mesa: update/remove display list comments

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

mesa: remove gl_dlist_node::next pointer to reduce dlist memory use

Now, sizeof(gl_dlist_node)==4 even on 64-bit systems.  This can
halve the memory used by some display lists on 64-bit systems.

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

mesa: begin reducing memory used by display lists

This is a first step in reducing memory used by display lists on
64-bit systems.  On 64-bit systems, the gl_dlist_node union type
is 8 bytes because of the 'data' and 'next' fields.  This causes
every display list node/token to occupy 8 bytes instead of 4 as
originally designed.  This basically doubles the memory used by
some display lists on 64-bit systems.

The fix is to remove the 64-bit 'data' and 'next' pointer fields
from the union and instead store them as a pair of 32-bit values.
Easily done with a few helper functions.

The next patch will take care of the 'next' field.

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

nouveau: Add lots of comments to the buffer transfer logic

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

nv50: wait on the buf's fence before sticking it into pushbuf

This resolves some rendering issues in source games.
See https://bugs.freedesktop.org/show_bug.cgi?id=64323

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>

nouveau: avoid leaking fences while waiting

This fixes a memory leak in some situations. Also avoids emitting an
extra fence if the kick handler does the call to nouveau_fence_next
itself.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>

nv50: fix a small leak on context destroy

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

docs: put MD5 sums in 9.2.4 relnotes file

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

docs: use --disable-dri3 for VMware guest driver build

For the time being at least.  Suggested by Adrian Rangel.

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

mesa: modified _mesa_align_free() to accept NULL pointer

So that it acts like ordinary free().  This lets us remove a bunch of
if statements where the function is called.

v2:
- Avoiding compile error on MSVC and possible warnings on other compilers.
- Added comment regards passing NULL pointer being safe.

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

mesa: don't leak performance monitors on context destroy

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>

nv50: Fix GPU_READING/WRITING bit removal

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
CC: "9.1, 9.2, 10.0" <mesa-stable@lists.freedesktop.org>

pipe-loader: Fix llvmpipe.la path

Fixes

 make[3]: *** No rule to make target `.../src/gallium/drivers/softpipe/libllvmpipe.la', needed by `pipe_swrast.la'.  Stop.

i965: Fix BRW_BATCH_STRUCT to specify RENDER_RING, not UNKNOWN_RING.

I missed this in the boolean -> enum conversion.  C cheerfully casts
false -> 0 -> UNKNOWN_RING.  On Gen4-5, this causes the render ring
prelude hook to get called in the middle of the batch, which is crazy.

BRW_BATCH_STRUCT is not used on Gen6+.

Fixes regressions since 395a32717df494353703f3581edcd3ba380f16d6
("i965: Introduce an UNKNOWN_RING state.").

Fixes "fips -v glxgears" on Ironlake.

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

Revert "i965: Move brw_emit_query_begin() to the render ring prelude."

This reverts commit a4bf7f6b6e612626c4e4fc21507ac213a7ba4b00.
It breaks occlusion queries on Gen4-5.  Doing this right will likely
require larger changes, which should be done at a future date.

Some Piglit tests still passed due to other bugs; fixing those revealed
this problem.

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

i965: Fix OACONTROL assertion failures on Ironlake.

I guarded half of the callers to start/stop_oa_counters with generation
checks, but missed the other half (which were added later).  OACONTROL
doesn't exist on Ironlake, so we better not write it.  Also, there's no
need---Ironlake's performance counters are always running.

This patch moves the generation checks into start/stop_oa_counters,
rather than requiring the caller to do them.

Fixes assertion failures in Piglit's AMD_performance_monitor/measure.

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

gallium/radeon: use PRIu64 macro for printing uint64_t

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

pipe-loader: build llvmpipe on top of softpipe

One can select if they want to fallback to softpipe.
Current approach makes this not possible, whereas other
targets (dri-swrast) handle this approapriately.

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

mesa: resolve typo DTXn/DXTn

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

automake: include only one copy VERSION in tarball

The VERSION file is tracked by git (git ls-files), thus
adding it to EXTRA_FILES will result in a duplicate copy
within the final tarball.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72230
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reported-by: Patrick Steinhardt <ps@pks.im>
Tested-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

glx: Add missing null check in gxl/dri2_glx.c

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

glx: Check malloc return value before accessing memory in glx/clientattrib.c

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

i965: Add extra-alignment for non-msrt fast color clear for all hw (v2)

The BSpec states that the aligment for the non-msrt clear rectangle must
be doubled; the BSpec does not restricit the workaround to specific
hardware.

Commit 9a1a67b applied the workaround to Haswell GT3.  Commit 8b659ce
expanded the workaround to all Haswell variants. This commit expands it
to all hardware.

No Piglit regressions on Ivybridge 0x0166. No fixes either.

I know no Ivybridge nor Baytrail bug related to this workaround.
However, the BSpec says the extra alignment is required, so let's do it.

v2: Apply to all hardware, not just gen7.

CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

configure.ac: require libdrm_radeon 2.4.50

st/mesa: implement layered framebuffer clear for the clear_with_quad fallback

Same approach as in u_blitter.

gallium/util: implement layered framebuffer clear in u_blitter

All bound layers (from first_layer to last_layer) should be cleared.

This uses a vertex shader which outputs gl_Layer = gl_InstanceID, so each
instance goes to a different layer. By rendering a quad and setting
the instance count to the number of layers, it will trivially clear all
layers.

This requires AMD_vertex_shader_layer (or PIPE_CAP_TGSI_VS_LAYER), which only
radeonsi supports at the moment. r600 could do this too. Standard DX11
hardware will have to use a geometry shader though, which has higher overhead.

gallium: add support for AMD_vertex_shader_layer

radeonsi: add driver support for layered rendering and AMD_vertex_shader_layer

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

radeonsi: implement OpenGL edge flags

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

st/mesa: add support for layered framebuffers and consolidate code

This is a subset of geometry shaders. It's all about setting first_layer and
last_layer correctly.

Also some code between st_render_texture and update_framebuffer_state is
consolidated. It doesn't use rtt_level and derives the level from dimensions
instead as the code in st_atom_framebuffer.c did.

mesa: expose AMD_vertex_shader_layer in the core profile only

It needs glFramebufferTexture, which isn't available in the compatibility
profile.

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

egl: add HAVE_LIBDRM define, fix EGL X11 platform

Commit a594cec broke EGL X11 backend by adding dependency between
X11 and DRM backends requiring HAVE_EGL_PLATFORM_DRM defined for X11.

This patch fixes the issue by adding additional define for libdrm
detection independent of which backend is being compiled. Tested by
compiling Mesa with '--with-egl-platforms=x11' and running es2gears_x11
+ glbenchmark2.7 successfully.

v2: return true for dri2_auth if running without libdrm (Samuel)
v3: check libdrm when building EGL drm platform + AM_CFLAGS fix (Emil)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72062
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: mesa-stable@lists.freedesktop.org

freedreno: Add a few texture formats

i965: Skip the register write check on Broadwell.

MI_STORE_REGISTER_MEM has to take a 48-bit address, so the existing code
doesn't work.  But supposedly Broadwell has a register whitelist and
just works out of the box anyway, so there's no need to check.

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

i965: Fix texture border color on Broadwell.

The Gen7 sampler state code still works.  Increasing the alignment to
64 bytes makes bit 5 zero, which is good because it's now reserved.

Since we don't use the new filter bits, we can leave those as zero too,
which means we don't need to update the code to update the pointer.
(We probably should anyway, for clarity, but alas, another day.)

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

i965: Don't use MACH for integer multiplies on Gen8+.

The documentation is really hard to follow, but apparently a 32-bit x
32-bit multiply just works without the MACH macro.  The macro apparently
is only necessary to get the full 64-bit value.

Fixes Piglit tests [vf]s-op-mult-int-int.shader_test.

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

i965: Fix texture swizzling on Broadwell.

Like Haswell, we do this in SURFACE_STATE rather than shader
workarounds.

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

i965: Set vertical alignment unit to 4 on Broadwell.

Broadwell doesn't support a surface vertical alignment of 2.  It only
supports VALIGN_4, VALIGN_8, or VALIGN_16.  I chose 4 since it's the
least wasteful.

v2: Replace my comment with a better one from Eric.  Move Broadwell
    checks earlier so it's more obvious that "return 2" won't be hit.

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

i965/vs: Always store pull constant offsets in GRFs on Gen8.

We need to SEND from a GRF, and we can only obtain those prior to
register allocation.

This allows us to do pull constant loads without the MRF hack.

v2: Reword comments (suggested by Paul).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

i965/vs: Don't copy propagate into SEND-from-GRF messages.

SEND can't deal with swizzles, source modifiers, and so on.  This should
avoid problems with VS pull constant loads on Broadwell.

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

clover: Fix missing minus sign in 'iterator_adaptor::operator-='.

The method is currently unused, this probably doesn't fix anything at
this point.

i965/hsw: Apply non-msrt fast color clear w/a to all HSW GTs

Pre-patch, the workaround was applied to only HSW GT3. However, the
workaround also fixes render corruption on the HSW GT1 Chromebook,
codenamed Falco.

Also, update the BSpec quote that discusses the workaround to reflect
the latest BSpec.

The BSpec states that the workaround is required for Ivybridge and
Baytrail as well as Haswell. But, we apply the workaround to only
Haswell because (a) we suspect that is the only hardware where it is
actually required and (b) we haven't yet validated the workaround for
the other hardware.

CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
OTC-Tracker: CHRMOS-812
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

glsl: Simplify the built-in function linking code.

Previously, we stored an array of up to 16 additional shaders to link,
as well as a count of how many each shader actually needed.

Since the built-in functions rewrite, all the built-ins are stored in a
single shader.  So all we need is a boolean indicating whether a shader
needs to link against built-ins or not.

During linking, we can avoid creating the temporary array if none of the
shaders being linked need built-ins.  Otherwise, it's simply a copy of
the array that has one additional element.  This is much simpler.

This patch saves approximately 128 bytes of memory per gl_shader object.

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

glsl: Create an accessor for the built-in function shader.

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

glsl: Drop crazy looping from no_matching_function_error().

Since the built-in functions rewrite, num_builtins_to_link is always either
0 or 1, so we don't need tho crazy loop starting at -1 with a special
case.

All we need to do is print the prototypes from the current shader, and
the single built-in function shader (if present).

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

glsl: Merge "candidates are: " message to the previous line.

Previously, when we hit a "no matching function" error, it looked like:

0:0(0): error: no matching function for call to `cos()'
0:0(0): error: candidates are: float cos(float)
0:0(0): error:                vec2 cos(vec2)
0:0(0): error:                vec3 cos(vec3)
0:0(0): error:                vec4 cos(vec4)

Now it looks like:

0:0(0): error: no matching function for call to `cos()'; candidates are:
0:0(0): error:    float cos(float)
0:0(0): error:    vec2 cos(vec2)
0:0(0): error:    vec3 cos(vec3)
0:0(0): error:    vec4 cos(vec4)

This is not really any worse and removes the need for the prefix variable.
It will also help with the next commit's refactoring.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

glsl: Drop unused call_ir parameter from generate_call().

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

glsl: Remove useless iteration through function parameters.

There's no need to loop through the "parameters" list and remove every
element; move_nodes_to(&parameters) already throws away all elements of
the destination list.

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

Fix 'make check' in src/mapi/glapi/tests when builddir != srcdir

make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests'
  CXX      check_table.o
/jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal error: glapi/glapitable.h: No such file or directory

We should look for the generated file glapi/glapitable.h in builddir, not srcdir

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>

docs: Import 10.0 release notes, add news item

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

i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.

On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel.  For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.

To work around this problem, sample from the source surface using
R32_FLOAT.  This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.

Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float

No piglit regressions on Sandy Bridge.

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

Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

glsl: Remove unused field loop_variable_state::loop.

This field was neither initialized nor used.  It was just dead memory.

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

glsl: Improve documentation of ir_loop counter/control fields.

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

glsl: In ir_validate, check that ir_loop::counter always refers to a new var.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time.  Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.

This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.

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

glsl: Fix inconsistent assumptions about ir_loop::counter.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).

However, previous to this patch:

(1) loop_control_visitor did not create a new variable for
    ir_loop::counter; instead it re-used the existing ir_variable.
    This caused the loop counter to be double-incremented (once
    explicitly by the body of the loop, and once implicitly by
    ir_loop::increment).

(2) ir_clone did not clone ir_loop::counter properly, resulting in the
    cloned ir_loop pointing to the source ir_loop's counter.

(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
    in the ir_variable being missed by reparenting.

Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).

The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times.  For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring).  At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object.  Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.

However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.

This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.

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

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

glsl: Teach ir_variable_refcount about ir_loop::counter variables.

If an ir_loop has a non-null "counter" field, the variable referred to
by this field is implicitly read and written by the loop.  We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.

Note: at the moment the dead code elimination bug doesn't occur due to
a bug in ir_hierarchical_visitor: it doesn't visit the "counter"
field, so dead code elimination doesn't treat it as a candidate for
elimination.  But the patch to follow will fix that bug, so we need to
fix ir_variable_refcount first in order to avoid breaking dead code
elimination.

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

mesa: fix mem leak of glPixelMap data in display list

And simplify save_PixelMapfv() by using the memdup() function.

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

mesa: added memory-related comment in save_error()

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

mesa: fix flags assignment in save_WaitSync()

The flags value is a bitfield so use the union's 'bf' field, not 'e'
(enum) field.  There's no actual change in behavior here since both
fields of the union are the same size.

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

mesa: remove old colortable, histogram, etc. code from dlist.c

Trying to compile any of these functions into a display list
now just generates a GL_INVALID_OPERATION error.

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

mesa: have old convolution functions generate GL_INVALID_OPERATION

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

mesa: have old glColorTable functions generate GL_INVALID_OPERATION

As is done for the old histogram functions.

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

trace: Dump PIPE_QUERY_* enums.

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

trace: Dump query results faithfully.

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

docs: Import 9.2.4 release notes, add news item.

gallium/cso: fix sampler / sampler_view counts

Now that it is possible to query drivers for the max sampler view it should
be safe to increase this without crashing.
Not entirely convinced this really works correctly though if state trackers
using non-linked sampler / sampler_views use this.

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

gallium: new shader cap bit for the amount of sampler views

Ever since introducing separate sampler and sampler view max this was really
missing.
Every driver but llvmpipe reports the same number as number of samplers for
now, so nothing should break.

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

gallium/drivers: support more sampler views than samplers for more drivers

This adds support for this to more drivers, in particular for all the "special"
ones useful for debugging.
HW drivers are left alone, some should be able to support it if they want but
they may not be interested at this point.

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

i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when __DRI2_ROBUSTNESS is not enabled

Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
GLX_ARB_create_context).

This fixes a regression in the piglit test
"glx/GLX_ARB_create_context/invalid flag"

v2: Remove commented debug code.  Noticed by Jordan.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>

Revert "drop old INTEL_DEBUG names for `perf` (fall) and `fs` (wm)"

This reverts commit 195994fe4cd851f4aed7fe32697f94c4188a96c8.

It wasn't sent to the list, Ken didn't review it, and it breaks
shader-db.

glsl: Link glcpp with math library.

This patch fixes this build error with Oracle Solaris Studio.

libtool: link: /opt/solarisstudio12.3/bin/cc -g -o glcpp/glcpp glcpp.o prog_hash_table.o  ./.libs/libglcpp.a
Undefined first referenced
 symbol       in file
sqrt                                prog_hash_table.o

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

i965: Always reserve binding table space for at least one render target.

In brw_update_renderbuffer_surfaces(), if there are no color draw
buffers, we always set up a null render target at surface index 0 so we
have something to use with the FB write marking the end of thread.

However, when we recently began computing surface indexes dynamically,
we failed to reserve space for it.  This meant that the first texture
would be assigned surface index 0, and our closing FB write would
clobber the texture.

Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5,
which regressed as of commit 4e5306453da6a1c076309e543ec92d999e02f67a
("i965/fs: Dynamically set up the WM binding table offsets.")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Tested-by: lu hua <huax.lu@intel.com>
Cc: "10.0" mesa-stable@lists.freedesktop.org

glsl: Initialize _mesa_glsl_parse_state::atomic_counter_offsets before using it.

Cc: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965/fs: Fix misleading comment.

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

i965: Bump number of supported atomic counter buffers.

Now that we have dynamic binding tables there's no good reason anymore
to expose so few atomic counter buffers.  Increase it to 16.

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

glsl/linker: Validate IR just before reparenting.

If reparent_ir() is called on invalid IR, then there's a danger that
it will fail to reparent all of the necessary nodes.  For example, if
the IR contains an ir_dereference_variable which refers to an
ir_variable that's not in the tree, that ir_variable won't get
reparented, resulting in subtle use-after-free bugs once the
non-reparented nodes are freed.  (This is exactly what happened in the
bug fixed by the previous commit).

This patch makes this kind of bug far easier to track down, by
transforming it from a use-after-free bug into an explicit IR
validation error.

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

glsl: Fix lowering of direct assignment in lower_clip_distance.

In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an
ir_rvalue_visitor), we failed to notice that since
lower_clip_distance_visitor overrides visit_leave(ir_assignment *),
ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called.
As a result, clip distance dereferences appearing directly on the
right hand side of an assignment (not in a subexpression) weren't
getting properly lowered.  This caused an ir_dereference_variable node
to be left in the IR that referred to the old gl_ClipDistance
variable.  However, since the lowering pass replaces gl_ClipDistance
with gl_ClipDistanceMESA, this turned into a dangling pointer when the
IR got reparented.

Prior to the introduction of geometry shaders, this bug was unlikely
to arise, because (a) reading from gl_ClipDistance[i] in the fragment
shader was rare, and (b) when it happened, it was likely that it would
either appear in a subexpression, or be hoisted into a subexpression
by tree grafting.

However, in a geometry shader, we're likely to see a statement like
this, which would trigger the bug:

    gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i];

This patch causes
lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the
base class visitor, so that the right hand side of the assignment is
properly lowered.

Fixes piglit test:
- spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy

Cc: Ian Romanick <idr@freedesktop.org>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965/gs: Set GS prog_data to NULL if there is no GS program.

The previous commit fixes a bug wherein we would incorrectly refer to
stale geometry shader prog_data when no geometry shader was active.

This patch reduces the likelihood of that sort of bug occurring in the
future by setting prog_data to NULL whenever there is no GS program.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/gs: Properly skip GS binding table upload when no GS active.

Previously, in brw_gs_upload_binding_table(), we checked whether
brw->gs.prog_data was NULL in order to determine whether a geometry
shader was active.  This didn't work: brw->gs.prog_data starts off as
NULL, but it is set to non-NULL when a geometry shader program is
built, and then never set to NULL again.  As a result, if we called
brw_gs_upload_binding_table() while there was no geometry shader
active, but a geometry shader had previously been active, it would
refer to a stale (and possibly freed) prog_data structure.

This patch fixes the problem by modifying
brw_gs_upload_binding_table() to use the proper technique to determine
whether a geometry shader is active: by checking whether
brw->geometry_program is NULL.

This fixes the crash reported in comment 2 of bug 71870 (the incorrect
rendering remains, however).

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

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

dri: Allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in driCreateContextAttribs

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>

i965: Only enable __DRI2_ROBUSTNESS if kernel support is available

Rather than always advertising the extension but failing to create a
context with reset notifiction, just don't advertise it.  I don't know
why it didn't occur to me to do it this way in the first place.

NOTE: Kristian requested that I provide a follow-up for master that
dynamically generates the list of DRI extensions instead of selected
between two hardcoded lists.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Suggested-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>

Revert "i965: Make the driver compile until a proper libdrm can be released."

libdrm 2.4.48 has been released.

This reverts commit bd4596efac2b783b789392a222da909efcd0fd3b.

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

i965: Bump libdrm requirement

drm_intel_get_reset_stats is only available in libdrm-2.4.48, and
libdrm-2.4.49 contains an important bug fix in that function.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>

egl: Kill macro _EGL_DECLARE_MUTEX

Replace all occurences of the macro with its expansion.

It seems that the macro intended to provide cross-platform static mutex
intialization. However, it had the same definition in all pre-processor
paths:
    #define _EGL_DECLARE_MUTEX(m) _EGLMutex m = _EGL_MUTEX_INITIALIZER

Therefore this abstraction obscured rather than helped.

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

egl: Enable EGL_EXT_client_extensions

Insert two fields into _egl_global to hold the client extensions and
statically initialize them:
    ClientExtensions // a struct of bools
    ClientExtensionString

Post-patch, Mesa supports exactly one client extension,
EGL_EXT_client_extensions.

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

radeon/compute: Unconditionally inline all functions v2

We need to do this until function calls are supported.

v2:
  - Fix loop conditional

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

CC: "10.0" <mesa-stable@lists.freedesktop.org>

i965: Use __attribute__((flatten)) on fast tiled teximage code.

The fast tiled texture upload code does not compile with GCC 4.8's -Og
optimization flag.

memcpy() has the always_inline attribute set.  This poses a problem,
since {x,y}tile_copy_faster calls it indirectly via {x,y}tile_copy,
and {x,y}tile_copy normally aren't inlined at -Og.

Using __attribute__((flatten)) tells GCC to inline every function call
inside the function, which I believe was the author's intent.

Fix suggested by Alexander Monakov.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: mesa-stable@lists.freedesktop.org

llvmpipe: support 8bit subpixel precision

8 bit precision is required by d3d10 but unfortunately
requires 64 bit rasterizer. This commit implements
64 bit rasterization with full support for 8bit subpixel
precision. It's a combination of all individual commits
from the llvmpipe-rast-64 branch.

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

gbm/dri: hide extension loader symbols

They should not be exposed.

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

i965: Enable ARB_draw_indirect (and ARB_multi_draw_indirect) on Gen7+

.. and mark them off on the extensions list as done.

V2: Enable only if pipelined register writes work.
V3: Also update relnotes

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

vbo: map indirect buffer and extract params if doing sw primitive restart

V2: Check for mapping failure (thanks Brian)
V3: - Change error on mapping failure to OUT_OF_MEMORY (Brian)
    - Unconst; remove casting away of const.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: pass indirect buffer to sw primitive restart

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

i965: pass indirect buffer to primitive restart check

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: implement indirect drawing for Gen7

Just prior to emitting the 3DPRIMITIVE command, we load each of the
indirect registers. The values loaded are either from offsets into the
current indirect BO, or constant zero if the parameter is not used for
this draw.

Enabling use of the indirect registers is done by turning on a bit in
the first dword of the 3DPRIMITIVE command itself.

V3: - Deduplicate the common part of both indexed and nonindexed indirect
setup.
    - Just refer to the indirect bo out of the context directly.

V4: - Fix bo reference to specify the range we care about.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Add new defines for indirect draws

- MMIO registers for draw parameters
- New bit in 3DPRIMITIVE command to enable indirection

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

vbo: Flesh out implementation of indirect draws

Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: add indirect_offset, is_indirect to _mesa_prim

V3: Add missing cases
V4: Add indirect_offset here too

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: Add validation helpers for new indirect draws

Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

V3: - Disallow primcount==0 for DrawMulti*Indirect. The spec is unclear
      on this, but it's silly. We might go back on this later if it
      turns out to be a problem.

    - Make it clear that the caller has dealt with stride==0

V4: - Allow primcount==0 again.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: Add binding point for indirect buffer

Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: Add extension scaffolding for ARB_draw_indirect

We will reuse the same extension flag for ARB_multi_draw_indirect since
it can always be supported by looping.

Based on part of Patch 2 of Christoph Bumiller's ARB_draw_indirect series.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>