mesa: Check for vertex program the same way in desktop GL and ES

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Multithread:

32-bit: Difference at 95.0% confidence 0.416027% +/- 0.163529% (n=40)
64-bit: Difference at 95.0% confidence 0.494771% +/- 0.259985% (n=40)

Gl32Batch7 had no difference proven at 95.0% confidence (n=120) on
32-bit or 64-bit.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

mesa: Drop index buffer bounds check

The previous check was insufficient (as it did not take 'indices' into
consideration), and DX10 hardware does not need this check anyway.

Since index_bytes is no longer used, remove it.

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: Difference at 95.0% confidence 1.66929% +/- 0.230107% (n=40)
64-bit: Difference at 95.0% confidence -1.40848% +/- 0.288038% (n=40)

The regression on 64-bit is odd.  Callgrind says the caller,
validate_DrawElements_common is faster.  Before it says 10,321,920
cycles, and after it says 8,945,664.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

mesa: Only check for a current vertex shader in core profile

This doesn't affect performance, but it feels more correct.

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: No difference proven at 95.0% confidence (n=120)
64-bit: No difference proven at 95.0% confidence (n=120)

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

mesa: Only validate shaders that can exist in the context

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: Difference at 95.0% confidence 0.495267% +/- 0.202063% (n=40)
64-bit: Difference at 95.0% confidence 3.57576% +/- 0.288175% (n=40)

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Store the atoms directly in the context

Instead of having an extra pointer indirection in one of the hottest
loops in the driver.

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: Difference at 95.0% confidence 1.98515% +/- 0.20814% (n=40)
64-bit: Difference at 95.0% confidence 1.5163% +/- 0.811016% (n=60)

v2 (Ken): Cut size of array from 64 to 57 to save memory.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Micro-optimize brw_get_index_type

With the switch-statement, GCC 4.8.3 produces a small pile of code with
a branch.

00000000 <brw_get_index_type>:
  000000:       8b 54 24 04             mov    0x4(%esp),%edx
  000004:       b8 01 00 00 00          mov    $0x1,%eax
  000009:       81 fa 03 14 00 00       cmp    $0x1403,%edx
  00000f:       74 0d                   je     00001e <brw_get_index_type+0x1e>
  000011:       31 c0                   xor    %eax,%eax
  000013:       81 fa 05 14 00 00       cmp    $0x1405,%edx
  000019:       0f 94 c0                sete   %al
  00001c:       01 c0                   add    %eax,%eax
  00001e:       c3                      ret

However, this could be two instructions.

00000000 <brw_get_index_type>:
  000000:       2d 01 14 00 00          sub    $0x1401,%eax
  000005:       d1 e8                   shr    %eax
  000007:       90                      nop
  000008:       90                      nop
  000009:       90                      nop
  00000a:       90                      nop
  00000b:       c3                      ret

The function was also moved to the header so that it could be inlined at
the two call sites.  Without this, 32-bit also needs to pull the
parameter from the stack.  This means there is a push, a call, a move,
and a ret added to a two instruction function.  The above code shows the
function with __attribute__((regparm=1)), but even this adds several
extra instructions.  There is also an extra instruction on 64-bit to
move the parameter to %eax for the subtract.

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: Difference at 95.0% confidence 0.818589% +/- 0.234661% (n=40)
64-bit: Difference at 95.0% confidence 0.54554% +/- 0.354092% (n=40)

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

meta: Put _mesa_meta_in_progress in the header file

...so that it can be inlined in the two places that call it.

On Bay Trail-D using Fedora 20 compile flags (-m64 -O2 -mtune=generic
for 64-bit and -m32 -march=i686 -mtune=atom for 32-bit), affects
Gl32Batch7:

32-bit: No difference proven at 95.0% confidence (n=120)
64-bit: Difference at 95.0% confidence 1.24042% +/- 0.382277% (n=40)

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Fix "vertex" vs. "geometry" and "VS" vs. "GS" in debug output.

We were happily printing "Native code for unnamed vertex shader" and
"VS vec4" program for geometry shaders in our INTEL_DEBUG=gs output,
as well as the KHR_debug output used by shader-db.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Pass a shader stage abbreviation to fs_generator().

A lot of messages hardcoded the string "FS", which is confusing on
Broadwell, where we use this code for VS support as well.

shader-db particularly got confused, as it reported two "FS SIMD8"
shaders, and no vertex shaders at all.  Craziness ensued.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

configure: add check for GNU indent

Only GNU indent is supported when indenting autogenerated format_pack.c
and format_unpack.c files. Some non-GNU indent (Mac OS X and FreeBSD)
add extra whitespaces than break the build of those files.

Fallback to 'cat' if a non-GNU indent is found.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88335
Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

configure: change required Python Mako version to 0.3.4

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>

mesa: rename RGBA8888_* format constants to something appropriate.

The 8888 suggests 8-bit components which is not correct, so
replace that with the actual size of the components in each
format.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

i965/miptree_map_blit: Don't do the initial copy if INVALIDATE_RANGE is set

Before we were always coping from the buffer being mapped into the
temporary buffer.  However, if INVALIDATE_RANGE is set, then we know that
the data is going to be junk after we unmap so there's no point in doing
the blit.  This is important because doing the blit will cause a stall 3
lines later when we map the buffer.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

mesa/glsl/glapi: enable GL_EXT_draw_buffers extension

Patch enables ES2 extension that utilizes existing ES3 functionality.

Changes make all the subtests to run and pass in WebGL conformance
test 'webgl-draw-buffers' when running Chrome on OpenGL ES, also
Piglit test 'draw_buffers_gles2' passes.

v2: remove unused boolean (Ilia Mirkin)
v3: proper error checking for invalid values (Chad Versace)
v4: run error check explicitly for ES2 and ES3 (Kenneth Graunke)

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>

i965/fs: Allow constant propagation between different types

This will be needed for NIR because it is typeless and treats all constants
as uint32 values and reinterprets them when they are used later.  This
commit allows those values to be properly propagated.

Also, this helps some synmark shaders because it allows us to copy
propagate a 0x00000000UD into a 0.0F in a load_payload, which then lets us
combine 4 load_payloads.

instructions in affected programs:     2288 -> 2144 (-6.29%)

Reviewed-by: Matt Turner <mattst88@gmail.com>

egl/wayland: Fix unused variable warnings

Remove ctx variables unused as of 70e8ccc459.

mesa: Enable GL_RGB/GL_RGBA in GLES3 glGetInternalformativ

Removes commit 7894278 changes and moves fix to _mesa_GetInternalformativ().
The original commit enabled the GL_RGB and GL_RGBA unsized internal formats
as valid for render buffers in GLES3, but this is incorrect. They should
have only been enabled for GetInternalformativ()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88079
Reviewed-by: Chad Versace <chad.versace@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

freedreno/ir3: handle "holes" in inputs

If, for example, only the x/y/w components of in.xyzw are actually used,
we still need to have a group of four registers and assign all four
components.  The hardware can't write in.xy and in.w to discontiguous
registers.  To handle this, pad with a dummy NOP instruction, to keep
the neighbor chain contiguous.

This fixes a problem noticed with firefox OMTC.

Signed-off-by: Rob Clark <robclark@freedesktop.org>

mesa: Fix error reporting for some cases of incomplete FBO attachments

According to the OpenGL and OpenGL ES specs (sections
"FRAMEBUFFER COMPLETENESS" and "Whole Framebuffer Completeness"),
the image for color, depth or stencil attachments must be renderable,
otherwise the attachment is considered incomplete and we should report
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. Currently, we detect this
situation properly but report a different error.

This fixes the following 3 piglit tests:
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgba_unsigned_int_2_10_10_10_rev
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb16f

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Returns a GL_INVALID_VALUE error if num of texs in glDeleteTextures is negative

Per GLES3 manual for glDeleteTextures
<https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteTextures.xhtml>,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.texture.deletetextures

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteRenderbuffers is negative

Per GLES3 manual for glDeleteRenderbuffers
<https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteRenderbuffers.xhtml>,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_renderbuffers

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Returns a GL_INVALID_VALUE error if num of fbos in glDeleteFramebuffers is negative

Per GLES3 manual for glDeleteFramebuffers
<https://www.khronos.org/opengles/sdk/docs/man3/html/glDeleteFramebuffers.xhtml>,
GL_INVALID_VALUE is generated if n is negative.

Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.delete_framebuffers

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Allows querying GL_SAMPLER_BINDING on GLES3 profile

From GLES3 specification (page 123), "The currently bound sampler may be
queried by calling GetIntegerv with pname set to
SAMPLER_BINDINGGL_SAMPLER_BINDING".

Fixes 4 dEQP tests:
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getboolean
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getinteger64
* dEQP-GLES3.functional.state_query.integers.sampler_binding_getfloat

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

main: round floating-point value to nearest integer in glGetSamplerParameteriv()

Previously, a cast was done to convert from float to int but there
were rounding errors.

The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.

This patch fixes the following 2 dEQP tests:

dEQP-GLES3.functional.state_query.sampler.sampler_texture_min_lod_getsamplerparameteri
dEQP-GLES3.functional.state_query.sampler.sampler_texture_max_lod_getsamplerparameteri

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

main: round floating-point value to nearest integer in glGetTexParameteriv()

Previously, a cast was done to convert from float to int but there
were rounding errors.

The spec specificies in Data Conversion chapter that Floating-point values are
rounded to the nearest integer.

This patch fixes the following 8 dEQP tests:

dEQP-GLES3.functional.state_query.texture.texture_2d_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_3d_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_3d_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_2d_array_texture_max_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_min_lod_gettexparameteri
dEQP-GLES3.functional.state_query.texture.texture_cube_map_texture_max_lod_gettexparameteri

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

main: fix return GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL value

Return the proper value for two-dimensional array texture and three-dimensional
textures.

From OpenGL ES 3.0 spec, chapter 6.1.13 "Framebuffer Object Queries",
page 234:

"If pname is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and the texture
object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a layer of a
three-dimensional texture or a two-dimensional array texture, then params
will contain the number of the texture layer which contains the attached im-
age. Otherwise params will contain the value zero."

Furthermore, FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is an alias of
FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT.

This patch fixes dEQP test:

dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_texture_layer

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Fix bitcast operations with negate (ceil)

Commit 0ae9ca12a8 put source modifiers out of the bitcast operations
by adding a MOV operation that would handle them separately. It missed
the case of ceil though: the implementation negates both its source and
destination operands. The source operand will be used for RNDD, which
we can handle normally, but we need to fix the modifier for the
negated result.

v2:
  - RNDD can handle the source modifier so no need to put that one
    in a separate MOV.

Fixes the following 42 dEQP tests:
dEQP-GLES3.functional.shaders.builtin_functions.common.ceil.*_vertex
dEQP-GLES3.functional.shaders.builtin_functions.common.ceil.*_fragment
dEQP-GLES3.functional.shaders.builtin_functions.precision.ceil._*vertex.*
dEQP-GLES3.functional.shaders.builtin_functions.precision.ceil._*fragment.*

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Depth and stencil attachments must be the same in OpenGL ES3

"9.4. FRAMEBUFFER COMPLETENESS
 ...
 Depth and stencil attachments, if present, are the same image."

Notice that this restriction is not included in the OpenGL ES2 spec.

Fixes 18 dEQP tests in:
dEQP-GLES3.functional.fbo.completeness.attachment_combinations.*

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Initializes the stencil value masks to 0xFF instead of ~0u

'4.1.4 Stencil Test' section of the GL-ES 3.0 specification says:

    "In the initial state, [...] the front and back stencil mask are both set
    to the value 2^s − 1, where s is greater than or equal to the number of
    bits in the deepest stencil buffer* supported by the GL implementation."

Since the maximum supported precision for stencil buffers is 8 bits, mask
values should be initialized to 2^8 - 1 = 0xFF.

Currently, these masks are initialized to max unsigned integer (~0u), because
in OpenGL 3.0 and before, the initial mask values were:

    "In the initial state, stenciling is disabled, the front and back
    stencil reference value are both zero, the front and back stencil
    comparison functions are both ALWAYS, and the front and back
    stencil mask are both all ones."

The problem is that it causes the mask values to overflow to -1 when converted
to signed integer by glGet* APIs.

Fixes 6 dEQP failing tests:
* dEQP-GLES3.functional.state_query.integers.stencil_value_mask_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_value_mask_separate_both_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_getfloat
* dEQP-GLES3.functional.state_query.integers.stencil_back_value_mask_separate_both_getfloat

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Sets missing vertex shader constant values for HighInt format

The range's min and max, and the precision value are not set correctly for the
vertex shader constants.

Fixes 1 dEQP test: dEQP-GLES3.functional.state_query.shader.precision_vertex_highp_int

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

r600g: fix build failure when building the driver without LLVM

main: Remove comparison unsigned int >= 0.

Fixes "macro compares unsigned to 0 (NO_EFFECT)" found by Coverity Scan.

Reviewed-by: Matt Turner <mattst88@gmail.com>

mesa/main: In _mesa_CompressedTextureSubImage3D() check found texObj

Check returned texObj is not null. If texObj is null there is already
GL_INVALID_OPERATION error set.

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

mesa: Move declarations to to of block.

To fix MSVC build.

Trivial.

mesa: restrict use of GL_ABGR_EXT format to allowed data types

GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV,
GL_UNSIGNED_INT_10_10_10_2, GL_UNSIGNED_INT_2_10_10_10_REV data types
are not explicitly allowed to work with GL_ABGR_EXT format neither
in GL nor GL_EXT_abgr specs.

Removed the corresponding mesa formats as there are no other functions
using them inside Mesa anymore.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_rebase_rgba_uint and _mesa_rebase_rgba_float

These are no longer used anywhere now that we have _mesa_format_convert.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_pack_int_rgba_row() and auxiliary functions

These are no longer used.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_(un)pack_index_span

These are not used anywhere.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_pack_rgba_span_float and tmp_pack.h

_mesa_pack_rgba_span_float was the last of the color span functions
and we have replaced all calls to it with calls to _mesa_format_convert,
so we can remove it together with tmp_pack.h which was used to
generate the pack functions for multiple types that were used from
the various color span functions that have been removed.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_unpack_color_span_float

And various helper functions that went unused after removing it.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove (signed) integer pack and span functions.

These are no longer used now that we moved to _mesa_format_convert.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_unpack_color_span_ubyte

This is no longer used anywhere after moving to _mesa_format_convert.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_make_temp_float_image

Now that we have _mesa_format_convert we don't need this.

This was only used to create temporary RGBA float images in the process
of storing some compressed formats. These can call _mesa_texstore
with a RGBA/float dst to achieve the same goal.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_make_temp_ubyte_image

Now that we have _mesa_format_convert we don't need this.

texstore_rgba will use the GL_COLOR_INDEX to RGBA conversion
helpers instead and compressed formats that used
_mesa_make_temp_ubyte_image to create an ubyte RGBA temporary
image can call _mesa_texstore with a RGBA/ubyte dst to
achieve the same goal.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Remove _mesa_unpack_color_span_uint

This is no longer used.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Replace _mesa_unpack_bitmap with _mesa_unpack_image()

_mesa_unpack_bitmap() was introduced by commit 02b801c to handle the case
when data is stored in PBO by display lists, in the context of this bug:

Incorrect pixels read back if draw bitmap texture through Display list
https://bugs.freedesktop.org/show_bug.cgi?id=10370

Since _mesa_unpack_image() already handles the case of GL_BITMAP, this patch
removes _mesa_unpack_bitmap() and makes affected calls go through
_mesa_unapck_image() instead.

The sample test attached to the original bug report passes with this change
and there are no piglit regressions.

Signed-off-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Let _mesa_swizzle_and_convert take array format types instead of GL types

In the future we would like to have a format conversion library that is
independent of GL so we can share it with Gallium. This is a step in that
direction.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

st/mesa: Use _mesa_format_convert to implement st_GetTexImage.

Instead of using _mesa_pack_rgba_span_float. This should allow us to remove
that function in a later patch.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

swrast: Use _mesa_format_convert to implement draw_rgba_pixels.

This is the only place that uses _mesa_unpack_color_span_float so after
this we should be able to remove that function.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Use _mesa_format_convert to implement get_tex_rgba_compressed.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: use _mesa_format_convert to implement get_tex_rgba_uncompressed.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: use _mesa_format_convert to implement glReadPixels.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Use _mesa_format_convert to implement texstore_rgba.

Notice that _mesa_format_convert does not handle byte-swapping scenarios,
GL_COLOR_INDEX or MESA_FORMAT_YCBCR(_REV), so these must be handled
separately.

Also, remove all the code that goes unused after using _mesa_format_convert.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add helpers to extract GL_COLOR_INDEX to RGBA float/ubyte

We only use _mesa_make_temp_ubyte_image in texstore.c to convert
GL_COLOR_INDEX to RGBA, but this helper does more stuff than this.
All uses of this helper can be replaced with calls to
_mesa_format_convert except for this GL_COLOR_INDEX conversion.

This patch extracts the GL_COLOR_INDEX to RGBA logic to a separate
helper so we can use that instead from texstore.c.

In future patches we will replace all remaining calls to
_mesa_make_temp_ubyte_image in the repository (related to compressed
formats) with calls to _mesa_format_convert so we can remove
_mesa_make_temp_ubyte_image and related functions.

v2:
- Remove ‘for’ loop initial declaration. They are only allowed in C99 or C11
mode.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add RGBA to Luminance conversion helpers

For glReadPixels with a Luminance destination format we compute luminance
values from RGBA as L=R+G+B. This, however, requires ad-hoc implementation,
since pack/unpack functions or _mesa_swizzle_and_convert won't do this
(and thus, neither will _mesa_format_convert). This patch adds helpers
to do this computation so they can be used to support conversion to luminance
formats.

The current implementation of glReadPixels does this computation as part
of the span functions in pack.c (see _mesa_pack_rgba_span_float), that do
this together with other things like type conversion, etc. We do not want
to use these functions but use _mesa_format_convert instead (later patches
will remove the color span functions), so we need to extract this functionality
as helpers.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add _mesa_swap2_copy and _mesa_swap4_copy

We have _mesa_swap{2,4} but these do in-place byte-swapping only. The new
functions receive an extra parameter so we can swap bytes on a source
input array and store the results in a (possibly different) destination
array.

This is useful to implement byte-swapping in pixel uploads, since in this
case we need to swap bytes on the src data which is owned by the
application so we can't do an in-place byte swap.

v2:
  - Include compiler.h in image.h, which is necessary to build in MSCV as
    indicated by Brian Paul.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/pack: use _mesa_format_from_format_and_type in _mesa_pack_rgba_span_from_*

We had previously added the needed mesa formats, so we can simplify
the code further.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add helper to convert a GL format and type to a mesa (array) format.

v2 after review by Jason Ekstrand:
- Move _mesa_format_from_format_and_type to glformats
- Return a mesa_format for GL_UNSIGNED_INT_8_8_8_8(_REV)

v3:
- Adapted to the new implementation of mesa_array_format as a plain uint32_t
  bitfield.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add a helper _mesa_compute_rgba2base2rgba_component_mapping

This will come in handy when callers of _mesa_format_convert need
to compute the rebase swizzle parameter to use.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add a rebase_swizzle parameter to _mesa_format_convert

The new parameter allows callers to provide a rebase swizzle that
the function needs to use to match the requirements of the base
internal format involved. This is necessary when the source or
destination internal formats (depending on whether we are doing
the conversion for a pixel download or a pixel upload respectively)
do not match the base formats of the source or destination
formats of the conversion. This can happen when the driver does not
support the internal formats and uses a different format to store
pixel data internally.

For example, a texture upload from RGB to Luminance in a driver
that does not support textures with a Luminance format may decide
to store the Luminance data as RGBA. In this case we want to store
the RGBA values as (R,R,R,1). Following the same example, when we
download from that texture to RGBA we want to read (R,0,0,1). The
rebase_swizzle parameter allows these transforms to happen.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Expose compute_component_mapping as _mesa_compute_component_mapping

This is necessary to handle conversions between array types where
the driver does not support the dst format requested by the client and
chooses a different format instead.

We will need this in _mesa_format_convert, so move it to format_utils.c,
prefix it with '_mesa_' and make it available to other files.

v2:
  - Move _mesa_compute_component_mapping to glformats

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add an implementation of a master convert function.

v2 by Iago Toral <itoral@igalia.com>:

- When testing if we can directly pack we should use the src format to check
  if we are packing from an RGBA format. The original code used the dst format
  for the ubyte case by mistake.
- Fixed incorrect number of bits for dst, it was computed using the src format
  instead of the dst format.
- If the dst format is an array format, check if it is signed. We were only
  checking this for the case where it was not an array format, but we need
  to know this in both scenarios.
- Fixed incorrect swizzle transform for the cases where we convert between
  array formats.
- Compute is_signed and bits only once and for the dst format. We were
  computing these for the src format too but they were overwritten by the
  dst values immediately after.
- Be more careful when selecting the integer path. Specifically, check that
  both src and dst are integer types. Checking only one of them should suffice
  since OpenGL does not allow conversions between normalized and integer types,
  but putting extra care here makes sense and also makes the actual requirements
  for this path more clear.
- The format argument for pack functions is the destination format we are
  packing to, not the source format (which has to be RGBA).
- Expose RGBA8888_* to other files. These will come in handy when in need to
  test if a given array format is RGBA or in need to pass RGBA formats to
  mesa_format_convert.

v3 by Samuel Iglesias <siglesias@igalia.com>:

- Add an RGBA8888_INT definition.

v4 by Iago Toral <itoral@igalia.com> after review by Jason Ekstrand:

- Added documentation for _mesa_format_convert.
- Added additional explanatory comments for integer conversions.
- Ensure that we use _messa_swizzle_and_convert for all signed source formats.
- Squashed: do not directly (un)pack to RGBA UINT if the source is not unsigned.

v5 by Iago Toral <itoral@igalia.com>:

- Adapted to the new implementation of mesa_array_format as a plain uint32_t
  bitfield.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/pack: refactor _mesa_pack_rgba_span_float()

Use autogenerated format pack functions and take advantage of some
macros to reduce source code, facilitating its maintenance.

Unfortunately, dstType == GL_UNSIGNED_SHORT cannot simplified like
the others, so keep it as it is.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/main/pack_tmp.h: Add float conversion support

We will use this in a later patch to refactor _mesa_pack_rgba_span_float.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/pack: use autogenerated format_pack functions

Take advantage of new mesa formats and new format_pack functions to
reduce source code in _mesa_pack_rgba_span_from_ints() and
_mesa_pack_rgba_span_from_uints().

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: use format conversion functions in swrast

This commit adds a macro to facilitate the task of using
format conversions functions but keeps the same API.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/formats: add new mesa formats and their pack/unpack functions.

This  will be used to refactor code in pack.c and support conversion
to/from these types in a master convert function that will be added
later.

v2:
- Fix autogeneration of MESA_FORMAT_A2R10G10B10_UNORM pack/unpack
  functions

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/format_pack: Add _mesa_pack_int_rgba_row()

This will be used to unify code in pack.c.

v2:
- Modify pack_int_*() function generator to use c.datatype() and
  f.datatype()

v3:
- Only autogenerate pack_int_*() functions for non-normalized integer
  formats.

v4:
- Use _mesa_unsigned_to_unsigned() in pack_int_*() because, in order
  to be able to pack both signed and unsigned formats, we need to
  sign-extend.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add _mesa_pack_uint_rgba_row() format conversion function

We will use this later on to handle uint conversion scenarios in a master
convert function.

v2:
- Modify pack_uint_*() function generation to use c.datatype() and
  f.datatype().
- Remove UINT_TO_FLOAT() macro usage from pack_uint*()
- Remove "if not f.is_normalized()" conditional as pack_uint*()
  functions are only autogenerated for non normalized formats.

v3:
- Add clamping for non-normalized integer formats in pack_uint*()

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Autogenerate format_unpack.c

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2 by Samuel Iglesias <siglesias@igalia.com>:
- Add usage of INDENT_FLAGS in Makefile.am

v3 by Samuel Iglesias <siglesias@igalia.com>:
- Modify unpack_float_*() and unpack_ubyte_*() function generation
to use c.datatype() and f.datatype()
- Fix out-of-tree build

v4 by Samuel Iglesias <siglesias@igalia.com>:
- format_unpack.c.mako is now format_unpack.py, with the template code
  inlined. It now auto-generates format_unpack.c
- Add format_unpack.c to gitignore.
- Simplify Makefile.am change
- Modify SConscript to build format_unpack.c with scons

v5 by Samuel Iglesias <siglesias@igalia.com>:
- Don't allow float to non-normalized integer format conversions.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Autogenerate most of format_pack.c

We were auto-generating it before.  The problem was that the autogeneration
tool we were using was called "copy, paste, and edit".  Let's use a more
sensible solution.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2 by Samuel Iglesias <siglesias@igalia.com>
- Remove format_pack.c as it is now autogenerated
- Add usage of INDENT_FLAGS in Makefile.am
- Remove trailing blank line

v3 by Samuel Iglesias <siglesias@igalia.com>
- Merge format_convert.py into format_parser.py
   - Adapt pack_*_* function generations
- Fix out-of-tree build

v4 by Samuel Iglesias <siglesias@igalia.com>
- _get_datatype() is now a helper function

v5 by Samuel Iglesias <siglesias@igalia.com>
- format_pack.c.mako is now format_pack.py, with the template code
  inlined. It now auto-generates format_pack.c
- Simplify Makefile.am change.
- Modify SConscript to build format_pack.c with scons.
- Remove run_mako.py
- Add format_pack.c to gitignore

v6 by Samuel Iglesias <siglesias@igalia.com>:
- Don't allow float to non-normalized integer format conversions.
- Add non-normalized formats support for ubyte packing functions. Merge
the previously separated patch.
- Add clamping for non-normalized integer formats in pack_ubyte*()

v7 by Samuel Iglesias <siglesias@igalia.com>:
- Add assert to check that sRGB formats are 8-bit size.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

configure: require python mako module

It is now a hard dependency because of the autogeneration of
format pack and unpack functions.

Update the documentation to reflect this change.

v2:
- Inline python script in m4 file and use PYTHON2

v3:

- Remove semicolons and quotes and change coding style
- Add Ilia Mirkin suggestion to use Python's split functionality.
- Use AX_CHECK_PYTHON_MAKO_MODULE name.
- Change to MIT license

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Add a _mesa_is_format_color_format helper

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: Let _mesa_get_format_base_format also handle mesa_array_format.

If we need the base format for a mesa_array_format we have to find the
matching mesa_format first. This is expensive because it requires
to loop through all existing mesa formats until we find the right match.

We can resolve the base format of an array format directly by looking
at its swizzle information. Also, we can have _mesa_get_format_base_format
accept an uint32_t which can pack either a mesa_format or a mesa_array_format
and resolve the base format for either type. This way clients do not need to
check if they have a mesa_format or a mesa_array_format and call different
functions depending on the case.

Another reason to resolve the base format for array formats directly is that
we don't have matching mesa_format enums for every possible array format, so
for some GL format/type combinations we can produce array formats that don't
have a corresponding mesa format, in which case we would not be able to
find the base format. Example format=GL_RGB, type=GL_UNSIGNED_SHORT. This type
would map to something like MESA_FORMAT_RGB_UNORM16, but we don't have that.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

main: Add a concept of an array format

An array format is a 32-bit integer format identifier that can represent
any format that can be represented as an array of standard GL datatypes.
Whie the MESA_FORMAT enums provide several of these, they don't account for
all of them.

v2 by Iago Toral Quiroga <itoral@igalia.com>:
 - Implement mesa_array_format as a plain bitfiled uint32_t type instead of
   using a struct inside a union to access the various components packed in
   it. This is necessary to support bigendian properly, as pointed out by
   Ian.
 - Squashed: Make float types normalized

v3 by Iago Toral Quiroga <itoral@igalia.com>:
  - Include compiler.h in formats.h, which is necessary to build in MSVC as
    indicated by Brian Paul.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

swrast: Remove unused variable.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Fix _mesa_swizzle_and_convert integer conversions to clamp properly

Fix various conversion paths that involved integer data types of different
sizes (uint16_t to uint8_t, int16_t to uint8_t, etc) that were not
being clamped properly.

Also, one of the paths was incorrectly assigning the value 12, instead of 1,
to the constant "one".

v2:
- Create auxiliary clamping functions and use them in all paths that
  required clamp because of different source and destination sizes
  and signed-unsigned conversions.

v3:
- Create MIN_INT macro and use it.

v4:
- Add _mesa_float_to_[un]signed() and mesa_half_to_[un]signed() auxiliary
  functions.
- Add clamp for float-to-integer conversions in _mesa_swizzle_and_convert()

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa/format_utils: Prefix and expose the conversion helper functions

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2 by Samuel Iglesias <siglesias@igalia.com>:
- Fix compilation errors

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Fix incorrect assertion in init_teximage_fields_ms

_BaseFormat is a GLenum (unsigned int) so testing if its value is
greater than 0 to detect the cases where _mesa_base_tex_format
returns -1 doesn't work.

Fixing the assertion breaks the arb_texture_view-lifetime-format
piglit test on nouveau, since that test calls
_mesa_base_tex_format with GL_R16F with a context that does not
have ARB_texture_float, so it returns -1 for the BaseFormat, which
was not being caught properly by the ASSERT in init_teximage_fields_ms
until now.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Fix get_texbuffer_format().

We were returning incorrect mesa formats for GL_LUMINANCE_ALPHA16I_EXT
and GL_LUMINANCE_ALPHA32I_EXT.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

mesa: Fix A1R5G5B5 packing/unpacking

As with B5G6R5, these have been left broken with comments saying they are.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa/colormac: Remove an unused macro

The PACK_565_REV macro is no longer used.  It was also extremely confusing
because it's actually a byteswapped 565 not reversed 565.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Fix packing/unpacking of MESA_FORMAT_R5G6B5_UNORM

Aparently, the packing/unpacking functions for these formats have differed
from the format description in formats.h.  Instead of fixing this, people
simply left a comment saying it was broken.  Let's actually fix it for
real.

v2 by Samuel Iglesias <siglesias@igalia.com>:
- Fix comment in formats.h

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: Fix clamping to -1.0 in snorm_to_float

This patch fixes the return of a wrong value when x is lower than
-MAX_INT(src_bits) as the result would not be between [-1.0 1.0].

v2 by Samuel Iglesias <siglesias@igalia.com>:
    - Modify snorm_to_float() to avoid doing the division when
      x == -MAX_INT(src_bits)

Cc: 10.4 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

docs: add news item and link release notes for mesa 10.3.7/10.4.2

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

docs: Add sha256 sums for the 10.4.2 release

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 14f1659b4311589959b2513e437f0229174eb5ae)

Add release notes for the 10.4.2 release

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 02f2e97c3ee4a10696bfce79b6299d478bb6e59a)

docs: Add sha256 sums for the 10.3.7 release

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 20e0546cc2aa2a32919c3fb179507a60bef8e6e7)

Add release notes for the 10.3.7 release

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 6b00e5585a765a82219ceffce2840308df52b44b)

i965: Respect the no_8 flag on Gen6, not just Gen7+.

When doing repclears, we only want to use the SIMD16 program, not the
SIMD8 one.  Kristian added this to the Gen7+ code, but apparently we
missed it in the Gen6 code.  This patch copies that code over.

Approximately doubles the performance in a clear microbenchmark from
mesa-demos (clearspd -width 500 -height 500 +color) on Sandybridge.

Cc: "10.4 10.3" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
References: https://code.google.com/p/chrome-os-partner/issues/detail?id=34681

mesa: Always generate GL_INVALID_OPERATION in _mesa_GetProgramBinary

There are no binary formats supported, so what are you doing?  At least
this gives the application developer some feedback about what's going
on.  The spec gives no guidance about what to do in this scenario.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Leight Bade <leith@mapbox.com>

mesa: Ensure that length is set to zero in _mesa_GetProgramBinary

v2: Fix assignment of length.  Noticed by Julien Cristau.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Leight Bade <leith@mapbox.com>

mesa: Add missing error checks in _mesa_ProgramBinary

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Leight Bade <leith@mapbox.com>

vc4: Clamp the inputs to the blend equation to [0, 1].

Fixes the remaining ARB_color_buffer_float rendering tests.

vc4: Add a little helper for clamping to [0,1].

vc4: Fix up statechange management for uncompiled/compiled FS/VS.

No need to recheck the FS compile when the VS source has changed, but
there *is* a need to recheck the VS compile when the compiled VS has
changed (since the live inputs may change).

Fixes es3conform's blend test.

vc4: Fix clear color setup for RGB565.

The util_pack_color() thing only sets up the low bits of the union, so
only return them, too.  Fixes intermittent failure on
fbo-alphatest-formats and es3conform's framebuffer-objects test under
simulation.

vc4: Avoid the save/restore of r3 for raddr conflicts, just use ra31.

Turns out this was harmful in code quality:

total instructions in shared programs: 39487 -> 38845 (-1.63%)
instructions in affected programs:     22522 -> 21880 (-2.85%)

This costs us yet another register, which is painful since it means more
programs might fail to compile).  However, the alternative was causing us
trouble where we'd save/restore r3 while it contained a MIN-ed direct
texture offset, causing the kernel to fail to validate our shaders (such
as in GLB2.7).

vc4: Allow dead code elimination of VPM reads.

This gets a bunch of dead reads out of the CSes, which don't read most
attributes generally.

total instructions in shared programs: 39753 -> 39487 (-0.67%)
instructions in affected programs:     4721 -> 4455 (-5.63%)

vc4: Cook up the draw-time VPM setup info during shader compile.

This will give the compiler the chance to dead-code eliminate unused VPM
reads.  This is particularly a big deal in the CS where a bunch of vattrs
are just not going to be used.