GitLab

For conditional rendering predicated on results of an occlusion query.

If this driver function is NULL, conditional rendering is not supported by
the driver.

Conflicts:
	configs/darwin
	src/gallium/auxiliary/util/u_clear.h
	src/gallium/state_trackers/xorg/xorg_exa_tgsi.c
	src/mesa/drivers/dri/i965/brw_draw_upload.c

Render into two color buffers (render targets).  Display half of each
buffer in the window.  Use different color masks for each render target.
Only enable blending for the second render target.

For GL_NV_conditional_render and GL3.

The drawing functions don't check the query object yet.
No API dispatch yet.

When using multiple color drawbuffers with blending/logicop/masking we
were overwriting color values which we still needed.

The immediate's bits eat the condition bits.

Cannot change hw reg assigned to a TGSI TEMP on the fly if
we are in a loop, conditional, or can jump around wildly.

Not that they make much sense on nv50, but we also do LIT ...

If we create multiple instances of an nv50_reg referencing
them same resource, register allocation from alloc_reg has
to be done with the original nv50_reg.

Also fixes RSQ of negative sources.

This negation would only be triggered in situations
where it's incorrect.
The caller of set_immd should negate the immediate value
in the instruction itself if desired, and will also know
if it's a float or an int.

ADD TEMP[0], CONST[0], -IMMD[0] would load the immediate
into extra TEMP, negated, and set the negate flag in add
as well - double negation.

Note: not plugged into the dispatch table yet.

Note: some code disabled until dispatch table supports GL3 entrypoints.

These functions clear color/depth/stencil buffers with a value that's
passed to the function, rather than the context clear values.

For now these functions are implemented in terms of the existing
ctx->Driver.Clear() hook.  In the future when we have non-normalized
integer and unsigned integer color buffer formats we'll need new
driver hook(s) to pass int and uint clear values to the driver.

Note: these functions are not hooked into the dispatch table at this time.