glcpp: Add test involving token pasting of INTEGER tokens.

This test file is very similar to test 113-line-and-file-macros but uses token
pasting for cleaner quiz answers (without spaces between the digits). This
test passes thanks to the recent addition of support for pasting INTEGER
tokens, (but would have failed without that).

(Note that this test is distinct from test 059-token-pasting-integer which
pastes integers parsed from the source. Those are parsed to INTEGER_STRING
tokens and are already pasted correctly as verified by that test. The only way
to generate the INTEGER tokens which currently fail to paste is with an
internal define such as __LINE__ that results in an integer.)

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

glcpp: Add support for pasting of INTEGER tokens.

By generalizing the current code designed to paste string tokens of various
types.

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

glcpp: Flag invalid pastes for integer followed by non-digits

As recently tested in the additions to the invalid paste test, it is illegal
to paste a non-digit sequence onto the end of an integer.

The 082-invalid-paste test should now pass again.

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

glcpp: Extend the invalid-paste test

The current code lets a few invalid pastes through, such as an string pasted
onto the end of an integer. Extend the invalid-paste test to catch some of
these.

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

glcpp: More factoring-out of common code to simplify things.

This time creating a new _token_list_create_with_one_integer function
modeled after the existing _token_list_create_with_one_space function
(both implemented with new _token_list_create_with_one_ival).

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

glcpp: Factor out a tiny bit of repeated code.

This function is getting a little long too read. Simplify it by pulling
up one assignment from every condition.

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

glcpp: Add support for __LINE__ and __FILE__ macros

These tokens are easy to expand by just looking at the current, tracked
location values, (and no need to look anything up in the hash table).

Add a test which verifies __LINE__ with several values, (and verifies __FILE__
for the single value of 0). Our testing framework isn't sophisticated enough
here to have a test with multiple file inputs.

This commit fixes part of es3conform's preprocess16_frag test.

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

mesa: Rename API_OPENGL to API_OPENGL_COMPAT.

This should help avoid confusion now that we're using the gl_api enum
to distinguishing between core and compatibility API's.  The
corresponding enum value for core API's is API_OPENGL_CORE.

Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>

gallium/postprocess: share pipe_context and cso_context with the state tracker

Using one context instead of two is more efficient and
we can skip another context flush.

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

mesa: move some helper functions from fboobject.c to glformats.c

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

android: include api_exec.c in generated files list

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

gallivm: Fix lp_build_float_to_half.

The current implementation was close by not fully correct: several
operations that should be done in floating point were being done in
integer.

Fixes piglit fbo-clear-formats GL_ARB_texture_float

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

gallivm: fix a trivial txq issue for 2d shadow and cube shadow samplers

untested (couldn't get the piglit test to run even with version overrides)
but seemed blatantly wrong.
In any case it would only affect an error case which when it would happen
probably all hope is lost anyway.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

llvmpipe: support array textures

This adds array (1d,2d) texture support to llvmpipe.
Though probably should do something about 1d array textures requiring gobs
of memory (this issue is not strictly limited to arrays but it is probably
worse there).
Initial code by Jakob Bornecrantz <jakob@vmware.com>

Reviewed-by: José Fonseca <jfonseca@vmware.com>

gallivm: support array textures

Support 1d and 2d array textures (including shadow samplers),
and (as a side effect mostly) also shadow cube samplers.
Seems to pass the relevant piglit tests both for sampling and rendering
to (though some require version overrides).
Since we don't support render target indices rendering to array textures
is still restricted to a single layer at a time.
Also, the min/max layer in the sampler view (which is unnecessary for GL)
is ignored (always use all layers).

Reviewed-by: José Fonseca <jfonseca@vmware.com>

llvmpipe: Remove lp_build_blend_soa()

No longer used/necessary, as we always blend in AoS now.

Trivial.

llvmpipe: Eliminate color buffer swizzling.

Now dead code.

Also had to remove the show_tiles/show_subtiles because now the color
buffers are always stored in their native format, so there is no longer
an easy way to paint the tile sizes.

Depth-stencil buffers are still swizzled.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

llvmpipe: Only advertise unswizzled formats.

Update llvmpipe_is_format_supported and llvmpipe_is_format_unswizzled
so that only the formats that we can render without swizzling are
advertised.

We can still render all D3D10 required formats except
PIPE_FORMAT_R11G11B10_FLOAT, which needs to be implemented in a future
opportunity.

Removal of rendertarget swizzling will be done in a subsequent change.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

util/u_format: Kill util_format_is_array().

It is buggy (it was giving wrong results for some of the formats with
padding), and util_format_description::is_array already does precisely
what's intended.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

util/u_format: Tighten the meaning of is_array bit to exclude mixed type formats.

This is what we want in practice.

The only change is in PIPE_FORMAT_R8SG8SB8UX8U_NORM, which no longer is
considered an array format.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>

util/u_format: Fix format manipulation for big-endian

This patch fixes various format manipulation for big-endian
architectures.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Fix format manipulation for big-endian

This patch fixes various format manipulation for big-endian
architectures.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Add byte-swap construct calls

This patch adds two more functions in type conversions header:
* lp_build_bswap: construct a call to llvm.bswap intrinsic for an
  element
* lp_build_bswap_vec: byte swap every element in a vector base on the
  input and output types.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Fix vector constant for shuffle

This patch fixes the vector constant generation used for vector shuffle
for big-endian machines.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: clear Altivec NJ bit

This patch enforces the clear of NJ bit in VSCR Altivec register so
denormal numbers are handles as expected by IEEE standards.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Altivec floating-point rounding

This patch adds Altivec intrinsics for float vector types. It changes
the SSE specific definitions to a platform neutral and adds the calls
to Altivec intrinsic builder.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Altivec vector add/sub intrisics

This patch add correct vector addition and substraction intrisics when
using Altivec with PPC. Current code uses default path and LLVM backend
ends up issuing carry-out arithmetic instruction while it is expected
saturated ones.

It also includes a fix for PowerPC where char are unsigned by default,
resulting in bogus values for vector shifting.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Altivec vector max/min intrisics

This patch adds the PPC Altivec instrics max/min instruction for
supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32).

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Altivec pack/unpack intrisics

This patch adds PPC Altivec support for pack/unpack operations using Altivec
supported vector type (8xi8, 16xi16, 4xi32, 4xf32).

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

radeonsi: Bitcast result of packf16 intrinsic to float for export intrinsic.

Fixes 7 piglit tests, and prevents many more from crashing.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Christian König <christian.koenig@amd.com>

i965/vs: Move struct brw_compile (p) entirely inside vec4_generator.

The brw_compile structure contains the brw_instruction store and the
brw_eu_emit.c state tracking fields.  These are only useful for the
final assembly generation pass; the earlier compilation stages doesn't
need them.

This also means that the code generator for future hardware won't have
access to the brw_compile structure, which is extremely desirable
because it prevents accidental generation of Gen4-7 code.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Split final assembly code generation out of vec4_visitor.

Compiling shaders requires several main steps:

   1. Generating VS IR from either GLSL IR or Mesa IR
   2. Optimizing the IR
   3. Register allocation
   4. Generating assembly code

This patch splits out step 4 into a separate class named "vec4_generator."

There are several reasons for doing so:

   1. Future hardware has a different instruction encoding.  Splitting
      this out will allow us to replace vec4_generator (which relies
      heavily on the brw_eu_emit.c code and struct brw_instruction) with
      a new code generator that writes the new format.

   2. It reduces the size of the vec4_visitor monolith.  (Arguably, a lot
      more should be split out, but that's left for "future work.")

   3. Separate namespaces allow us to make helper functions for
      generating instructions in both classes: ADD() can exist in
      vec4_visitor and create IR, while ADD() in vec4_generator() can
      create brw_instructions.  (Patches for this upcoming.)

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Abort on unsupported opcodes rather than failing.

Final code generation should never fail.  This is a bug, and there
should be no user-triggerable cases where this could occur.

Also, we're not going to have a fail() method after the split.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Move uses of brw_compile from do_vs_prog to brw_vs_emit.

The brw_compile structure is closely tied to the Gen4-7 hardware
encoding.  However, do_vs_prog is very generic: it just calls out to
get a compiled program and then uploads it.

This isn't ultimately where we want it, but it's a step in the right
direction: it's now closer to the code generator.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Rework memory contexts for shader compilation data.

During compilation, we allocate a bunch of things: the IR needs to last
at least until code generation...and then the program store needs to
last until after we upload the program.

For simplicity's sake, just keep it all around until we upload the
program.  After that, it can all be freed.

This will also save a lot of headaches during the upcoming refactoring.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Pass the brw_context pointer into brw_compute_vue_map().

We used to steal it out of the brw_compile struct, but that won't be
initialized in time soon (and is eventually going away).

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Pass the brw_context pointer into vec4_visitor and do_vs_prog.

We used to steal it out of the brw_compile struct...but vec4_visitor
isn't going to have one of those in the future.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/vs: Move some functions from brw_vec4_emit.cpp to brw_vec4.cpp.

This leaves only the final code generation stage in brw_vec4_emit.cpp,
moving the payload setup, run(), and brw_vs_emit functions to brw_vec4.cpp.

The fragment shader backend puts these functions in brw_fs.cpp, so this
patch also helps with consistency.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

meta: Don't try to glOrtho when the draw buffer isn't initialized.

I ran across this while running a glGenerateMipmap() test.

_meta_GenerateMipmap sets MESA_META_TRANSFORM, which causes
_mesa_meta_begin to try and set a default orthographic projection.

Unfortunately, if the drawbuffer isn't set up, ctx->DrawBuffer->Width
and Height are 0, which just causes an GL_INVALID_VALUE error.

Fixes oglconform's fbo/mipmap.automatic, mipmap.manual, and
mipmap.manualIterateTexTargets.

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

docs: Mark some features in GL3.txt as done for r600

Signed-off-by: Marek Olšák <maraeo@gmail.com>

st/mesa: allow forward-compatible contexts and set Const.ContextFlags

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

st/mesa: add support for GL core profiles

The rest of the plumbing was in place already.

I have tested this by turning on all GL 3.1 features.
The drivers not supporting GL 3.1 will fail to create a core profile
as they should.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

configure.ac: remove -fomit-frame-pointer from LLVM flags

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

configure.ac: look for whole words in LLVM flags, not prefixes

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

configure.ac: consolidate stripping unwanted LLVM flags

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

configure.ac: print LLVM flags

to see what we're mixing with ours

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

util: add more memory debugging features

Add a DEBUG_FREED_MEMORY option to help catch use-after-free errors.
Add debug_memory_check() function which can be periodically called to
check that all known blocks are good.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

llvmpipe: Implement logic ops for the AoS path.

It was forgotten in the previous patch series, but it is trivial to
implement, based on the SoA path.

This fixes glean logicOp failures.

llvmpipe: Don't use dynamically sized arrays.

Unfortunately for MSVC arrays with a constant variable size are still
considered dynamically sized.

i965/gen4-5: Fix segfaults with stencil-only depth/stencil setups.

Fixes a ton of piglit regressions since the depthstencil fixes for gen6+.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57309
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Don't generate saturates over existing variable values.

Fixes a crash in http://workshop.chromeexperiments.com/stars/ on i965,
and the new piglit test glsl-fs-clamp-5.
We were trying to emit a saturating move into a uniform, which the code
generator appropriately choked on.  This was broken in the change in
32ae8d3b321185a85b73ff703d8fc26bd5f48fa7.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57166
NOTE: This is a candidate for the 9.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Add some minimal backend-IR dumping.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

llvmpipe: Update llvmpipe_is_format_unswizzled to reflect latest changes.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

llvmpipe: Enable vertex color clamping.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

llvmpipe: Unswizzled rendering.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Updated lp_build_const_mask_aos to input number of channels.

Also updated lp_build_const_mask_aos_swizzled to reflect this.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

util: Updated util_format_is_array to be more accurate.

Will allow formats with padding, e.g. RGBX.
Will now allow swizzled formats as long as the alpha is channel 3.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Added support for float to half-float conversion in lp_build_conv.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Changed lp_build_pad_vector to correctly handle scalar argument.

Removed the lp_type argument as it was unnecessary.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Add a function to generate lp_type for a format.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

gallivm: Add support for unorm16 in lp_build_mul.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

glcpp: Support #elif(expression) with no intervening space.

And add test cases to ensure that this works
- 110 verifies that glcpp rejects #elif<digits> which glcpp
  previously accepted.
- 111 verifies that glcpp accepts #if followed immediately by
  (, +, -, !, or ~.
- 112 does the same as 111 but for #elif.

See 17f9beb6 for #if change.
Reviewed-by: Carl Worth <cworth@cworth.org>

glcpp: Reject #version and #line not followed by whitespace

Fixes part of es3conform's preprocess16_frag test.
Reviewed-by: Carl Worth <cworth@cworth.org>

mesa: fix BlitFramebuffer between linear and sRGB formats

NOTE: This is a candidate for the stable branches.

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

gallivm: fix multiple lods with different min/mag filter and wide vectors

broken since 529fe420ba6836479619ba42e53665724755fc1c,
I forgot some code, only added the comment...
Fixes bug 57644.

radeonsi: Reinstate assertions against invalid colour/depth formats.

radeonsi now supports Z16 and doesn't fail these assertions anymore.

This partially reverts commit 7bba4879bb79719e22a18b52759b1d1d839c783c, but
leaves the error messages in place to allow diagnosing such problems even with
non-debugging builds.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

radeonsi: Re-enable Z16 depth buffers.

8 more piglits.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

radeonsi: remove redundant parameter in r600_init_surface

[ Cherry-picked from r600g commit f5ac60152b10b04d38e77db6b904dd50d1a54d6c ]

radeonsi: Use explicit stencil mipmap level offsets.

Extracted from r600g commit 428e37c2da420f7dc14a2ea265f2387270f9bee1.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: correct texture memory size for Z32F_S8X24

[ Cherry-picked from r600g commit ea72351a919c594e7f40e901dca42aebb866f8a6 ]

radeonsi: Depth/stencil fixes.

Adapted from r600g commit 018e3f75d69490598d61059ece56d379867f3995.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: Flesh out support for depth/stencil exports from the pixel shader.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: Fix sampler views for depth textures.

Consistently reference the flushed depth texture in the sampler view, not the
original one.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: Fix z/stencil texture creation.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
[ Cherry-picked from r600g commit b4f0ab0b22625ac1bb3cf16342039557c086ebae ]

scons: Build ws_xlib on Mac OS X.

Fixes this SCons build error on Mac OS X if X11 is found.

NameError: name 'ws_xlib' is not defined:
  File "SConstruct", line 144:
    duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
  File "scons-2.2.0/SCons/Script/SConscript.py", line 614:
    return method(*args, **kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 551:
    return _SConscript(self.fs, *files, **subst_kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "src/SConscript", line 34:
    SConscript('gallium/SConscript')
  File "scons-2.2.0/SCons/Script/SConscript.py", line 614:
    return method(*args, **kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 551:
    return _SConscript(self.fs, *files, **subst_kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "src/gallium/SConscript", line 135:
    'targets/libgl-xlib/SConscript',
  File "scons-2.2.0/SCons/Script/SConscript.py", line 614:
    return method(*args, **kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 551:
    return _SConscript(self.fs, *files, **subst_kw)
  File "scons-2.2.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "src/gallium/targets/graw-xlib/SConscript", line 9:
    ws_xlib,

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

configure.ac: Remove -O., -g and -Wall from LLVM_C{PP,XX}FLAGS.

Signed-off-by: Marek Olšák <maraeo@gmail.com>

vbo: move another line of code after declarations

Signed-off-by: Brian Paul <brianp@vmware.com>

vbo: move code after declarations to fix MSVC errors

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

vbo: minor whitespace fix

mesa: remove '(void) k' lines

Serves no purpose as the k parameter is used later in the code.

mesa/vbo: Check for invalid types in various packed vertex functions.

According to the ARB_vertex_type_2_10_10_10_rev specification:
"The error INVALID_ENUM is generated by VertexP*, NormalP*,
 TexCoordP*, MultiTexCoordP*, ColorP*, or SecondaryColorP if <type>
 is not UNSIGNED_INT_2_10_10_10_REV or INT_2_10_10_10_REV."

Fixes 7 subcases of oglconform's packed-vertex test.

v2: Add "gl" prefix to error messages (pointed out by Brian).
    Also rebase atop the ctx plumbing.

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

mesa/vbo: Support the ES 3.0 signed normalized scaling rules.

Traditionally, OpenGL has had two separate equations for converting from
signed normalized fixed-point data to floating point data.  One was used
primarily for vertex data, while the other was primarily for texturing
and framebuffer data.

However, ES 3.0 and GL 4.2 change this, declaring there's only one
equation to be used in all cases.  Unfortunately, it's the other one.

v2: Correctly convert 0b10 to -1.0, as pointed out by Chris Forbes.

Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

mesa/vbo: Plumb ctx through to the conv_i(10|2)_to_norm_float functions.

The rules for converting these values actually depend on the current
context API and version.  The next patch will implement those changes.

v2: Mark ctx as const, as suggested by Brian.

Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

mesa: Set transform feedback's default buffer mode to INTERLEAVED_ATTRIBS

Fixes part of es3conform's transform_feedback_init_defaults test.
NOTE: This is a candidate for the stable branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>

mesa: Return 0 for XFB_VARYING_MAX_LENGTH if no varyings

v2: Perform this count the same way as elsewhere in this file, per
    Brian Paul's review.

Fixes part of es3conform's transform_feedback_init_defaults test.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Brian Paul <brianp@vmware.com>

gallium/tests/trivial: updates for transfer functions changes

Fixes build error with configure option --enable-gallium-tests
introduced in 369e46888904c6d379b8b477d9242cff1608e30e

Compile tested only.

Reviewed-by: Marek Olšák <maraeo@gmail.com>

gallium/tests/trivial: updates for CSO interface changes

Fixes build error with configure option --enable-gallium-tests
introduced in ea6f035ae90895bd4ee3247408eb179dfdf96d22

Cc: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>

gallium/tests/trivial: updates for util_draw_vertex_buffer changes

Fixes build error with configure option --enable-gallium-tests
introduced in e73bf3b805de78299f1a652668ba4e6eab9bac94

Reviewed-by: Marek Olšák <maraeo@gmail.com>

util: Modified u_rect to default to memcpy.

Previously this function would assert if the format didn't fit an expected 4 channel format size.

Now will work with any format type with any amount of channels.

Signed-off-by: José Fonseca <jfonseca@vmware.com>

util/format: Fix bug in float to non-float conversion in u_format_pack.py.

Signed-off-by: José Fonseca <jfonseca@vmware.com>

gallivm: Fix bug in lp_build_one which would incorrectly return a vector for length 1.

Signed-off-by: José Fonseca <jfonseca@vmware.com>

glsl: Support unsigned integer constants in layout qualifiers.

Fixes es3conform's explicit_attrib_location_integer_constants.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-and-tested-by: Matt Turner <mattst88@gmail.com>

i965/fs: Move struct brw_compile (p) entirely inside fs_generator.

The brw_compile structure contains the brw_instruction store and the
brw_eu_emit.c state tracking fields.  These are only useful for the
final assembly generation pass; the earlier compilation stages doesn't
need them.

This also means that the code generator for future hardware won't have
access to the brw_compile structure, which is extremely desirable
because it prevents accidental generation of Gen4-7 code.

v2: rzalloc p, as suggested by Eric.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Split final assembly code generation out of fs_visitor.

Compiling shaders requires several main steps:

   1. Generating FS IR from either GLSL IR or Mesa IR
   2. Optimizing the IR
   3. Register allocation
   4. Generating assembly code

This patch splits out step 4 into a separate class named "fs_generator."

There are several reasons for doing so:

   1. Future hardware has a different instruction encoding.  Splitting
      this out will allow us to replace fs_generator (which relies
      heavily on the brw_eu_emit.c code and struct brw_instruction) with
      a new code generator that writes the new format.

   2. It reduces the size of the fs_visitor monolith.  (Arguably, a lot
      more should be split out, but that's left for "future work.")

   3. Separate namespaces allow us to make helper functions for
      generating instructions in both classes: ADD() can exist in
      fs_visitor and create IR, while ADD() in fs_generator() can
      create brw_instructions.  (Patches for this upcoming.)

Furthermore, this patch changes the order of operations slightly.
Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now:

   - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16
   - Generate final assembly code for both modes together

This is because the frontend work can be done independently, but final
assembly generation needs to pack both into a single program store to
feed the GPU.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Abort on unsupported opcodes rather than failing.

Final code generation should never fail.  This is a bug, and there
should be no user-triggerable cases where this could occur.

Also, we're not going to have a fail() method in a moment.

v2: Just abort() rather than assert, to cover the NDEBUG case
    (suggested by Eric).

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965: Make it possible to create a cfg_t without a backend_visitor.

All we really need is a memory context and the instruction list; passing
a backend_visitor is just convenient at times.

This will be necessary two patches from now.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Move uses of brw_compile from do_wm_prog to brw_wm_fs_emit.

The brw_compile structure is closely tied to the Gen4-7 hardware
encoding.  However, do_wm_prog is very generic: it just calls out to
get a compiled program and then uploads it.

This isn't ultimately where we want it, but it's a step in the right
direction: it's now closer to the code generator.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Pass the brw_context pointer into fs_visitor explicitly.

We used to steal it out of the brw_compile struct...but fs_visitor
isn't going to have one of those in the future.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Move brw_wm_compile::fp to fs_visitor.

Also change it from a brw_fragment_program to a gl_fragment_program,
since that seems to be what everything wants anyway.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/fs: Remove struct brw_shader * parameter to fs_visitor constructor.

We can easily recover it from prog, and this makes it clear that we
aren't passing additional information in.

v2: Use an if-statement rather than the ?: operator (suggested by Eric).

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>