dri3: Prefer the last chosen back when finding a new one.

With the buffer_age code, I need to be able to potentially call this more
than once per frame, and it would be bad if a new special event showing up
meant I chose a different back mid-frame.  Now, once we've chosen a back
for the frame, another find_back will choose it again since we know that
it won't have ->busy set until swap.

Note that this makes find_back return a buffer id instead of a backbuffer
index.  That's kind of a silly distinction anyway, since it's an identity
mapping between the two (it's the front buffer that is at an offset).

Reviewed-By: Adel Gadllah <adel.gadllah@gmail.com>
dri3: Add GLX_EXT_buffer_age support

v2: Indent according to Mesa style, reuse sbc instead of making a new
    swap_count field, and actually get a usable back before returning the
    age of the back (fixing updated piglit tests).  Changes by anholt.

Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1)
Reviewed-by: Adel Gadllah <adel.gadllah@gmail.com> (v2)
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Fix build warning of unused variable

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
nv50: add missing brackets when handling the samplers array

Commit 3805a864b1d(nv50: assert before trying to out-of-bounds access
samplers) introduced a series of asserts as a precausion of a previous
illegal memory access.

Although it failed to encapsulate loop within nv50_sampler_state_delete
effectively failing to clear the sampler state, apart from exadurating
the illegal memory access issue.

Fixes gcc warning "array subscript is above array bounds" and
"Nesting level does not match indentation" and "Out-of-bounds read"
defects reported by Coverity.

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
nouveau: typecast the prime_fd handle when calling nouveau_bo_set_prime

Core drm defines that the handle is of type int, while all drivers
treat it as uint internally. Typecast the value to silence gcc
warning messages and be consistent amongst all drivers.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
nouveau: honor fread return value in the nouveau_compiler

There is little point of continuing if fread returns zero, as it
indicates that either the file is empty or cannot be read from.
Bail out if fread returns zero after closing the file.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: minor cleanups in stream output handling

Constify the offsets parameter to silence gcc warning 'assignment
from incompatible pointer type' due to function prototype miss-match.

Use a boolean changed as a shorthand for target != current_target.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
mesa: return v.value_int64 when the requested type is TYPE_INT64

Fixes "Operands don't affect result" defect reported by Coverity.

Cc: "9.2 10.0 10.1"  <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
radeon: Move DMA ring creation to common code

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
radeonsi: flush the dma ring in si_flush_from_st

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
glapi: restore _glthread_GetID() function

This partially reverts patch 02cb04c68f.  This fixes an unresolved
symbol error when using older builds of libGL.

Tested-by: Chia-I Wu <olv@lunarg.com>
gallivm: use correct rounding for linear wrap mode (in the aos int path)

The previous method for converting coords to ints was sligthly inaccurate
(effectively losing 1bit from the 8bit lerp weight). This is probably
especially noticeable when trying to draw a pixel-aligned texture.
As an example, for a 100x100 texture after dernormalization the texture
coords in this case would turn up as
0.5, 1.5, 2.5, 3.5, 4.5, ...
After the mul by 256, conversion to int and 128 subtraction, they end up as
0, 256, 512, 768, 1024, ...
which gets us the correct coords/weights of
0/0, 1/0, 2/0, 3/0, 4/0, ...
But even LSB errors (which are unavoidable) in the input coords may cause
these coords/weights to be wrong, e.g. for a coord of 3.49999 we'd get a
coord/weight of 2/255 instead.

Fix this by using round-to-nearest int instead of FPToSi (trunc). Should be
equally fast on x86 sse though other archs probably suffer a little.
gallivm: use correct rounding for nearest wrap mode (in the aos int path)

The previous code used coords which were calculated as
(int) (f_coord * tex_size * 256) >> 8.
This is not only unnecessarily complex but can give the wrong texel due to
rounding for negative coords (as an example, after denormalization coords
from -1.0 to 0.0 should give -1, but this will give -1 for numbers from
-1.0-1/256 - 0.0-1/256.
Instead, juse use ifloor, dropping the shift stuff.
Unfortunately, this will most likely be slower - with arch rounding available
it shouldn't be too bad (trades a int shift for a round but also saves an int
mul (which is shared by all coords) but otherwise it's a mess.
gallivm: optimize repeat linear npot code in the aos int path

Similar to the other cases, shift some weight/coord calculations to int
space. This should be slightly faster (on x86 sse it should actually safe one
instruction, and generally int instructions are cheaper).
i965: Switch mapping modes for non-explicit-flush blit-temporary maps.

On LLC, it should always be better to use a cached mapping than the GTT.
On non-LLC, it seems pretty silly to try to optimize read performance for
the INVALIDATE_RANGE_BIT case.  This will make the buffer_storage logic
easier.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Drop the system-memory temporary allocations for flush explicit.

While in expected usage patterns nobody will ever hit this path, doubling
our bandwidth used seems like a waste, and it cost us extra code too.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Always use CPU mappings for BOs on LLC platforms.

It looks like there's no big difference for write-only workloads, but
using a CPU map means that if they happen to read without having set the
MAP_READ_BIT, they get 100x the performance for those reads.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Add support for GL_ARB_buffer_storage.

It turns out we can allow COHERENT storage/mappings all the time,
regardless of LLC vs non-LLC.  It just means never using temporary
mappings to avoid GPU stalls, and on non-LLC we have to use the GTT intead
of CPU mappings.  If we were to use CPU maps on non-LLC (which might be
useful if apps end up using buffer_storage on PBO reads, to avoid WC read
slowness), those would be PERSISTENT but not COHERENT, but doing that
would require us driving the clflushes from userspace somehow.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Improve debug output and variable names for opt_dead_code_local.

I know this code has confused others, and it confused me 3 years later,
too.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
i965/fs: Fix register comparisons in saturate propagation.

opt_saturate_propagation_local compares scan_inst->dst.reg/reg_offset
with inst->src[0].reg/reg_offset, and ensures that scan_inst->dst.file
is GRF.  But nothing ensured that inst->src[0].file was GRF.

In the following program, this resulted in u1:F matching vgrf1:UW,
and a saturate being incorrectly propagated from instruction 8 to
instruction 1.

{  1}    0: add vgrf0:UW, hw_reg1+8:UW, hw_reg0:V
{  1}    1: add vgrf1:UW, hw_reg1+10:UW, hw_reg0:V
{  1}    2: linterp vgrf6:F, hw_reg2:F, hw_reg3:F, hw_reg0:F
{  2}    3: linterp vgrf27:F, hw_reg2:F, hw_reg3:F, hw_reg0+16:F
{  4}    4: mov vgrf10+0.0:F, vgrf6:F
{  3}    5: mov vgrf10+1.0:F, vgrf27:F
{  6}    6: tex vgrf8+0.0:F, vgrf10+0.0:F
{  5}    7: mov vgrf32:F, u1:F
{  5}    8: mov.sat vgrf12:F, u1:F

From shader-db:
   total instructions in shared programs: 1841932 -> 1841957 (0.00%)
   instructions in affected programs:     5823 -> 5848 (0.43%)
I inspected two of the 25 hurt shaders, and concluded that they were
both hitting this bug, and not legitimately optimized.

This fixes bugs in Left 4 Dead 2 and Team Fortress 2, possibly among
others.  The optimization pass didn't exist in 10.0, so this is only
a candidate for 10.1.

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>