softpipe: implement separate depth-stencil clear

The CAP is going away.

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: always assume separate depth and stencil clear is supported

All drivers implement it now.

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium: remove PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: fix glClear with different colormask for each colorbuffer

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: simplify conditionals in Clear

just check depth and stencil separately, the outcome is the same

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: remove dead conditional in Clear

I think the conditional always evaluates to false.

If I understand the code in core Mesa correctly, depthBits or stencilBits
is 0 if the depth or stencil renderbuffer is NULL, respectively.

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: fix InternalFormat for Z24X8 window-system buffers

This probably doesn't fix anything, but it's good to be consistent.

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium/util: fix glClear with MRT by making the FS write to all cbufs

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: use a generic varying to pass the clear color to the FS

The color varying may have reduced precision or be even clamped.

Reviewed-by: Brian Paul <brianp@vmware.com>
Revert "targets/opencl: Link against libgallium.la instead of libgallium.a"

This reverts commit 4148a29ed83d1d85bff3d4e40e847128011c3f20.

This is a work-around for bug:
https://bugs.freedesktop.org/show_bug.cgi?id=59334

We really should be linking against libgallium.la instead of
libgallium.a, but until we can figure why linking against libgallium.la
causes runtime failures in clover we will continue to link against
libgallium.a

Acked-by: Andreas Boll <andreas.boll.dev@gmail.com>
Tested-by: Aaron Watry <awatry@gmail.com>
gallium/util: add a half float array to util_color

For convenient packing into half floats.
r300g: implement MSAA compression and fast MSAA color clear

These are optimizations which make MSAA a lot faster.

The MSAA work is complete with this commit.  (except for enablement of AA
optimizations for RGBA16F, for which a patch is ready and waiting until
the kernel CS checker fix lands)

MSAA can't be made any faster as far as hw programming is concerned.

The catch is only one process and one colorbuffer can use the optimizations
at a time.  There usually is only one MSAA colorbuffer, so it shouldn't be
an issue.

Also, there is a limit on the size of MSAA colorbuffer resolution in terms
of megapixels.  If the limit is surpassed, the AA optimizations are disabled.
The limit is:
- 1 Mpix on low-end and some mid-level chipsets (1024x768 and 1280x720)
- 2 Mpix on some mid-level chipsets (1600x1200 and 1920x1080)
- 3 or 4 Mpix on high-end chipsets (2048x1536 or 2560x1600, respectively)
It corresponds to the number of raster pipes (= GB pipes) available, each pipe
can hold 1 Mpix of AA compression data.

If it's enabled, the driver prints to stdout:
  radeon: Acquired access to AA optimizations.
r300g: fix and cleanup flushing before clearing CMASK, ZMASK, and HIZ
docs: minor updates to VMware guest driver docs

The DRM's --enable-vmwgfx-experimental-api flag isn't needed anymore.
Update comment to specify actual text being referenced from the specification.

The reference to "correct, see spec" was a bit too vague to be useful,
(particularly since the language being referenced here changes between OpenGL
3.1 and OpenGL 4.3).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
queryobj: Add EverBound flag, making ISQuery() return false before BeginQuery()

This flag allows for the specified behavior that GenQueries reserves a name,
but does not associate an object with it until BeginQuery. We allocate the
object immediately with the new EverBound flag set to false, and then set the
flag to true at the time of BeginQuery.

This allows us to implement a conformant IsQuery function by checking the
state of the new EverBound flag.

This fixes the following es3conform tests:

	occlusion_query_genqueries
	occlusion_query_is_query_nonzero

and the following piglit test:

	occlusion_query_lifetime

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
meta: Allow meta operations to pause/resume an active occlusion query

This allows for avoiding the occlusion query erroneously accumulating results
during the meta operation. This functionality is made conditional on a new
MESA_META_OCCLUSION_QUERY bit so that meta-operations which should generate
fragments can continue to get the current behavior.

The implementation of glClear is specifically augmented to request the flag
since glClear is specified to not generate fragments.

This fixes the following es3conform tests:

	occlusion_query_draw_occluded.test
 	occlusion_query_clear
	occlusion_query_custom_framebuffer
	occlusion_query_stencil_test
	occlusion_query_discarded_fragments

As well as the following piglit test:

	occlusion_query_meta_no_fragments

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Force even an empty query to flush all previous queries.

The specification requires that query results are processed in order, (when
one query result is returned, all previous query of the same type must also be
available). The implementation was failing this requirement in the case of
BeginQuery and EndQuery with no intervening drawing, (the result would be made
available immediately without flushing previous queries).

This fixes the following es3conform test:

	occlusion_query_query_order

as well as the following piglit test:

	occlusion_query_order

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Rework crazy error code rules in glDrawBuffers().

Perhaps most importantly, this patch adds comments quoting the relevant
spec paragraphs above each error condition.

It also makes three changes:
- For FBOs, GL_COLOR_ATTACHMENTm where m >= MaxDrawBuffers is supposed
  to generate INVALID_OPERATION (not INVALID_ENUM).
- Constants that refer to multiple buffers (such as FRONT, BACK, LEFT,
  RIGHT, and FRONT_AND_BACK) are supposed to generate INVALID_OPERATION,
  not INVALID_ENUM.
- In ES 3.0, for FBOs, buffers[i] must be NONE or GL_COLOR_ATTACHMENTi
  or else INVALID_OPERATION occurs.  (This is a new restriction.)

Fixes es3conform's draw-buffers-api test.

v2: The error path was missing a "return" like all the other error
paths.  Also, we may as well call it glDrawBuffers in the error message
since the ARB suffix doesn't exist in ES 3.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Fix default value of BUFFER_ACCESS_FLAGS.

According to both the GL 3.0 and ES 3.0 specifications (table 2.7 for GL
and table 2.8 for ES), the default value of BUFFER_ACCESS_FLAGS is
supposed to be zero.

Note that there are two related quantities: the obsolete BUFFER_ACCESS
enum and the new BUFFER_ACCESS_FLAGS bitfield.

BUFFER_ACCESS can only be GL_READ_ONLY, GL_WRITE_ONLY, or GL_READ_WRITE;
BUFFER_ACCESS_FLAGS can easily represent all three via GL_MAP_WRITE_BIT,
GL_MAP_READ_BIT, and their logical or.  It also supports more flags.

Thus, Mesa only stores the bitfield, and simply computes the old enum
when queried, via simplified_access_mode(bufObj->AccessFlags).

The tricky part is that, while BUFFER_ACCESS_FLAGS defaults to 0,
BUFFER_ACCESS defaults to GL_READ_WRITE for desktop [GL 3.0, table 2.8]
and GL_WRITE_ONLY_OES for ES [the GL_EXT_map_buffer_range extension].

Mesa tried to implement this by setting the default AccessFlags to
GL_MAP_READ_BIT | GL_MAP_WRITE_BIT on desktop, and GL_MAP_WRITE_BIT on
ES.  But in all specifications, it needs to be 0.

This patch moves that logic into simplified_access_mode(): when
AccessFlags == 0, it now returns GL_READ_WRITE for desktop and
GL_WRITE_ONLY for ES 1/2.  (BUFFER_ACCESS doesn't exist on ES 3.0,
so it's irrelevant there.)

With that in place, it changes the AccessFlags default to 0.

Fixes three es3conform tsets:
- copy_buffer_defaults
- map_buffer_range_modify_indices
- pixel_buffer_object_default_parameters

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>