i965: Move device quirks to brw_device_info.

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

i965: Move hardware limits to brw_device_info.

Since each kind of device has its own brw_device_info structure, we can
simply store the URB and thread limits there.  This eliminates all the
large if-ladders, and simplifies the context initialization code quite a
bit.

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

i965: Replace some intel_screen fields with brw_device_info references.

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

i965: Delete the INTEL_SEPARATE_STENCIL override.

This option was useful during initial development, but it's been ages
since I've heard of anyone using it.  Plus, Gen7+ mandates separate
stencil, so it was really only useful on Sandybridge anyway.

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

i965: Add a new brw_device_info structure.

The idea is that struct brw_device_info should store statically-known
information about hardware features.  Using the new family name in the
PCI ID table, we can easily grab the right structure.

This is basically the equivalent of intel_device_info in the kernel.

This patch also makes the new structure available from intel_screen, but
nothing uses it.  Right now, it looks very redundant with existing
fields, but that will change.

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

i965: Add the family name to the PCI ID table.

I removed this a while ago, since we never used it, but I'm finally
resurrecting the idea in the next commits.

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

i965: Remove #define name from PCI ID table.

Nothing uses the #define name, and it's not terribly useful - the
numerical ID serves the same purpose.  The only thing we could really do
with it is generate slightly prettier preprocessed code.  But who looks
at that?

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

i965: Pull most driconf option handling into a centralized function.

Using a helper function clarifies the context initialization code.

I would've liked to completely centralize it, but moving the optionCache
code from intelInitExtensions into here would've required setting flags
in the context, which seems like a waste.

v2: Rebase for the introduction of disable_derivative_optimization.

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

i965: Move a bunch of code from intelInitContext to brwCreateContext.

Now that intelInitContext isn't shared between i915 and i965, the split
is fairly arbitrary.  This patch moves a bunch of the basic context
creation and generation checking code up to the top-level function
(and slightly earlier).

More will follow.

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

i965: Update the comment about viewport hacks.

It wasn't clear that this was necessary for EGL, or why.

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

i965: Pull out INTEL_DEBUG handling into new intel_debug.[ch] files.

Now that there isn't an intel_context structure, the split between
brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary.
Removing intel_context.[ch] seems desirable, but not everything really
belongs in brw_context.[ch], either.

Moving INTEL_DEBUG handling into separate intel_debug.[ch] files should
make them relatively easy to find.

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

i965: Rename brwCreateContext's error parameter to dri_ctx_error.

"error" is a very generic name.  dri_ctx_error is the name used in
intelInitContext(), which is more specific.

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

dri: Move i965-specific context flag logic to dri common.

Nobody else yet can do a forward context anyway, but others should be able
to do debug contexts, and those would have just had no effect currently.

i915g: Fix assert

Now that we support start, assert on start + num < max samplers

Reported by xexaxo

mesa: Bump version to 10.0.0.

Mesa now supports OpenGL 3.2 and GLSL 1.50, so bump the Mesa major
version from 9 to 10 to reflect this.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa: Remove warning that geometry shader support is experimental.

Geometry shader support is now working well, and adequately piglit
tested.  There are just a few piglit failures left to fix.  So there's
no need for an "experimental" warning anymore.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.

Geometry shaders were the last thing we needed to finish before
turning on GLSL 1.50 and GL 3.2 support.  They are now working well,
with just a few piglit failures left to fix.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

radeon/llvm: show LLVM disassembly when available

With code dump enabled LLVM may generate disassembly during compilation.
Show this disassembly when available and prefer it to SI bytecode dump.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jay Cornwall <jay@jcornwall.me>

softpipe: fix seamless cube filtering

Fix coord wrapping (and face selection too) in case of edges.
Unfortunately, the coord wrapping is way more complicated than what
the code did, as it depends on the face and the direction where the
texel falls off the face (the logic needed to get this right in fact
seems utterly ridiculous).
Also fix a bug in (y direction under/overflow) face selection.
And get rid of complicated cube corner handling. Just like edge case,
the coord wrapping was wrong and it seems very difficult to fix.
I'm near certain it can't always work anyway (though ordinary seamless
filtering on edge has actually a similar problem but not as severe)
because we don't have per-pixel face, hence could have multiple corner
texels which would make it very difficult to average the remaining texels
correctly. Hence simply pick a texel which would only have fallen off one
edge but not both instead, which is not quite accurate but actually I think
should be enough to meet OpenGL (but not d3d10) requirements.

v2: small fixes suggested by Brian, add some comments.

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

llvmpipe: increase fs shader variant instruction cache limit by factor 4

The previous limit of of 128*1024 was reported to cause frequent recompiles
in some apps due to shader variant thrashing on IRC in some apps leading
to noticeable lags.
Note that the LP_MAX_SHADER_VARIANTS limit (1024) was more or less impossible
to reach, since even simple fragment shaders without texturing (glxgears) used
more than twice than 128 instructions, hence the instruction limit would have
always been reached first (excluding things like trivial shaders not writing
color). Even with the new limit it is VERY likely the instruction limit is hit
first.
Should help with such lags due to recompiles (though other shader types have
their own limits, LP_MAX_SETUP_VARIANTS and DRAW_MAX_SHADER_VARIANTS, in
particular the latter seems a bit small (128)).

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

mesa: Do not use newlocale on NetBSD.

Fixes this build error.

  CC       imports.lo
../../src/mesa/main/imports.c: In function '_mesa_strtof':
../../src/mesa/main/imports.c:570:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'loc'
../../src/mesa/main/imports.c:570:20: error: 'loc' undeclared (first use in this function)
../../src/mesa/main/imports.c:570:20: note: each undeclared identifier is reported only once for each function it appears in
../../src/mesa/main/imports.c:572:7: error: implicit declaration of function 'newlocale'
../../src/mesa/main/imports.c:572:23: error: 'LC_CTYPE_MASK' undeclared (first use in this function)
../../src/mesa/main/imports.c:574:4: error: implicit declaration of function 'strtof_l'
../../src/mesa/main/imports.c:580:1: warning: control reaches end of non-void function

Signed-off-by: Vinson Lee <vlee@freedesktop.org>

svga: s/0/FALSE/

mesa: add comment to clarify ctx->Driver.MapBufferRange() return value

st/mesa: whitespace fixes in st_cb_bufferobjects.c

vbo: assorted minor clean-ups

Use GL_TRUE/FALSE instead of 1/0.  Remove extraneous parentheses.
Remove trailing whitespace.

glsl: fix signed/unsigned comparison warning

wayland: Only pass wl_drm instance to gbm when using gbm platform

wayland: Don't rely on static variable for identifying wl_drm buffers

Now that libEGL has been fixed to not leak all kinds of symbols, gbm
links to its own copy of the libwayland-drm.a helper library.  That means
we can't rely on comparing the addresses of a static vtable symbol in that
library to determine if a wl_buffer is a wl_drm_buffer.  Instead, we
move the vtable into the wl_drm struct and use that for comparing.

https://bugs.freedesktop.org/show_bug.cgi?id=69437

Cc: 9.2 <mesa-stable@lists.freedesktop.org>

glapi: Do not use backtrace on NetBSD.

execinfo.h is not available on NetBSD.

Fixes this bulid error.

  CC       glapi_gentable.lo
glapi_gentable.c:44:22: fatal error: execinfo.h: No such file or directory

Signed-off-by: Vinson Lee <vlee@freedesktop.org>

glsl: Remove extraneous .dir-locals.el

This was overriding the top-level .dir-locals.el causing some settings
(like forcing spaces instead of tabs!) to be lost.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

r600g: fix crash in set_framebuffer_state

We should be able to safely set the framebuffer state without a
fragment shader bound. bind_ps_state will take care of updating the
necessary state bits later.

v2: check in update_db_shader_control

mesa: Allow external textures to use fallback (0, 0, 0, 1)

Fixes GL2ExtensionTests/egl_image_external/TestSimpleUnassociated.test
which is part of gles2/3 conformance suite. Here image external
textures are switched to be treated the same as 2D textures. These
can be associated with the fallback texture providing fixed sample
values of (0, 0, 0, 1).

The OES_EGL_image_external spec says:

  "Sampling an external texture which is not associated with any EGLImage
   sibling will return a sample value of (0,0,0,1)."

  "External textures cannot be used with TexImage2D, TexSubImage2D,
   CompressedTexImage2D, CompressedTexSubImage2D, CopyTexImage2D, or
   CopyTexSubImage2D, and an INVALID_ENUM error will be generated if
   this is attempted."

And quoting Chad:

  "That's enforced in _mesa_TexImage*() by calling
   legal_teximage_target(), and enforced in _mesa_TexSubImage*() by
   calling legal_texsubmimage_target(). Each of the
   legal_tex*image_target() functions reject external textures.
   Therefore, allowing GL_TEXTURE_EXTERNAL_OES in store_texsubimage()
   won't violate the above spec quote.

   I think it's safe to allow GL_TEXTURE_EXTERNAL_OES in
   store_texsubimage(), as long as the texture has only a single
   plane. Luckily, that's the only type of external textures that
   Mesa currently supports."

CC: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>

doxygen: Add i965 to list of modules in html header

Signed-off-by: Chad Versace <Chad Versace chad@chad-versace.us>

i965: extend fast texture upload

Extend the fast texture upload from BGRA X-tiled to include RGBA,
Alpha/Luminance, and Y-tiled.  Speed improvements, measured with
mesa demos teximage program, on 256 x 256 texture, in MB/s, on a
Sandy Bridge (Ivy is comparable):

              before  after   increase
BGRA/X-tiled   3266    4524    1.39x
BGRA/Y-tiled   1739    3971    2.28x
RGBA/X-tiled    474    4694    9.90x
RGBA/Y-tiled    477    3368    7.06x
   L/X-tiled   1268    1516    1.20x
   L/Y-tiled   1439    1581    1.10x

v2: Cosmetic changes only: reformat and reword comments, make doxygen-friendly,
    rename variables, use existing macros, add an assert.

Signed-off-by: Frank Henigman <fjhenigman@google.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>

haiku: Fix llvmpipe and clean up softpipe tracing

* Fix LLVM library and defines
* Only enable tracing when scons build=debug

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

haiku: Remove common directory search path

* /boot/common no longer exists in Haiku as of
  a few days ago (and this is undefined)

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

dri: Reference the global driver vtable once at screen init..

This is part of the prep for megadrivers, which won't allow using a single
global symbol due to the fact that there will be multiple drivers built
into the same dri.so file.  For that, we'll need screen init to take a
reference to the driver to set up this vtable.

v2: Fix two missed references to driDriverAPI.

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

i965: Clean up error handling for context creation.

The intel_screen.c used to be a dispatch to one of 3 driver functions, but
was down to 1, so it was kind of a waste.  In addition, it was trying to
free all of the data that might have been partially freed in the kernel
3.6 check (which comes after intelInitContext, and thus might have had
driverPrivate set and result in intelDestroyContext() doing work on the
freed data).  By moving the driverPrivate setup earlier, we can use
intelDestroyContext() consistently and avoid such problems in the future.

v2: Adjust the prototype of brwCreateContext to use the proper enum
    (fixing a compiler warning in some builds)

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

intel: Remove silly check for !bufmgr.

If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place.  This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.

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

dri: Move API version validation into dri/common.

i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the
same logic, except where they failed to.  Notably, swrast had code that
appeared to try to enable GLES1/2 but forgot to set api_mask (thus
preventing any gles context from being created), and the non-intel drivers
didn't support MESA_GL_VERSION_OVERRIDE.

nouveau still relies on _mesa_compute_version(), because I don't know what
its limits actually are, and gallium drivers don't declare limits up front
at all.  I think I've heard talk about doing so, though.

v2: Compat max version should be 30 (noted by Ken)
    Drop r100's custom max version check, too (noted by Emil Velikov)

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

dri: Merge drisw_util.c into dri_util.c

The only important difference was not calling drmGetVersion, and making
the swrast extension vtable.  That doesn't justify duplicating the other
330 lines of code.

v2: fix the scons build (code by Emil Velikov)
v3: fix scons build with swrast-only (code by Emil Velikov)
v4: Drop the new define I added, when we already have __NOT_HAVE_DRM_H.

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

dri: Add an explanatory comment for an important driver entrypoint.

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

dri: Remove dead comment.

The code it was referencing was removed in 2010.

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

i965/fs: Convert gen7 to using GRFs for texture messages.

Looking at Lightsmark's shaders, the way we used MRFs (or in gen7's
case, GRFs) was bad in a couple of ways.  One was that it prevented
compute-to-MRF for the common case of a texcoord that gets used
exactly once, but where the texcoord setup all gets emitted before the
texture calls (such as when it's a bare fragment shader input, which
gets interpolated before processing main()).  Another was that it
introduced a bunch of dependencies that constrained scheduling, and
forced waits for texture operations to be done before they are
required.  For example, we can now move the compute-to-MRF
interpolation for the second texture send down after the first send.

The downside is that this generally prevents
remove_duplicate_mrf_writes() from doing anything, whereas previously
it avoided work for the case of sampling from the same texcoord twice.
However, I suspect that most of the win that originally justified that
code was in avoiding the WAR stall on the first send, which this patch
also avoids, rather than the small cost of the extra instruction.  We
see instruction count regressions in shaders in unigine, yofrankie,
savage2, hon, and gstreamer.

Improves GLB2.7 performance by 0.633628% +/- 0.491809% (n=121/125, avg of
~66fps, outliers below 61 dropped).

Improves openarena performance by 1.01092% +/- 0.66897% (n=425).

No significant difference on Lightsmark (n=44).

v2: Squash in the fix for register unspilling for send-from-GRF, fixing a
    segfault in lightsmark.

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

i965/fs: Allocate more register classes on gen7.

For texturing from GRFs, we now have payloads of arbitrary sizes up to the
message length limit.

v2 (Kenneth Graunke): Rebase on intel_context -> brw_context change.
v3: Add some comment text.
v4: Change some magic 16s to BRW_MAX_MRF (noted by Ken).  Leave the 11,
    which is the magic "max sampler message length".  BRW_MAX_MRF sizing
    on the little int arrays is retained because I could see us needing to
    extend in the future if we move to GRFs for FB writes (those go to at
    least 12 long in a quick scan of the specs)

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
Acked-by: Matt Turner <mattst88@gmail.com>

i965/fs: Use per-channel interference for register_coalesce_2().

This will let us coalesce into texture-from-GRF arguments, which would
otherwise be prevented due to the live interval for the whole vgrf
extending across all the MOVs setting up the channels of the message

v2 (Kenneth Graunke): Rebase for renames.

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

i965/fs: Use the new per-channel live ranges for dead code elimination.

v2 (Kenneth Graunke): Rebase on s/live_variables/live_intervals/g.

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

i965/fs: Keep a copy of the live variables class around.

Now optimization passes will be able to look at the per-channel ranges.

v2: Rebase on various optimization pass changes.
v3 (Kenneth Graunke): Rename live_variables to live_intervals; split
   introduction of invalidate_live_intervals() into a separate patch.

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

i965/fs: Invalidate live intervals when compacting; don't fix them.

When compacting the list of VGRFs, we patch up the live interval ranges
(which are indexed by VGRF number).  Unfortunately, once we make
per-component data available, this will become too complicated to
maintain.  Instead, simply invalidate them.

This was pulled out of a patch by Eric Anholt.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Remove start/end aliases in compute_live_intervals().

In compute_live_intervals(), start and end are shorter names for
the virtual_grf_start and virtual_grf_end class members.

Now that the fs_live_intervals class has arrays named start and end
which are indexed by var, rather than VGRF, reusing the name is
confusing.  Plus, most of the code has been factored out, so using the
long names isn't as inconvenient.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Track live variable ranges on a per-channel level.

This is the information we'll actually use to replace the
virtual_grf_start[]/end[] arrays.

No change in shader-db.

v2 (Kenneth Graunke): Rebase; minor comment updates.

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

i965/fs: Factor def[]/use[] setup out to a separate function.

These blocks are about to grow some more code, and the indentation was
getting out of hand.

v2 (Kenneth Graunke): Rebase, minor typo fixes and style changes.

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

i965/fs: Create a helper function for invalidating live intervals.

For now, this simply sets live_intervals_valid = false, but in the
future it will do something more sophisticated.

Based on a patch by Eric Anholt.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Do live variables dataflow analysis on a per-channel level.

This significantly improves our handling of VGRFs of size > 1.

Previously, we only marked VGRFs as def'd if the whole register was
written by a single instruction.  Large VGRFs which were written
piecemeal would not be considered def'd at all, even if they were
ultimately completely written.

Without being def'd, these were then marked "live in" to the basic
block, often extending the range to preceding blocks and sometimes
even the start of the program.

The new per-component tracking gives more accurate live intervals,
which makes register coalescing more effective.

In the future, this should help with texturing from GRFs on Gen7+.
A sampler message might be represented by a 2-register VGRF which
holds the texture coordinates.  If those are incoming varyings,
they'll be produced by two PLN instructions, which are piecemeal writes.

No reduction in shader-db instruction counts.  However, code which
prints the live interval ranges does show that some VGRFs now have
smaller (and more correct) live intervals.

v2: Rebase on current send-from-GRF code requiring adding extra use[]s.
v3: Rebase on live intervals fix to include defs in the end of the
    interval.
v4 (Kenneth Graunke): Rebase; split off a few preparatory patches;
    add lots of comments; minor style changes; rewrite commit message.
v5 (Eric Anholt): whitespace nit.

Written-by: Eric Anholt <eric@anholt.net> [v1-3]
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [v4]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> (v4)

i965/fs: Rename num_vars to num_vgrfs in live interval analysis.

num_vars was shorthand for the number of virtual GRFs.  num_vgrfs is a
bit clearer.  Plus, the next patch will introduce "vars" which are
distinct from vgrfs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Short-circuit a loop in live variable analysis.

This has no functional effect, but should make subsequent changes a
little simpler.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

glsl: Don't allow gl_PerVertex to be redeclared after it's been used.

Fixes piglit tests:
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-in-after-other-usage.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-after-other-usage.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-after-usage.geom
- spec/glsl-1.50/compiler/vs-redeclares-pervertex-out-after-other-usage.vert
- spec/glsl-1.50/compiler/vs-redeclares-pervertex-out-after-usage.vert

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

glsl: Support redeclaration of GS gl_PerVertex input.

Fixes piglit test
spec/glsl-1.50/execution/redeclare-pervertex-subset-vs-to-gs.

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

glsl: Catch redeclaration of interface block instance names at compile time.

From section 4.1.9 (Arrays) of the GLSL 4.40 spec (as of revision 7):

    However, unless noted otherwise, blocks cannot be redeclared;
    an unsized array in a user-declared block cannot be sized
    through redeclaration.

The only place where the spec notes that interface blocks can be
redeclared is to allow for redeclaration of built-in interface blocks
such as gl_PerVertex.  Therefore, user-defined interface blocks can
never be redeclared.  This is a clarification of previous intent (see
Khronos bug 10659).

We were already preventing interface block redeclaration using the
same block name at compile time, but we weren't preventing interface
block redeclaration using the same instance name (and different block
names) at compile time.  And we weren't preventing an instance name
from conflicting with a previously-declared ordinary variable.

In practice the problem would be caught at link time, but only because
of a coincidence: since ast_interface_block::hir() wasn't doing any
checking to see if the instance name already existed in the shader, it
was creating a second ir_variable in the shader having the same name
but a different type.  Coincidentally, when the linker checked for
intrastage consistency of global variable declarations, it treated the
two declarations from the same shader as a conflict, so it reported a
link error.

But it seems dangerous to rely on that linker behaviour to catch
illegal redeclarations that really ought to be detected at compile
time.

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

glsl: Support redeclaration of VS and GS gl_PerVertex output.

Fixes piglit tests:
- spec/glsl-1.50/execution/redeclare-pervertex-out-subset-gs
- spec/glsl-1.50/execution/redeclare-pervertex-subset-vs

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

glsl: Error check redeclarations of gl_PerVertex.

This patch verifies that:

- The gl_PerVertex input interface block may only be redeclared in a
  geometry shader, and that it may only be redeclared as gl_in[].

- The gl_PerVertex output interface block may only be redeclared in a
  vertex or geometry shader, and that it may only be redeclared as a
  non-array without an interface name.

- gl_PerVertex may not be redeclared as any other type of interface
  block (i.e. as a uniform interface block).

As a side-effect, the code now keeps track of what the previous
declaration of gl_PerVertex was--this will be needed in future
patches.

Fixes piglit tests:
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-in-with-incorrect-name.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-as-array.geom
- spec/glsl-1.50/compiler/gs-redeclares-pervertex-out-with-instance-name.geom

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

glsl: Make it possible to disable a variable in the symbol table.

In later patches, we'll use this in order to implement the required
behaviour that after the gl_PerVertex interface block has been
redeclared, only members of the redeclared interface block may be
used.

v2: Update the function name and comment to clarify that we aren't
actually removing the variable from the symbol table, just disabling
it.

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

glsl: Add an ir_variable::reinit_interface_type() function.

This will be used by future patches to change an ir_variable's
interface type when the gl_PerVertex built-in interface block is
redeclared.

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

glsl: Generalize processing of variable redeclarations.

This patch modifies the get_variable_being_redeclared() function so
that it no longer relies on the ast_declaration for the variable being
redeclared.  In future patches, this will allow
get_variable_being_redeclared() to be used for processing
redeclarations of the built-in gl_PerVertex interface block.

v2: Also make get_variable_being_redeclared() static.

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

glsl: Don't allow invalid identifiers as struct names.

Fixes piglit test
spec/glsl-1.10/compiler/struct/struct-name-uses-gl-prefix.vert.

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

glsl: Don't allow invalid identifiers as interface block instance names.

Note: we need to make an exception for the gl_PerVertex interface
block, since in geometry shaders it is allowed to be redeclared with
the instance name gl_in.  Future patches will make redeclaration of
gl_PerVertex work properly.

Fixes piglit test
spec/glsl-1.50/compiler/interface-block-instance-name-uses-gl-prefix.vert.

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

glsl: Don't allow invalid identifier names in struct/interface fields.

Note: we need to make an exception for the gl_PerVertex interface
block, since built-in variables are allowed to be redeclared inside
it.  Future patches will make redeclaration of gl_PerVertex work
properly.

Fixes piglit tests:
- spec/glsl-1.50/compiler/interface-block-array-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/named-interface-block-elem-uses-gl-prefix.vert
- spec/glsl-1.50/compiler/unnamed-interface-block-elem-uses-gl-prefix.vert

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

glsl: Don't allow invalid identifiers as interface block names.

Note: we need to make an exception for the gl_PerVertex interface
block, since this is allowed to be redeclared.  Future patches will
make redeclaration of gl_PerVertex work properly.

Fixes piglit test
spec/glsl-1.50/compiler/interface-block-name-uses-gl-prefix.vert.

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

glsl: Don't allow unnamed interface blocks to redeclare variables.

Note: some limited amount of redeclaration is actually allowed,
provided the shader is redeclaring the built-in gl_PerVertex interface
block.  Support for this will be added in future patches.

Fixes piglit tests
spec/glsl-1.50/compiler/unnamed-interface-block-elem-conflicts-with-prev-{block-elem,global}.vert.

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

glsl: Refactor code to check that identifier names are valid.

GLSL reserves identifiers beginning with "gl_" or containing "__", but
we haven't been consistent about enforcing this rule.  This patch
makes a new function to check whether identifier names are valid.  In
the process it closes a loophole where we would previously allow
function argument names to contain "__".

v2: Rename check_valid_identifier() -> validate_identifier().  Add
curly braces in validate_identifier().

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

glsl: Account for location field when comparing interface blocks.

In commit e2660770731b018411fbe1620cacddaf8dff5287 (glsl: Keep track
of location for interface block fields), I neglected to update
glsl_type::record_key_compare to account for the fact that interface
types now contain location information.  As a result, interface types
that differ only by their location information would not be properly
distinguished.

At the moment this is not a problem, because the only interface block
in which location information != -1 is gl_PerVertex, and gl_PerVertex
is always created in the same way.  However, in the patches that
follow, we'll be adding new ways to create gl_PerVertex (by
redeclaring it), so we'll need location information to be handled
properly.

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

glsl: Construct gl_PerVertex interfaces for GS and VS outputs.

Although these interfaces can't be accessed directly by GLSL (since
they don't have an instance name), they will be necessary in order to
allow redeclarations of gl_PerVertex.

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

glsl: Refactor code for creating gl_PerVertex interface block.

Currently, we create just a single gl_PerVertex interface block for
geometry shader inputs.  In later patches, we'll also need to create
an interface block for geometry and vertex shader outputs.  Moving the
code into its own class will make reuse easier.

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

glsl: Fix block name of built-in gl_PerVertex interface block.

Previously, we erroneously used the name "gl_in" for both the block
name and the instance name.

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

glsl: Construct gl_in with a location of -1.

We use a location of -1 for variables which don't have their own
assigned locations--this includes ir_variables which represent named
interface blocks.  Technically the location assigned to gl_in doesn't
matter, since gl_in is only accessed via its members (which have their
own locations).  But it's nice to be consistent.

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

radeon/winsys: fix handling in radeon_drm_cs_flush v2

Calling radeon_drm_cs_flush from multiple threads might cause deadlocks,
fix this by immediately signaling the semaphore after waiting for it.

This is a candidate for the stable branch(es).

Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=70123

v2: some fixes on commit message

Signed-off-by: Christian König <christian.koenig@amd.com>

util: Fix MinGW build.

_GNU_SOURCE appears to not be used reliably.  Use _MSC_VER instead so
that MSVC alone is affected.

llvmpipe: We don't use the draw pipeline for offset_point/line.

Unless the polygon fill mode is different from PIPE_POLYGON_MODE_FILL,
so checking the the polygon mode is sufficient.

Testing done: no regression in polygon-mode-offset
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

gallivm: kill old per-quad face selection code

Not used since ages, and it wouldn't work at all with explicit derivatives now
(not that it did before as it ignored them but now the code would just use
the derivs pre-projected which would be quite random numbers).

v2: also get rid of 3 helper functions no longer used.

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

gallivm: handle explicit derivatives for cubemaps

They need some special handling. Quite complicated.
Additionally, use the same code for implicit derivatives too if no_rho_approx
and no_quad_lod is set, because it seems while generally it should be ok
to use per quad lod for implicit derivatives there's at least some test which
insists that in case of cubemaps the shared lod value MUST come from a pixel
inside the primitive (due to the derivatives becoming different if a different
larger major axis is chosen).

v2: based on Brian's feedback, clean up code a bit.
And use sign bit of major axis instead of pre-select s/t/r sign for coord
mirroring (which should be the same in the end, saves 2 ands).
Also fix two bugs with select/mirror of derivatives, the minor axes need to
use major axis sign as well (instead of major derivative axis sign), and
don't mistakenly use absolute values of major derivative and inverse major
values.

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

gallivm: ignore rho approximation for cube maps

There's two reasons for this:
1) even when ignoring rho approximation for cube maps, the result is still
not correct, but it's better as the max error at edges is now sqrt(2) instead
of 2 (which was a full mip level), same as it is for ordinary 2d maps when
doing rho approximations (so the error actually goes from factor 2 at edges and
sqrt(2) completely inside a face to sqrt(2) at edges and 0 inside a face).
2) I want to repurpose rho_no_approx for cubemaps for fully correct cubemap
derivatives (so don't need yet another debug var).

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

glsl: Modify array_sizing_visitor to handle unnamed interface blocks.

We were already setting the array size of unsized arrays that appeared
inside unnamed interface blocks, but we weren't updating
ir_variable::interface_type to reflect the new array size, causing
bogus link errors.

This patch causes array_sizing_visitor to keep track of all the
unnamed interface types it sees, and the ir_variables corresponding to
each one.  After the visitor runs, a new function,
fixup_unnamed_interface_types(), adjusts each unnamed interface type
to correctly correspond with the array sizes in the ir_variables.

Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block-gs
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block-multiple

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Update call_link_visitor to update max_ifc_array_access.

When multiple shaders of the same type access an interface block
containing an unsized array, we need to set the array size based on
the maximum array element accessed across all the shaders.  This is
similar to what we already do with unsized arrays occurring outside of
interface blocks.

Note: one corner case is not yet addressed by these patches: the case
where one compilation unit defines an interface block containing
unsized arrays and another compilation unit defines the same interface
block containing sized arrays.

Fixes piglit test:
- spec/glsl-1.50/execution/unsized-in-named-interface-block-multiple

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl/linker: Modify array_sizing_visitor to handle named interface blocks.

Unsized arrays appearing inside named interface blocks now get a
proper size assigned by the array_sizing_visitor.

Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-named-interface-block
- spec/glsl-1.50/execution/unsized-in-named-interface-block-gs
- spec/glsl-1.50/linker/unsized-in-named-interface-block
- spec/glsl-1.50/linker/unsized-in-named-interface-block-gs
- spec/glsl-1.50/linker/unsized-in-unnamed-interface-block-gs (*)

(*) is fixed by dumb luck--support for unsized arrays in unnamed
interface blocks will come in a later patch.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Update ir_variable::max_ifc_array_access properly.

This patch modifies update_max_array_access() so that it updates
ir_variable::max_ifc_array_access to reflect the shader's use of
arrays appearing within interface blocks.

v2: Use an ordinary function in ast_array_index.cpp rather than a
virtual function in ir_rvalue.  Avoid dereferencing NULL when handling
accesses to ordinary structs.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Sanity check max_ifc_array_access in ir_validate::visit(ir_variable *).

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Add an ir_variable::max_ifc_array_access field.

For interface blocks that contain arrays, this field will contain the
maximum element of each contained array that is accessed by the
shader.  This is a first step toward supporting unsized arrays in
interface blocks.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Make accessor functions for ir_variable::interface_type.

In a future patch, this will allow us to enforce invariants when the
interface type is updated.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Move update of max_array_access into a separate function.

Currently, when converting an access to an array element from ast to
IR, we need to see if the array is an ir_dereference_variable, and if
so update the variable's max_array_access.

When we add support for unsized arrays in interface blocks, we'll also
need to account for cases where the array is an ir_dereference_record
and the record is an interface block.

To make this easier, move the update into its own function.

v2: Use an ordinary function in ast_array_index.cpp rather than a
virtual function in ir_rvalue.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Add parser support for unsized arrays in interface blocks.

Although it's not explicitly stated in the GLSL 1.50 spec, unsized
arrays are allowed in interface blocks.

section 1.2.3 (Changes from revision 5 of version 1.5) of the GLSL
1.50 spec says:

    * Completed full update to grammar section.  Tested spec examples
      against it:

      ...

      * add unsized arrays for block members

And section 7.1 (Vertex and Geometry Shader Special Variables)
includes an unsized array in the built-in gl_PerVertex interface
block:

    out gl_PerVertex {
        vec4 gl_Position;
        float gl_PointSize;
        float gl_ClipDistance[];
    };

Furthermore, GLSL 4.30 contains an example of an unsized array
occurring inside an interface block.  From section 4.3.9 (Interface
Blocks):

    uniform Transform {  // API uses "Transform[2]" to refer to instance 2
        mat4           ModelViewMatrix;
        mat4           ModelViewProjectionMatrix;
        vec4           a[];  // array will get implicitly sized
        float          Deformation;
    } transforms[4];

This patch adds the parser rule to support unsized arrays inside
interface blocks.  Later patches in the series will add the
appropriate semantics to handle them.

Fixes piglit tests:
- spec/glsl-1.50/execution/unsized-in-unnamed-interface-block
- spec/glsl-1.50/linker/unsized-in-unnamed-interface-block

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

glsl: Rename the fourth argument to get_interface_instance.

Interface declarations have two names associated with them: the block
name and the instance name.  It's the block name that needs to be
passed to get_interface_instance().  This patch renames the argument
so that there's no confusion.

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

i965/blorp: Allow format conversions for CopyTexSubImage.

BLORP performs blits by drawing a rectangle with a shader that samples
from the source texture, and writes color data to the destination.

The sampler always returns 32-bit RGBA float data, regardless of the
source format's component ordering or data type.  Likewise, the render
target write message takes 32-bit RGBA float data, and converts it
appropriately.  So the bulk of the work is already taken care of for us.

This greatly accelerates a lot of CopyTexSubImage calls, and makes
Legends of Aethereus playable on Ivybridge.  At the default settings,
LOA continually blits between SRGBA8888 (the window format) and
RGBA16_FLOAT.  Since neither BLORP nor our BLT paths supported this,
it fell back to meta, spending 33% of the CPU in floorf() converting
between floats and half-floats.

v2: Use != instead of ^ (suggested by Ian).  Note that only
    CopyTexSubImage is affected by this patch (caught by Eric).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Rework sRGB override behavior.

The previous code for sRGB overrides assumes that the source and
destination formats are equal, other than the color space.  This won't
be feasible when we add support for format conversions.

Here are a few cases, and how the old code handled them:

1.  RGB8 -> SRGB8, MSAA     ==>   SRGB8 -> SRGB8
2.  RGB8 -> SRGB8, single   ==>    RGB8 -> RGB8
3. SRGB8 ->  RGB8, MSAA     ==>    RGB8 -> RGB8
4. SRGB8 ->  RGB8, single   ==>   SRGB8 -> SRGB8

Apparently, preserving the behavior of #1 is important.  When doing a
multisample to single-sample resolve, blending the samples together in
an sRGB correct fashion results in a noticably higher quality image.
It also is necessary to pass Piglit's EXT_framebuffer_multisample
accuracy color tests.

Paul, Eric, Anuj, and I talked about this, and aren't sure that it
matters in the other cases.

This patch preserves the behavior of #1, but otherwise reverts to
doing everything in linear space, changing the behavior of case #4.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Explain why Z24 can't use a sensible format.

We could conceivably use BRW_SURFACEFORMAT_R24_UNORM_X8_TYPELESS for
Z24 source images, allowing conversions from Z24 to either Z16 or Z32F.

Unfortunately, we can't use it for destination images since it isn't
supported as a render target.

Using different formats for sources or destinations would be painful,
so for now, punt.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Use R32_FLOAT for Z32F surfaces.

Currently, all that matters is that we copy the correct number of bits,
so any format that has 32-bits of data will work fine.

Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data.  We don't need a depth format, but we do
need the right number of components and data type (FLOAT).

For Z32F, this means using R32_FLOAT.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Use R16_UNORM for Z16 surfaces.

Currently, all that matters is that we copy the correct number of bits,
so any format that has 16-bits of data will work fine.

Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data.  We don't need a depth format, but we do
need the right number of components and data type (UNORM).

For Z16, this means using R16_UNORM.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Add support for non-render-target formats.

Once blorp gains the ability to do format conversions, it's conceivable
that the source format may be texturable but not supported as a render
target.  This would break Paul's code, which assumes that it can use the
render_target_format array even for the source format.

There are three ways to convert MESA_FORMAT enums to BRW_SURFACEFORMAT
enums:

1. brw_format_for_mesa_format()

   This translates the Mesa format to the most equivalent BRW format.

2. brw->render_target_format[]

   This is used for renderbuffers, and handles the subset of formats
   that are renderable.  However, it's not always equivalent, since
   it overrides a few non-renderable formats.  For example, it
   converts B8G8R8X8_UNORM to B8G8R8A8_UNORM so it can be rendered to.

3. translate_tex_format()

   This is used for textures.  It wraps brw_format_for_mesa_format(),
   but overrides depth textures, and one sRGB case on Gen4.

BLORP has a fourth function, which uses brw->render_target_format[]
and overrides depth formats (differently than translate_tex_format).

This patch makes the BLORP function to use brw_format_for_mesa_format()
for textures/source data, since not everything will be a render target.
It continues using brw->render_target_format[] for render targets, since
it needs the format overrides that provides.

We don't use translate_tex_format() since the additional overrides are
not useful or simply redundant.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i965/blorp: Add an is_render_target parameter to surface_info::set.

This allows us to determine whether we're setting up a format for
the source (as a texture) or destination (as a render target).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

util/u_math: Fix C++ include of u_math.h on MSVC.

GNU C++ compiler declares the C99 lrint, etc. when _GNU_SOURCE is
defined, but MSVC does not.

Trivial.

llvmpipe: abstract the code to set number of subpixel bits

As we're moving towards expanding the number of subpixel
bits and the width of the variables used in the computations
we need to make this code a bit more centralized.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>