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>

glapi: add plumbing for GL_ARB_draw_indirect and GL_ARB_multi_draw_indirect

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 indirect drawing buffer parameter to draw functions

Split from patch implementing ARB_draw_indirect.

v2: Const-qualify the struct gl_buffer_object *indirect argument.
v3: Fix up some more draw calls for new argument.
v4: Fix up rebase conflicts in i965.
v5: Undo const-qualification

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

docs/llvmpipe: Add one other good reference.

docs: describe the INTEL_* envvars that do exist

V2: drop description of `fall` and `wm`, which have been removed by the
previous patch; describe `stats`.

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

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

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

i965: remove unused DEBUG_IOCTL

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

radeon: change last instance of DEBUG_IOCTL to use RADEON_IOCTL

DEBUG_IOCTL comes from i965, and is about to be removed. Both defines
have the same value (4).

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

docs: drop INTEL_* envvars which no longer exist

These were removed back in 2012.

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

docs: bump supported shading language version

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

st/mesa: respect higher GLSL levels. (v2)

Limit the max glsl version level to what the state tracker supports.

Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

glsl: Improve error message when attemping assignment to unsized array

V2: Return after error to avoid cascading error messages and
removed redundant "to" from error message

Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

intel: enable GL_AMD_vertex_shader_layer extension for gen7+

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

radeonsi: implement MSAA for CIK

There are also some changes to the printfs.

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

radeonsi: enable 2D tiling on CIK

libdrm does the DRM version check and decides if 2D tiling is used.

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

mesa: initialize gl_renderbuffer::Depth in core

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

i965/fs: Make the first pre-allocation heuristic be the post heuristic.

I recently made us try two different things that tried to reduce register
pressure so that we would be more likely to allocate successfully.  But
now that we have the logic for trying two, we can make the first thing we
try be the normal, not-prioritizing-register-pressure heuristic.

This means one less scheduling pass in the common case of that heuristic
not producing spills, plus the best schedule we know how to produce, if
that one happens to succeed.  This is important, because our register
allocation produces a lot of possibly avoidable dependencies for the
post-register-allocation schedule, despite ra_set_allocate_round_robin().

GLB2.7: 1.04127% +/- 0.732461% fps improvement (n=31)
nexuiz: No difference (n=5)
lightsmark: 0.838512% +/- 0.300147% fps improvement (n=86)
minecraft apitrace: No difference (n=15)

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

mesa: Remove the ralloc canary on release builds.

The canary is basically just to give a better debugging message when you
ralloc_free() something that wasn't rallocated.  Reduces maximum memory
usage of apitrace replay of the dota2 demo by 60MB on my 64-bit system (so
half that on a real 32-bit dota2 environment).

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

i965: Fix streamed state dumping/annotation after the blorp-flush change.

I think I was thinking of the batch command packet cache when I pasted
this in, but this counter is only used for dumping out streamed state for
INTEL_DEBUG=batch and for putting annotations in our aub files.

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

i965: Let driconf clamp_max_samples affect context version

Commit 2f89662 added the driconf option 'clamp_max_samples'.  In that
commit, the option did not alter the context version. The neglect to
alter the context version is a fatal issue for some apps.

For example, consider running Chromium with clamp_max_samples=0.
Pre-patch, Mesa creates a GL 3.0 context but clamps GL_MAX_SAMPLES to
0. This violates the GL 3.0 spec, which requires GL_MAX_SAMPLES >= 4.
The spec violation causes WebGL context creation to fail in many
scenarios because Chromium correctly assumes that a GL 3.0 context
supports at least 4 samples.

Since the driconf option was introduced largely for Chromium, the issue
really needs fixing.

This patch fixes calculation of the context version to respect the
post-clamped value of GL_MAX_SAMPLES. This in turn fixes WebGL on
Chromium when clamp_max_samples=0.

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

i965: Share code between intel_quantize_num_samples and clamp_max_samples

clamp_max_samples() and intel_quantize_num_samples() each maintained
their own list of which MSAA modes the hardware supports. This patch
removes the duplication by making intel_quantize_num_samples() use the
same list as clamp_max_samples(), the list maintained in
brw_supported_msaa_modes().

By removing the duplication, we prevent the scenario where someone
updates one list but forgets to update the other.

Move function `brw_context.c:static brw_supported_msaa_modes()` to
`intel_screen.c:(non-static) intel_supported_msaa_modes()` and patch
intel_quantize_num_samples() to use the list returned by that function.

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

i965: Terminate brw_supported_msaa_modes() list with -1, not 0

This simplifies the loop logic in a subsqequent patch that refactors
intel_quantize_num_samples() to use brw_supported_msaa_modes().

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

st/mesa: simplify writemask for emitting fog result

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

mesa: fix indentation in ffvertex_prog.c

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

tgsi: Prevent emission of instructions with empty writemask.

These degenerate instructions can often be emitted by state trackers
when the semantics of instructions don't match precisely.

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

tgsi: Rework calls to ureg_emit_insn().

Mere syntactical change.

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

docs: Add a section with recommended reading for llvmpipe development.

Several of links the were contributed by Keith Whitwell and Roland Scheidegger.

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

llvmpipe: (trivial) disable new accurate origin calculation

It looks like there's some bugs in it...

meta: Move declaration before code.

Fixes MSVC build.

meta.c(2411) : error C2143: syntax error : missing ';' before 'type'
meta.c(2411) : error C2143: syntax error : missing ')' before 'type'
meta.c(2411) : error C2065: 'layer' : undeclared identifier
meta.c(2411) : error C2059: syntax error : ')'
meta.c(2411) : error C2143: syntax error : missing ';' before '{'
meta.c(2413) : error C2065: 'layer' : undeclared identifier
meta.c(2415) : error C2065: 'layer' : undeclared identifier

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

mesa: Implement GL_FRAMEBUFFER_ATTACHMENT_LAYERED query.

From section 6.1.18 (Renderbuffer Object Queries) of the GL 3.2 spec,
under the heading "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE
is TEXTURE, then":

    If pname is FRAMEBUFFER_ATTACHMENT_LAYERED, then params will
    contain TRUE if an entire level of a three-dimesional texture,
    cube map texture, or one-or two-dimensional array texture is
    attached. Otherwise, params will contain FALSE.

Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/framebuffer-layered-attachments
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture-defaults

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
v2: Don't include "EXT" in the error message, since this query only
makes sensen in context versions that have adopted
glGetFramebufferAttachmentParameteriv().

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

mesa: Fix texture target validation for glFramebufferTexture()

Previously we were using the code path for validating
glFramebufferTextureLayer().  But glFramebufferTexture() allows
additional texture types.

Fixes piglit tests:
- spec/!OpenGL 3.2/layered-rendering/gl-layer-cube-map
- spec/!OpenGL 3.2/layered-rendering/framebuffertexture

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
v2: Clarify comment above framebuffer_texture().

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

i965: Fix fast clear of depth buffers.

From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

    When the Clear or ClearBuffer* commands are used to clear a
    layered framebuffer attachment, all layers of the attachment are
    cleared.

This patch fixes the fast depth clear path.

Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-depth".

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

i965: Fix blorp clear of layered framebuffers.

From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

    When the Clear or ClearBuffer* commands are used to clear a
    layered framebuffer attachment, all layers of the attachment are
    cleared.

This patch fixes the blorp clear path for color buffers.

Fixes piglit test "spec/!OpenGL 3.2/layered-rendering/clear-color".

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

i965: refactor blorp clear code in preparation for layered clears.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

meta: fix meta clear of layered framebuffers

From section 4.4.7 (Layered Framebuffers) of the GLSL 3.2 spec:

    When the Clear or ClearBuffer* commands are used to clear a
    layered framebuffer attachment, all layers of the attachment are
    cleared.

This patch fixes meta clears to properly clear all layers of a layered
framebuffer attachment.  We accomplish this by adding a geometry
shader to the meta clear program which sets gl_Layer to a uniform
value.  When clearing a layered framebuffer, we execute in a loop,
setting the uniform to point to each layer in turn.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

mesa: Track number of layers in layered framebuffers.

In order to properly clear layered framebuffers, we need to know how
many layers they have.  The easiest way to do this is to record it in
the gl_framebuffer struct when we check framebuffer completeness.

This patch replaces the gl_framebuffer::Layered boolean with a
gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is
not layered, and equal to the number of layers otherwise.

v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers
always have a defined value.  Fix factor of 6 error in the number of
layers in a cube map array.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

nvc0: inform kernel about buffers that screen_create touches

Prevents a GPU page fault if somehow the uniform bo gets evicted
before the screen_create pushbuf has been submitted.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

radeonsi/compute: Fix LDS size calculation

We need to include the number of LDS bytes allocated by the state tracker.

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

r600g/compute: Add a work-around for flushing issues on Cayman

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
https://bugs.freedesktop.org/show_bug.cgi?id=69321

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

glsl: Fix interstage uniform interface block link error detection.

Previously, we checked for interstage uniform interface block link
errors in validate_interstage_interface_blocks(), which is only called
on pairs of adjacent shader stages.  Therefore, we failed to detect
uniform interface block mismatches between non-adjacent shader stages.

Before the introduction of geometry shaders, this wasn't a problem,
because the only supported shader stages were vertex and fragment
shaders, therefore they were always adjacent.  However, now that we
allow a program to contain vertex, geometry, and fragment shaders,
that is no longer the case.

Fixes piglit test "skip-stage-uniform-block-array-size-mismatch".

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: Rename validate_interstage_interface_blocks() to
validate_interstage_inout_blocks() to reflect the fact that it no
longer validates uniform blocks.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v3: Make validate_interstage_inout_blocks() skip uniform blocks.

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

glsl: Fix cross-version linking between VS and GS.

Previously, when attempting to link a vertex shader and a geometry
shader that use different GLSL versions, we would sometimes generate a
link error due to the implicit declaration of gl_PerVertex being
different between the two GLSL versions.

This patch fixes that problem by only requiring interface block
definitions to match when they are explicitly declared.

Fixes piglit test "shaders/version-mixing vs-gs".

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: In the interface_block_definition constructor, move the assignment
to explicitly_declared after the existing if block.

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

glsl: Prohibit illegal mixing of redeclarations inside/outside gl_PerVertex.

From section 7.1 (Built-In Language Variables) of the GLSL 4.10
spec:

    Also, if a built-in interface block is redeclared, no member of
    the built-in declaration can be redeclared outside the block
    redeclaration.

We have been regarding this text as a clarification to the behaviour
established for gl_PerVertex by GLSL 1.50, so we apply it regardless
of GLSL version.

This patch enforces the rule by adding an enum to ir_variable to track
how the variable was declared: implicitly, normally, or in an
interface block.

Fixes piglit tests:
- gs-redeclares-pervertex-out-after-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-global-redeclaration.vert
- gs-redeclares-pervertex-out-after-other-global-redeclaration.geom
- vs-redeclares-pervertex-out-after-other-global-redeclaration.vert
- gs-redeclares-pervertex-out-before-global-redeclaration
- vs-redeclares-pervertex-out-before-global-redeclaration

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
v2: Don't set "how_declared" redundantly in builtin_variables.cpp.
Properly clone "how_declared".

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

i965: Enable the AMD_performance_monitor extension on Gen5+.

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

i965: Take "bookend" OA snapshots at the start/end of each batch.

Unfortunately, our hardware only has one set of aggregating performance
counters shared between all 3D programs, and their values are not saved
or restored by hardware contexts.  Also, at least on Sandybridge and
Ivybridge, the counters lose their values if the GPU goes to sleep.

To work around both of these problems, we have to snapshot the
performance counters at the beginning and end of each batch, similar to
how we handle query objects on platforms that don't support hardware
contexts.  I call these "bookend" snapshots.

Since there can be multiple performance monitors active at a time, we
store the bookend snapshots in a global BO, shared by all monitors.

For monitors that span multiple batches, acquiring results involves
adding up three segments:

   BeginPerfMonitor   --> End of Batch 1    ("head")
   Start of Batch 2   --> End of Batch 2
                      ...                   ("middle")
   Start of Batch N-1 --> End of Batch N-1
   Start of Batch N   --> EndPerfMonitor    ("tail")

Monitors that refer to bookend BO snapshots are considered "unresolved".
We delay resolving them (and adding up deltas to obtain the results) as
long as possible to avoid blocking on mapping monitor->oa_bo.

We can also run out of space in the bookend BO, at which point we have
to resolve all unresolved monitors.  Then we can throw away the
snapshots and begin writing at the beginning of the buffer.

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

i965: Reserve batchbuffer space for a closing MI_REPORT_PERF_COUNT.

In order to use the Observability Architecture effectively, we'll need
to take snapshots of the OA counters via MI_REPORT_PERF_COUNT at the
start and end of each batch.

Experimentation reveals that we need to flush before and after each
MI_REPORT_PERF_COUNT to get working values.  For simplicitly, I chose to
use intel_batchbuffer_emit_mi_flush(), which unfortunately expands to
triple pipe controls on Sandybridge.

We may want to start computing per-generation reserved batch space to
avoid the insanity of Sandybridge's PIPE_CONTROL cost.  That said, much
of this cost existed before I rewrote the query object support to use
hardware contexts, so it's at least not entirely new.

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

i965: Add some plumbing for gathering OA results.

Currently, this only considers the monitor start and end snapshots.
This is woefully insufficient, but allows me to add a bunch of the
infrastructure now and flesh it out later.

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

i965: Start and stop OA counters as necessary.

We need to start OA at the beginning of each batch where monitors are
active.  OACONTROL isn't part of the hardware context, so to avoid
leaving counters enabled for other applications, we turn them off at the
end of the batch too.

We also need to start them at BeginPerfMonitor time (unless they've
already been started).  We stop them when the monitor last ends as well.

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

i965: Add functions to start and stop the OA counters.

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

i965: Add #defines for the OACONTROL register and fields.

We'll need to write this register to start/stop performance counters.

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

i965: Take OA counter snapshots at Begin/EndPerfMonitor time.

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

i965: Add a function to emit the MI_REPORT_PERF_COUNT packet.

MI_REPORT_PERF_COUNT writes a snapshot of the Observability Architecture
counters to a buffer.  Exactly how it works varies between generations:
Ironlake requires two packets, Sandybridge has to use GGTT, and Ivybridge
and later use PPGTT.

v2: Assert that we didn't use more space than we reserved (suggested
    by Eric Anholt).

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

i965: Track the number of monitors that need OA counters.

Using the OA counters requires some per-batch work.  When starting and
ending a batch, it's useful to know whether any monitors are actually
interested in OA data.

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

i965: Enumerate Observability Architecture counters on Gen5+.

In addition to listing the counter names, we include several "remap"
tables.  Confusingly, counters are documented with names like "A23",
are written to some buffer offset other than 23, and exposed by core
Mesa under a counter ID that is different still.

The first is inevitable; MI_REPORT_PERF_COUNT writes certain counters to
fixed locations in the buffer.  The latter could be avoided, but core
Mesa uses the "Counters" array index as the ID for a counter.  We could
do remapping there, but it would just complicate the core Mesa code.

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

i965: Expose pipeline statistics registers via performance monitors.

This is fairly simple:
- At BeginPerfMonitor time, take an opening snapshot.
- At EndPerfMonitor time, take a closing snapshot.
- The first time the application asks for results, subtract the two and
  store that value.  Then free the BO containing the snapshots.
- On subsequent requests for the results, just return the saved value.
- On reset, throw away the results.

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