... if you have EXT_framebuffer_sRGB. The extension just relaxes an
error check that we're already not performing, and sRGB rendering
implies sRGB texture support, and mipmap generation would need it to be
a valid render format. So advertise it if EXT_framebuffer_sRGB works.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19476>
This was just all kinds of wrong. Note that the comment implying "this
is a workaround for old XQuartz" is on the "not apple" side of the
ifdef. Anyway. xserver didn't start sending GLX_DRAWABLE_TYPE in the
fbconfig until:
commit 8cde0af3c57f0375ba8ba77af9fdf74b79d9496d
Author: Kristian Høgsberg <krh@redhat.com>
Date: Wed Apr 2 19:06:40 2008 -0400
Send the GLX_EXT_texture_from_pixmap attributes to the client.
So we can remove this default from the fbconfig path. But we preserve it
for the GLXGetVisualConfigs path, because that is specified not to send
GLX_DRAWABLE_TYPE.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20549>
First, move a few early-out checks up since they don't need to take the
GLX lock. Second, move garbage collecting deleted contexts up to
immediately after they are unbound. This fixes a memory leak, albeit a
difficult one to hit, in the case where you switch away from a deleted
context but switching to the new one errors out. In that case we would
leak the deleted context, since it's been unbound from all threads and
there's no longer an XID for it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20549>
Instead of smashing unconditionally to 1. Not sure if this fixes anything but it
gets rid of an unknown at least. Possibly slightly faster.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20561>
If we pass a physical 2D texture descriptor we should also pass 2
coords. Otherwise it just uses the random content in the second
register which ends up funny sometimes.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20696>
If the previously emitted graphics pipeline uses the value A for
col_format_non_compacted and the new bound graphics pipeline uses B.
At bind time, radv_cmd_state::col_format_non_compacted will be set to
B and the rbplus flag will be dirtied. But if there is no draws and a
new graphics pipeline is bound with the same value as A, the next
draw will emit the rbplus state with B instead of A.
This can be basically triggered with meta operations after drawing
because the driver saves/restores the bound pipeline.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8073
Fixes: 11469f7553 ("radv: copy the non-compacted color format at pipeline bind time")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20692>
On GFX10-10.3, RADV_PERFTEST=ngg_streamout can be used to replace the
legacy path but it should be in the pipeline key. Otherwise, it's
possible to load legacy shaders from the cache instead of NGG.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20668>
Zink testing should happen in the layered-backends stage, not the AMD
one.
Suggested-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20677>
It seems to have happened only once so far, but let's be proactive as
an unexpected pass is fatal.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20677>
It seems `spec@ext_texture_array@fbo-depth-array stencil-draw` got
fixed last week, so let's update the expectations.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20677>
The results.csv file of a full piglit run is about 6 MB.
Given how seldomly this file is being used, and the fact that it cannot
be viewed directly in gitlab's artifact page anyway.
Let's compress the file using zstd, and enjoy a ~90% reduction in size
at the cost of probably less than 500ms of compression time on a slow
device, and 55ms on the CI machines in the valve farm.
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20669>
The results.csv file can get ridiculously big for a vkcts run (up to
135MB). Given how seldomly this file is being used, and the fact that
it cannot be viewed directly in gitlab's artifact page anyway.
Let's compress the file using zstd, and enjoy a ~95% reduction in size
at the cost of probably less than 1 second of compression time on even
the slowest of the devices in CI (which would use sharing), and about
150ms on the CI machines in the Valve farm.
Suggested-by: Daniel Stone <daniels@collabora.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20669>
This is to inform you of some planned downtime in the LAVA lab as follows:
Start: 2023-01-13 08:00 GMT
End: 2023-01-13 12:00 GMT
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20632>
load_preamble is intended to be almost free (costing at most a move), and it
does not have special bounds checking requirement, so it's ok to select with it.
With this, drivers that use nir_opt_preamble together with a late call to
peephole_select can optimize sequences like:
if (x) {
<uniform-on-uniform calculation>
} else {
<different uniform-on-uniform calculation>
}
to simply
bcsel(x, <uniform register 0>, <uniform register 1>)
rather than emitting needless control flow / branching over some moves.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20597>
multiplying by the array size is always wrong for this case, and not
doing so allows for some simplification and better inlining, though
the output results are identical
the one corner case is clip/cull distance, which need special handling
since they're arrays with vec semantics
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20678>
This is heavily copy-pasted from a patch of Ian Romanick, including the
commit message.
Previously, this pass always generated fcsel for bcsel. This was the
only place that generate fcsel, so various drivers assumed (and needed!)
that src0 was a Boolean with 0.0 or 1.0 as the only values.
Specifically, many DX9 / GL_ARB_vertex_program platforms lack a CMP
instruction in vertex shaders. In those cases, they would use LRP to
implement fcsel. The bummer is that many plaforms have a real fcsel
instruction, and those platforms would benefit from other places
generating that opcode.
Instead of leaving assumptions in drivers about the sources of an opcode
that they can't really support, allow them to control the way the
lowering pass translates bcsel. Two flags are used to control this:
- If the driver sets has_fused_comp_and_csel in nir_options, fcsel_gt
will be used. Since the Boolean value is 0.0 or 1.0, this is
equivalent to fcsel.
- If the parameter has_fcsel_ne is set, fcsel will be used. This is the
old path.
- Otherwise, the lowering pass assumes we're on a crufty, old DX9 vertex
program, and it emits flrp.
With this, the assumptions about src0 of fcsel in NTT can be removed.
If a platform can't handle fcsel, it should ensure that the lowering
pass won't generate it.
No change in shader-db.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
DX9 PS 1.x / GL_ARB_fragment_program shaders that have been converted to
GLSL are littered with patterns like
ps_r1.x = ((ps_t0.y >= 0.0) ? ps_r1.x : ps_c1.y);
This is because CMP is a fundamental opcode in those earlier shading
languages. i915 supports this opcode natively, but there's no way to
get it directly into the backend. Instead, NIR and NTT generate some
combination of fcsel and sge and hope for the best.
i915
total instructions in shared programs: 49032 -> 48897 (-0.28%)
instructions in affected programs: 4173 -> 4038 (-3.24%)
helped: 39
HURT: 0
total temps in shared programs: 2795 -> 2790 (-0.18%)
temps in affected programs: 22 -> 17 (-22.73%)
helped: 5
HURT: 0
total const in shared programs: 4976 -> 4967 (-0.18%)
const in affected programs: 203 -> 194 (-4.43%)
helped: 9
HURT: 0
GAINED: shaders/trine/fp-13.shader_test FS
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
These match the TGSI CMP opcode very nicely. Every driver that uses NTT
for its fragment shader path should be able to enable these opcodes now.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20162>
