mesa/st: enable ARB_gpu_shader5 if the reported GLSL version >= 400

The ARB_gpu_shader5 extension is made up of a lot of small sub-parts.
Instead of adding PIPE_CAP's for each of these, just rely on the GLSL
version reported by the pipe driver. The remaining extensions lend
themselves naturally to being checked through a single CAP.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
nvc0: increase GLSL level to 400 to enable ARB_gpu_shader5

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nouveau: add emacs dir-locals file for tabs/8-space indents

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
nouveau: only try to get new storage if there are any levels

This would try to allocate 0-sized bo's when the max level was below the
base level.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
ra: cleanup the public API

Previously, there were 3 entrypoints into parts of the actual allocator,
and an API called ra_allocate_no_spills() that called all 3. Nobody
would ever want to call any of the 3 entrypoints by themselves, so
everybody just used ra_allocate_no_spills(). So just make them static
functions, and while we're at it rename ra_allocate_no_spills() to
ra_allocate() since there's no equivalent "with spills," because the
backend is supposed to handle spilling.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ra: make the p, q test more efficient

We can store the q total that pq_test() would've calculated in the node
itself, updating it when we add a node to the stack. This way, we only
have to walk the adjacency list when we push a node on the stack (i.e.
when the p, q test succeeds) instead of every time we do the p, q test.

No difference in shader-db run times, but I'm keeping this in because
the q total that it calculates will also be used in the next few commits.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
ra: don't consider nodes for spilling we don't need to

Previously, we would consider any optimistically colored nodes for
spilling. However, spilling any optimistically colored nodes below the
node that we failed to color on the stack wouldn't help us make
progress, since it wouldn't help with allowing us to find a color for
the node currently failing to get colored. Only consider nodes
which were above the failing node on the stack for spilling, which
simplifies the logic, and comment the code better so people know what's
going on here.

No shader-db changes with BRW_MAX_GRF reduced to 90 (or with the normal
number of GRF's).

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
ra: optimistically color only one node at a time

Before, when we encountered a situation where we had to optimistically
color a node, we would immediately give up and push all the remaining
nodes on the stack in the order of their index - which is a random, and
potentially not optimal, order. Instead, choose one node to
optimistically color in ra_select(), and then once we've optimistically
colored it, keep on going as normal in the hopes that we've opened up
more avenues for the normal select phase to make progress. In cases with
high register pressure, this helps make the order we push things on the
stack much better, and therefore increase the chance that we can allocate
successfully.

total instructions in shared programs: 4545447 -> 4545401 (-0.00%)
instructions in affected programs:     1353 -> 1307 (-3.40%)
GAINED:                                124
LOST:                                  6

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
radeon/compute: Fix reported values for MAX_GLOBAL_SIZE and MAX_MEM_ALLOC_SIZE

There is a hard limit in older kernels of 256 MB for buffer allocations,
so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
to statisfy requirements of OpenCL.

CC: "10.2" <mesa-stable@lists.freedesktop.org>
radeon/compute: Report a value for PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE

CC: "10.2" <mesa-stable@lists.freedesktop.org>
radeonsi/compute: Update reference counts for buffers in si_set_global_binding()

CC: "10.2" <mesa-stable@lists.freedesktop.org>
radeonsi/compute: Call si_pm4_free_state() after emitting compute state

This will decrement the reference count for buffers referenced in the
command stream will prevent us from leaking them.

CC: "10.2" <mesa-stable@lists.freedesktop.org>
radeonsi/compute: Whitespace fixes

CC: "10.2" <mesa-stable@lists.freedesktop.org>
radeonsi/compute: Stop leaking the input buffer

We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.

CC: "10.2" <mesa-stable@lists.freedesktop.org>
clover: Flush the command queue in clReleaseCommandQueue()

This is required by the spec.

Reviewed-by: Francisco Jerez <currojerez@riseup.net>

CC: "10.2" <mesa-stable@lists.freedesktop.org>
r300g: Fix bug in build_loop_info()/compiler v2

Fixes piglit glean "do-loop with continue and break" on RS690

It's based on Tom Stellard patch and improved to handle CMP instruction.

[v2] handle CMP instruction

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: David Heidelberger <david.heidelberger@ixit.cz>
winsys/radeon: fix hawaii accel_working2 comment

accel_working2 returns 3 if the new firmware is used.

The comment wasn't updated in v3 of commit:
36771dc winsys/radeon: fix nop packet padding for hawaii

Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
mesa: fix texstore with GL_COLOR_INDEX data

This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
hud: don't overrun malloced arrays

==17630== Invalid read of size 4
==17630==    at 0x400AE10: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630==    by 0x49024A2: u_upload_data (u_upload_mgr.c:253)
==17630==    by 0x49050E1: u_vbuf_draw_vbo (u_vbuf.c:980)
==17630==    by 0x487DE29: cso_draw_vbo (cso_context.c:1425)
==17630==    by 0x487DEA0: cso_draw_arrays (cso_context.c:1445)
==17630==    by 0x48A3B0E: hud_draw_colored_prims.constprop.6 (hud_context.c:123)
==17630==    by 0x48A4810: hud_draw (hud_context.c:266)
==17630==    by 0x48763F7: dri_flush (dri_drawable.c:483)
==17630==    by 0x4057510: dri2Flush.constprop.4 (dri2_glx.c:559)
==17630==    by 0x405789E: dri2SwapBuffers (dri2_glx.c:851)
==17630==    by 0x402C531: glXSwapBuffers (glxcmds.c:842)
==17630==    by 0x8049716: ??? (in /usr/bin/glxgears)
==17630==  Address 0x4426b2c is 4 bytes after a block of size 1,008 alloc'd
==17630==    at 0x4006B11: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630==    by 0x48A4CE7: hud_pane_add_graph (hud_context.c:625)
==17630==    by 0x48A68F0: hud_pipe_query_install (hud_driver_query.c:175)
==17630==    by 0x48A6A30: hud_driver_query_install (hud_driver_query.c:207)
==17630==    by 0x48A5835: hud_create (hud_context.c:791)
==17630==    by 0x48756CB: dri_create_context (dri_context.c:165)
==17630==    by 0x4871CD4: driCreateContextAttribs (dri_util.c:435)
==17630==    by 0x4871E06: driCreateNewContext (dri_util.c:464)
==17630==    by 0x4056A22: dri2_create_context (dri2_glx.c:223)
==17630==    by 0x402CF68: CreateContext (glxcmds.c:299)
==17630==    by 0x402D265: glXCreateContext (glxcmds.c:430)
==17630==    by 0x804B136: ??? (in /usr/bin/glxgears)

This is due to second vertex element being specified, and the upload
tries to fetch over the end. However the pane rendering only requires
a single vertex element, so specify only one.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
docs/GL3.txt: add GLES 3.1 section

This just cherry-pick the extensions into a list for GLES 3.1

I'm not actually sure if this list if complete or correct, maybe someone
else can tell me what I missed, and I'm not 100% sure on multi_draw_indirect.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>