vc4: Pair up QPU instructions when scheduling.

We've got two mostly-independent operations in each QPU instruction, so
try to pack two operations together.  This is fairly naive (doesn't track
read and write separately in instructions, doesn't convert ADD-based MOVs
into MUL-based movs, doesn't reorder across uniform loads), but does show
a decent improvement on shader-db-2.

total instructions in shared programs: 59583 -> 57651 (-3.24%)
instructions in affected programs:     47361 -> 45429 (-4.08%)
clover: clCompileProgram CL_INVALID_COMPILER_OPTIONS

clCompileProgram should return CL_INVALID_COMPILER_OPTIONS
instead of CL_INVALID_BUILD_OPTIONS

Reviewed-by: Francisco Jerez <currojerez@riseup.net>
r600, llvm: Fix mem leak

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
mesa: fix height error check for 1D array textures

height=0 is legal for 1D array textures (as depth=0 is legal for
2D arrays).  Fixes new piglit ext_texture_array-errors test.

Cc: "10.3 10.4" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
mesa: Generate GL_INVALID_OPERATION when drawing w/o a VAO in core profile

GL 3-ish versions of the spec are less clear that an error should be
generated here, so Ken (and I during review) just missed it in 1afe335.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Refactor common validation code to validate_DrawElements_common

Most of the code in _mesa_validate_DrawElements,
_mesa_validate_DrawRangeElements, and
_mesa_validate_DrawElementsInstanced was the same.  Refactor this out to
common code.

As a side-effect, a bug in _mesa_validate_DrawElementsInstanced was
fixed.  Previously this function would not generate an error when
check_valid_to_render failed if numInstances was 0.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Silence unused parameter warnings in _mesa_validate_Draw functions

../../src/mesa/main/api_validate.c: In function '_mesa_validate_DrawElements':
../../src/mesa/main/api_validate.c:376:37: warning: unused parameter 'basevertex' [-Wunused-parameter]
../../src/mesa/main/api_validate.c: In function '_mesa_validate_MultiDrawElements':
../../src/mesa/main/api_validate.c:394:65: warning: unused parameter 'basevertex' [-Wunused-parameter]
../../src/mesa/main/api_validate.c: In function '_mesa_validate_DrawRangeElements':
../../src/mesa/main/api_validate.c:452:35: warning: unused parameter 'basevertex' [-Wunused-parameter]
../../src/mesa/main/api_validate.c: In function '_mesa_validate_DrawArrays':
../../src/mesa/main/api_validate.c:473:25: warning: unused parameter 'start' [-Wunused-parameter]
../../src/mesa/main/api_validate.c: In function '_mesa_validate_DrawElementsInstanced':
../../src/mesa/main/api_validate.c:590:44: warning: unused parameter 'basevertex' [-Wunused-parameter]

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Use unreachable instead of assert in check_valid_to_render

This is generally the prefered style these days.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Use current Mesa coding style in check_valid_to_render

This makes some others patches (still in my local tree) a bit cleaner.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Just return void from brw_try_draw_prims

Note from Ken:

    "We used to use the return value to indicate whether software
    fallbacks were necessary, but we haven't in years."

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Remove "disable_derivative_optimization" driconf option.

This was added in September 2013 when we first implemented the fast
(but lower quality) derivatives.  A quick Google search didn't turn
up anyone using or recommending the option, so I suspect no one does.

Applications that want to control the quality of their derivatives can
use the new GL_ARB_derivative_control extension, or use the glHint
mechanism.  The driconf option seems superfluous.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Rename CACHE_NEW_*_PROG to BRW_NEW_*_PROG_DATA.

Now that we've moved a bunch of CACHE_NEW_* bits to BRW_NEW_*, the only
ones that are left are legitimately related to the program cache.  Yet,
it seems a bit wasteful to have an entire bitfield for only 7 bits.

State upload is one of the hottest paths in the driver.  For each atom
in the list, we call check_state() to see if it needs to be emitted.
Currently, this involves comparing three separate bitfields (mesa, brw,
and cache).  Consolidating the brw and cache bitfields would save a
small amount of CPU overhead per atom.  Broadwell, for example, has
57 state atoms, so this small savings can add up.

CACHE_NEW_*_PROG covers the brw_*_prog_data structures, as well as the
offset into the program cache BO (prog_offset).  Since most uses refer
to brw_*_prog_data, I decided to use BRW_NEW_*_PROG_DATA as the name.

Removing "cache" completely is a bit painful, so I decided to do it in
several patches for easier review, and to separate mechanical changes
from manual ones.  This one simply renames things, and was made via:

$ for file in *.[ch]; do
      sed -i -e 's/CACHE_NEW_\([A-Z_\*]*\)_PROG/BRW_NEW_\1_PROG_DATA/g' \
             -e 's/BRW_NEW_WM_PROG_DATA/BRW_NEW_FS_PROG_DATA/g' $file
  done

Note that BRW_NEW_*_PROG_DATA is still in .cache, not .brw!
The next patch will remedy this flaw.  It will also fix the
alphabetization issues.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Matt Turner <mattst88@gmail.com>
i965: Move BRW_NEW_*_PROG_DATA flags to .brw (not .cache).

I put the BRW_NEW_*_PROG_DATA flags at the beginning so that
brw_state_cache.c can still continue using 1 << brw_cache_id.

I also added a comment explaining the difference between
BRW_NEW_*_PROG_DATA and BRW_NEW_*_PROGRAM, as it took me a long time
to remember it.

Non-mechanical changes:
- brw_state_cache.c and brw_ff_gs.c now signal .brw, not .cache.
- brw_state_upload.c - INTEL_DEBUG=state changes.
- brw_context.h - bit definition merging.

v2: Correct the explanation of BRW_NEW_*_PROG_DATA to mention
    state-based recompiles, and nix the "proper subset" claim,
    as it's false. (Caught by Kristian Høgsberg).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Delete brw_state_flags::cache and related code.

It's been merged into brw_state_flags::brw for simplicity and
efficiency.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Move program key structures to brw_program.h.

With fs_visitor/fs_generator being reused for SIMD8 VS/GS programs,
we're running into weird #include patterns, where scalar code #includes
brw_vec4.h and such.

Program keys aren't really related to SIMD4X2/SIMD8 execution - they
mostly capture NOS for a particular shader stage.  Consolidating them
all in one place that's vec4/scalar neutral should help avoid problems.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Drop use of GL types in program keys.

This is really far removed from the API; we should just use C types.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Use the enum type for gen6_gather_wa sampler key field.

Requested by Matt Turner.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/vs: Handle vertex color clamping in emit_urb_slot().

Vertex color clamping only applies to a few specific built-ins: COL0/1
and BFC0/1 (aka gl_[Secondary]{Front,Back}Color).  It seems weird to
handle special cases in a function called emit_generic_urb_slot().

emit_urb_slot() is all about handling special cases, so it makes more
sense to handle this there.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Make vertex color clamp handling code VS specific.

Vertex color clamping only applies to gl_[Secondary]{Front,Back}Color,
which are compatibility-only built-in varyings.  We only support GS in
core profile, so they can't exist in geometry shaders.

We can drop several dirty bits from the GS program key - they're
unnecessary for a core profile implementation.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/vs: Set brw_vs_prog_key::clamp_vertex_color to 0 when irrelevant.

Vertex color clamping is only relevant if the shader writes to
the built-in gl_[Secondary]{Front,Back}Color varyings.  Otherwise,
brw_vs_prog_key::clamp_vertex_color is never used, so we can simply
leave it set to 0.

This enables us to correctly predict the clamp_vertex_color key value
in the precompile for shaders which don't use those varyings.

Eliminates virtually all VS recompiles in Serious Sam 3's intro.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>