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>
i965: Remove tabs from instruction scheduler.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
i965: Avoid union literal, for old gcc compatibility.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86939
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
r600, llvm: Don't leak global symbol offsets

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
i965/skl: Fix SBE state upload code.

The state upload code was incorrectly shifting the attribute swizzles. The
effect of this is we're likely to get the default swizzle values, which disables
the component.

This doesn't technically fix any bugs since Skylake support is still disabled by
default (no PCI IDs).

While here, since VARYING_SLOT_MAX can be greater than the number of attributes
we have available, add a warning to the code to make sure we never do the wrong
thing (and hopefully prevent further static analysis from finding this).
Admittedly I am a bit confused. It seems to me like the moment a user has
greater than 8 varyings we will hit this condition. CC Ken to clarify.

v2: Forgot to git add the warning message in v1

v3: Change the > 31 varyings to an assertion (Ken)

Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> (via Coverity)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>