If the window is destroyed from underneath us while we happen to be in
xcb_wait_for_special_event, there's no recovery. The special event will
never match because the XID is no longer valid, and Present doesn't have
an in-band DestroyNotify. We're going to work around this by using the
poll API instead. If we get an event we short-circuit back to the top of
the "wait for available image" loop, so we drain the whole special event
queue before any other logic. Which means if we run out of special
events (and the connection and swapchain are still valid) that we
_don't_ have enough images available, so to hurry along any events that
the X server hasn't flushed out yet we call GetGeometry on the
swapchain's window. As a side effect this verifies that the window is
still alive.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15800>
Valhall introduces hardware-allocated varyings. Instead of allocating varying
descriptors on the CPU with a slot based interface, the driver just tells the
hardware how many bytes to allocate per vertex and loads/stores with byte
offsets. This is much nicer!
However, this requires us to rework our linking code to account for separable
shaders. With separable shaders, we can't rely on driver_location matching
between stages, and unlike on Midgard, we can't resolve the differences with
curated command stream descriptors. However, we *can* rely on slots matching. So
we should "just" determine the byte offsets based on the slot, and then
separable shaders work.
For GLES, it really is that easy.
For desktop GL, it's not -- desktop GL brings unpredictable extra varyings like
COL1 and TEX2. Allocating space for all of these unconditionally would hamper
performance. To cope, we key fragment shaders to the set of non-GLES varyings
written by the linked vertex shader. Then we may define an efficient ABI, where
only apps only pay for what they use.
Fixes various tests in dEQP-GLES31.functional.separate_shader.random.* on
Valhall.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16310>
Packed TLS has cache-locality benefits on Valhall, compared to Bifrost's flat
TLS. Valhall does support flat TLS, but requires extra arithmetic in the shader
for correct results. At least until we get to generic pointers (and maybe even
then), we can use packed TLS. So just use packed TLS always for proper spilling.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16314>
The set of blend shaders is closed. They are completely internal. As such, we
know that the registers we reserve for them suffice, and we don't permit
register spilling. Refusing to support spilling in blend shaders simplifies a
number of parts of the compiler. Add a check that we don't try to spill anyway,
which will silently fail.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16314>
BIFROST_MESA_DEBUG=spill now restricts the register file to 1/4 its usual size,
useful for testing register spilling (e.g. running CTS) as well as debugging
spilling on small shaders.
Note blend shaders are exempt, as we don't allow blend shaders to spill.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16314>
Fixes failures on tests like this when the on-disk-cache is enabled:
dEQP-VK.binding_model.descriptor_copy.compute.uniform_buffer_0
We only found them when running full CTS runs. What happens is that we
got a hit from the on-disk shader cache, for several tests using the
same shaders. But some tests seems to be using a uniform buffer, and
others a inline buffer. Right now inline buffers leads to some changes
on the final nir shader, and generated assembly, compared with uniform
buffers. So we got a wrong shader. Fortunately we only got an assert
instead of weird behaviour.
With this commit we include the pipeline layout on the pipeline sha1,
so those two cases would get different sha1. FWIW, this is what other
drivers are already doing.
Surprisingly that didn't cause a problem before.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16313>
If we are calling pipeline_cache_upload_shared_data with
from_disk_cache, that means that we had used the disk-cache to found
that entry. And that should only happens if we didn't find the entry
on the cache. So on that case we can skip to search for it.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16313>
From the GL 4.6 spec: "If the value of any non-ignored component of the
offset vector operand is outside implementation-dependent limits, the
results of the texture lookup are undefined." We shouldn't assertion
fail, then.
GLSL-to-NIR shouldn't be enforcing limits on TG4 offsets, since it doesn't
for non-TG4 tex_src_offset either. Leave it up to the driver to handle
it.
Fixes a crash in a piglit test on nouveau that supplies a negative random
number up to 10,000 as the first coordinate for some reason. Other NIR
drivers lowered TG4 explicit offsets to tex_src_offset, so they weren't
affected.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16261>
Adam Jackson