The extension is optional in Vulkan 1.2 and is causing crashes in
multiple CTS tests.
Signed-off-by: Nick Hamilton <nick.hamilton@imgtec.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Backport-to: 26.0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39351>
(cherry picked from commit 3aacc324bc)
now that transient images are a more complete mechanism, this should
in theory be okay and also accounts for the case where
a framebuffer contains mixed msrtt textures and plain multisampled textures
(cherry picked from commit 6474af3b42)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39469>
WSI used to track the similar for aliased wsi image creation, but later
got deprecated. So let's rename wsi.memory to wsi.anb_mem and drop
wsi.memory_owned to avoid confusions with common wsi related trackings.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39401>
(cherry picked from commit 481df22209)
Vulkan is supposed to operate in explicit synchronization mode. However,
for legacy compositors that only support implicit fencing, we have to
extract the compositor implicit fence (release fence) and resolve it
properly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39401>
(cherry picked from commit 849e3552e8)
The skip check should only be checking the format rather than the entire
packed word.
Fixes: 52ddc40a75 ("pco: restrict shadow sampler comparator clamping to unorm formats")
Signed-off-by: Simon Perretta <simon.perretta@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39428>
(cherry picked from commit c5b70dcb48)
Fixes: 6bda88bfdb ("pvr: copy WSI can_present_on_device function from PanVK")
Signed-off-by: Kitlith <kitlith@kitl.pw>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39415>
(cherry picked from commit b18b52e61d)
The offset for the dynamic buffers needs to be computed with the currently
bound pipeline layout. This change fixes incorrectly selecting the offset
for a dynamic buffer if a descriptor with a lower index than the currently
being bound contains a dynamic buffer but said descriptor hasn't being
bound yet. It also prevents the binding to override the dynamic buffers in
order to preserve the already bound dynamic descriptors.
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
(cherry picked from commit aaf4405507)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39440>
The offset for the dynamic buffers needs to be computed with the currently
bound pipeline layout. This change fixes incorrectly selecting the offset
for a dynamic buffer if a descriptor with a lower index than the currently
being bound contains a dynamic buffer but said descriptor hasn't being
bound yet. It also prevents the binding to override the dynamic buffers in
order to preserve the already bound dynamic descriptors.
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
(cherry picked from commit 80a076f5d0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39440>
```
Traceback (most recent call last):
File "bin/pick-ui.py", line 31, in <module>
loop = urwid.MainLoop(u.render(), PALETTE, event_loop=evl, handle_mouse=False)
~~~~~~~~^^
File "bin/pick/ui.py", line 196, in render
asyncio.ensure_future(self.update())
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
File "/usr/lib64/python3.14/asyncio/tasks.py", line 730, in ensure_future
loop = events.get_event_loop()
File "/usr/lib64/python3.14/asyncio/events.py", line 715, in get_event_loop
raise RuntimeError('There is no current event loop in thread %r.'
% threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'MainThread'.
```
Of the 3 dependencies, only urwid actually needs to be updated, but
while at it let's pick the latest of each.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39452>
(cherry picked from commit 21829c9f7e)
Now that all larger workgroup sizes are lowered to 256,
the regalloc hang cannot mess up the compute queues anymore.
Still don't allow compute queues on GFX6 though,
those have never been enabled ever since RadeonSI started using
the compute queue in a1378639ab - let's keep it that way.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39288>
Now that all larger workgroup sizes are lowered to 256,
the regalloc hang cannot mess up the compute queues anymore.
Still don't allow compute queues on GFX6 though,
they are prone to hangs. Needs further investigation.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39288>
Even though radeonsi may not use compute queues, other processes
might run compute jobs in the background, so radeonsi must make
sure not to use larger than 256 sized workgroups on GPUs that
are affected by the regalloc hang.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39288>
Even though radeonsi may not use compute queues, other processes
might run compute jobs in the background, so radeonsi must make
sure not to use larger than 256 sized workgroups on GPUs that
are affected by the regalloc hang.
Unfortunately that means that for now RadeonSI won't be able to
support ARB_compute_variable_group_size on these GPUs.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39288>
So that we can put the coarse_pixel_dispatch value available to NIR
lowering.
LNL internal fossildb changes:
Totals from 40 (0.01% of 490838) affected shaders:
Instrs: 33321 -> 33311 (-0.03%); split: -0.04%, +0.01%
Cycle count: 780136 -> 779936 (-0.03%); split: -0.03%, +0.00%
Max live registers: 5292 -> 5298 (+0.11%)
Non SSA regs after NIR: 26638 -> 26464 (-0.65%)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38996>
We don't need to take ETNA_DIRTY_SHADER into consideration for pure
updates of the constant states. When the shader is dirty constants
and code will be uploaded together and the update path will be skipped.
The uniform cache in the context has been removed in ee1ed59458
("etnaviv: prep for UBOs"), so the comment referencing this cache
is confusing and can go as well.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39422>
Constant buffers may be changed without the shader changing.
Check the correct dirty bits when marking constant buffers
as read during the draw to ensure proper synchronization.
Fixes: a40a6e551e ("etnaviv: draw: only mark resources as read/written when the state changed")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39422>
Jobs have been timing out, requiring 2-6 additional minutes beyond the
previous 30-minute limit. Increase the overall timeout from 30 to 45
minutes, with an additional 5-minute buffer for GitLab (50m total) to
provide margin for variance.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39432>
Currently panfrost has some bug at least on Midgard T-860, which causes
an assertion failure with these 16 bpc displayable framebuffer configs:
".../drivers/panfrost/pan_fb_preload.c:341: pan_preload_get_blend_shaders:
Assertion `b->work_reg_count <= 4' failed."
See discussion in:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588
Disable these rgb16 configs on panfrost by default for now,
as suggested by Eric Smith.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Suggested-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588>
Needed, so dEQP can deal with 16 bpc unorm surface formats, and doesn't
generate wrong reference images with its rasterizer, leading to false
positive failures in image comparison driver vs. reference rasterizer.
As proposed by Valentine Burley, thanks!
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Suggested-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38588>
