Deleting a sampler object will only cause it to be unbound from the
current context. To avoid reusing something that it still bound in
another context we need to check the DeletePending flag first.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c9130 ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 9bb696588d)
The calls look up a texture object and create it if it doesn't
already exist. However they weren't locking the hash between looking
up the name and adding it to the hash so it could be possible
another thread also generated the same name.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fixes: 842c9130 ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 95e87f6a6a)
Deleting a buffer object will only cause it to be unbound from the
current context. To avoid reusing something that it still bound in
another context we need to check the DeletePending flag first.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12810
Fixes: 842c91300f ("mesa: enable GL name reuse by default for all drivers except virgl")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34091>
(cherry picked from commit 0f0834275d)
The spec allows to create aliased disjoint image for a specific plane of
a multi-planar image, and the format can be R8. When querying memory
requirement of such image, VkImagePlaneMemoryRequirementsInfo is not
required to be chained although it has the disjoint bit.
This change fixes to look for aspect info from plane memory info only
when that's chained. The implementation can be passive here as the spec
VU has sufficient guarantees for the validity around. See below VU for
details:
- VUID-VkImageMemoryRequirementsInfo2-image-01589
- VUID-VkImageMemoryRequirementsInfo2-image-01590
- VUID-VkImageMemoryRequirementsInfo2-image-02279
- VUID-VkImageMemoryRequirementsInfo2-image-02280
Meanwhile, the existing disjoint check for size info is kept as is for
the special handling of VK_FORMAT_D32_SFLOAT_S8_UINT.
Test: dEQP-VK.ycbcr.plane_view.memory_alias.* pass with venus-on-panvk
Fixes: 412c286331 ("panvk: Enable multiplane images and image views")
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34134>
(cherry picked from commit 5dcb9f918d)
Per Vulkan spec 7.9. Host Write Ordering Guarantees, queue submission
commands automatically perform a domain operation from host to device
for all writes performed before the command executes. That is to say,
host updates to the mappings can occur after the end of the command
recording and must be flushed implicitly at submission boundary.
Before this change, necessary cache flushes could be missed once the
app starts reusing pre-recorded command buffers. e.g. a simple buffer
copy cmd while the app only updates the source buffer mapping in
different submissions. This changes backs out most of the current
version of cache flush reduction while still assigning LATEST_FLUSH_ID
to at least the final batch itself. This aligns with panfrost_batch
submit behavior on the gallium side.
Test: dEQP-VK.synchronization*.timeline_semaphore.* pass w/o flakiness
via venus-on-panvk
Fixes: 28e4d22497 ("panvk/csf: Pass a non-zero flush-id to benefit from cache flush reduction")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34093>
(cherry picked from commit 98a5acf352)
If the last owner thread has just unset the alive status and released
the watchdog, the new owner thread could have acquired to abort
unexpectedly if the ownership transfer occurs right before the next
owner's warn order. So we must set watchdog alive for new owner so that
it can properly check ring alive status in the next warn order.
Cc: mesa-stable
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34135>
(cherry picked from commit 8b2703fe08)
Register spilling can cause us to require thread local storage (tls).
However, we were not adjusting the tls stack size space to account for
the tls needed for the extra xfb shader when transform feedback is
needed. We noticed this when testing register allocation in the
OpenGL CTS (for testing we had forced spilling where none happened
before).
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33935>
(cherry picked from commit 2ee3bef252)
If we pass zink=false to pipe_loader_drm_probe_fd, it could happen that
a Gallium driver that had been already discarded because of not
supporting the graphics CAP will be chosen.
To avoid that, explicitly ask pipe_loader_drm_probe_fd to choose the
zink Gallium driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 854bc2ee05)
Exposing a rendernode from a supported driver is not a sufficient
matching criteria to qualify as the render part of a renderonly
device, as the rendernode might only expose compute or 2D accel
capabilities.
Look for a screen that actually supports gallium graphics operations
to qualify as a renderonly screen.
v2 (Tomeu): Have pipe-loader return a list of FDs for kmsro to choose
based on capabilities.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30096>
(cherry picked from commit 7e76c67632)
These changes happened with no mesa code change, only infrastructure
changes, which is really weird, but to be able to move on, let's simply
document the "new normal".
A recent change now requires the kvm runner tag to be explicitly listed
for jobs that need to run on runners with KVM capability.
This ensures the jobs are scheduled on compatible runners.
Cc: mesa-stable
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34120>
(cherry picked from commit a36379d973)
It seems the hardware requires a dummy PS state with a noop FS,
otherwise it might just hang. This used to work just fine on older
gens.
Note that RadeonSI refuses to draw if VS or PS is missing and AMDVLK
seems to also always emit this state. So, this might be a bug that AMD
didn't encounter at all.
This fixes a GPU hang during loading with Ghostwire: Tokyo.
Backport-to: 25.0
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34070>
(cherry picked from commit 1e4cfd9dfa)
This feature bit has inverted polarity from most other feature bits:
if the bit is present the driver should not use early Z. So the bit
must be set when the debug option to disable early Z is enabled.
Fixes: d600b45ccc ("etnaviv: Switch to etna_core APIs")
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/34064>
(cherry picked from commit 4608eef0a0)
This change began by fixing an old regression related to the dceil
functionality. This issue affected palm. Now, this change adjusts
the software fp64 support to make it fully operational.
This change was tested on palm and barts. This change fixes 561
"piglit run all" tests. The khr_gl tests are fixed as well (243 tests).
Here is a summary:
spec/arb_gpu_shader_fp64/execution/built-in-functions/*
spec/arb_gpu_shader_fp64/execution/fs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/gs-isnan-dvec: fail pass
spec/arb_gpu_shader_fp64/execution/vs-isnan-dvec: fail pass
spec/glsl-4.00/execution/built-in-functions/*
spec/glsl-4.10/execution/conversion/*
khr-gl4[3-5]/compute_shader/fp64-case1: fail pass
khr-gl4[0-5]/gpu_shader_fp64/builtin/*
Fixes: aed6a39c10 ("glsl: Retire dround lowering.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33708>
(cherry picked from commit 186fb5e73a)
The problem occurs with a series of instructions build the subgroup
invocation value :
mov(8) g23<1>UW 0x76543210V
add(8) g23.8<1>UW g23<8,8,1>UW 0x0008UW
add(16) g23.16<1>UW g23<16,16,1>UW 0x0010UW
Our register spilling code operates on physical registers (64B on
Xe2+) and using the brw_inst::is_partial_write() helper only considers
32B registers. So the spiller doesn't see that the add(16) instruction
is doing a partial write and ends up discarding the previous value.
You can reproduce the issue by running a test like :
INTEL_DEBUG=spill_fs ./deqp-vk -n dEQP-VK.compute.pipeline.cooperative_matrix.khr_a.subgroupscope.constant.uint8_uint8.buffer.rowmajor.linear
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: aa494cbacf ("brw: align spilling offsets to physical register sizes")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33642>
(cherry picked from commit c60180ba63)
std::slice::from_raw_parts requires that the slice pointer be non-null,
even when the slice contains zero elements. Failing this invariant is
undefined behavior.
v2: reordered commits to allow cherry-picking bugfixes
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33989>
(cherry picked from commit 5e365f1674)
When a slow/fast/slow clear sequence is executed on a surface, the second
slow clear will not regenerate the clear command if the clear value of the
fast clear is the same as the one used for the second slow clear, as the
current stored surface clear value is the same as the new clear value.
The command generated on the first slow clear however may have used a
different clear value, which is now submitted unchanged to the hardware on
the second slow clear.
Fix this by only generating the clear command if there is no valid one
already. If we already have a valid clear command simply update the fill
value in that command with the new clear value. This has some marginal
overhead, but has been chosen over the alternative of adding more state by
remembering the last slow clear value.
Cc: mesa-stable
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/34029>
(cherry picked from commit fb0f9e6352)
Cayman has a non-deterministic behavior issue which is
visible with the test below (arb_shader_image_size).
The tests fail randomly at the "fragment" test category.
Anyway, if the "compute" category is removed, the same
tests are working flawlessly.
The "compute" part of the driver was interfering with the
graphic pipeline. The culprit is the packet PKT3_DEALLOC_STATE
which puts the gpu in an incorrect state to perform some
graphic operations.
This change fixes this problem by issuing a PKT3_CLEAR_STATE
packet just after the PKT3_SURFACE_SYNC packet. As explained
by d51dbe048a PKT3_DEALLOC_STATE is mandatory on cayman to
avoid a gpu hang at the PKT3_SURFACE_SYNC stage.
This correction makes tests like
"spec@glsl-4.30@execution@built-in-functions@cs-.*" to pass
in an utterly deterministic way without random failures.
This change removes around 500 random failures for a
"piglit run all".
For instance, this issue is triggered on cayman with
"piglit/bin/arb_shader_image_size-builtin -auto -fbo".
Fixes: d51dbe048a ("r600g/compute: Emit DEALLOC_STATE on cayman after dispatching a compute shader.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33973>
(cherry picked from commit 085cfc98cc)
This optimization seems broken because eg. v_s_log_f32 uses SGPRs
for both the source and destination but applying OMOD seems to require
VGPRs.
This fixes a GPU hang when launching Enshrouded on GFX1201.
No fossils db changes on GFX1201.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34027>
(cherry picked from commit f46830912e)
Otherwise, the size of the EGLSurface and the drawable may get out of
sync if kopper needs to re-create the swapchain at a different size.
This can cause problems with things like eglSetDamageRegionKHR() where
the core EGL code clamps them to the size in the EGLSurface.
With Wayland, it's up to the client to choose a size and resize by
creating a new EGLSurface with a different size. Only on X11 can we
get a resize side-band like this.
Normally, without kopper, this goes the other direction where the X11
EGL code will detect a surface size change in dri2_x11_query_surface()
and it invalidates the drawable if they've changed, forcing
re-allocation. Kopper, however, works more like the DRI2 path where we
just get handed buffers at some size decided by X11 and have to deal
with them. In the DRI2 path, the size is unconditionally updated by
dri2_x11_get_buffers(). This is roughly equivalent, updating the size
right after every call to kopperSwapBuffers().
Fixes: 8ade5588e3 ("zink: add kopper api")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12797
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34015>
(cherry picked from commit ad90dbabe4)
This should fix some hangs on polaris when decode is forced on.
Fixes: 95a980b61f ("radv/video: add event support for VCN4")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34013>
(cherry picked from commit 2e3b23539e)
Stride can be zero if there are less than two queries to copy.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Fixes: 7755c41b3e ("panvk/csf: Rework the occlusion query logic to avoid draw flushes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34020>
(cherry picked from commit 8a47ae456c)
While the idea to take advantage of the higher throughput wasn't bad,
the hardware wasn't design with this in mind and doesn't behave like expected
with constant sources.
Fixes: bee487df48 ("aco/gfx11.5+: use vinterp for fddx/fddy")
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33969>
(cherry picked from commit 3b5e537b09)
A lot of people (including me) misinterpreted the conformanceVersion
field for so long. The Vulkan spec wasn't very clear either but it's
going to be clarified soon.
VkConformanceVersion is actually unrelated to the official CTS
conformance process in Khronos. It just reports the latest CTS version
that the driver can pass, not more.
For GFX8+, RADV should be passing CTS 1.4.0.0 on all GPUs because we
validated this CTS version recently for Vulkan 1.4.
For GFX6-7, which only suppports Vulkan 1.3, RADV should also be
passing CTS 1.4.0.0, because newer versions of the CTS can be used
to validate a driver against an older version of the spec, so
it's perfectly fine to report a higher CTS version than the Vulkan version.
Newer CTS versions likely can't pass 100% due to a DGC bug that I still
need to fix.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12799
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34018>
(cherry picked from commit e519e0b9e6)
This workaround is similar to anv_assume_full_subgroups, but it applies
to the shaders that use shared memory. If they rely on the implicit
synchronization, and we choose a smaller group size than the
(broken) shader expects, it will produce incorrect results.
Cc: mesa-stable
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23408>
(cherry picked from commit 369aec5704)
If a valid primary file descriptor is already set (e.g. from vc4),
don't overwrite it with -1.
This prevents losing a valid primary fd and resolves issues arising
when vc4 is the first node returned by `drmGetDevices2()` and v3d is
the second.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12777
Fixes: 188f1c6cbe ("v3dv: rewrite device identification")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33958>
(cherry picked from commit 7775c79035)
With secondary command buffers, inherited rendering can be used but
it's basically impossible to know if the depth/stencil attachment
enabled HiZ/HiS. But it's required to disable WALK_ALIGN8 to avoid
GPU hangs.
This assumes that HiZ/HiS is enabled for inherited rendering as long
as a depth/stencil attachment is used. It's not the most optimal
approach but it's not supposed to hurt either.
This fixes a GPU hang with
dEQP-VK.dynamic_rendering.primary_cmd_buff.basic.contents_secondary_cmdbuffers
and friends.
GFX1200 isn't affected because it doesn't support HiZ/HiS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33986>
(cherry picked from commit d1a2ba57f9)
We currently report a deviceName as e.g. "Mali-G610 (Panfrost)", but
panfrost has nothing to di with the physical device, and the suffix
doesn't belong there at all.
So let's remove that suffix from PanVK. This results in output like this
from vulkaninfo:
---8<---
VkPhysicalDeviceProperties:
---------------------------
apiVersion = 1.1.305 (4198705)
driverVersion = 25.0.99 (104857699)
vendorID = 0x13b5
deviceID = 0xa8670000
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = Mali-G610
pipelineCacheUUID = <snip>
---8<---
We already sort of namedrop Panfrost in the driver properties:
---8<---
VkPhysicalDeviceDriverPropertiesKHR:
------------------------------------
driverID = DRIVER_ID_MESA_PANVK
driverName = panvk
driverInfo = Mesa 25.1.0-devel (git-136dd9f985)
conformanceVersion:
major = 1
minor = 4
subminor = 1
patch = 2
---8<---
While this might techically speaking be a regression, PanVK has been
marked as experimental until Mesa 25.0. But to reduce the risk of people
starting to depend on this behavior, let's also backport this change to
the 25.0 release.
The patch looks a bit funny, because we add the " (Panfrost)"-suffix in
common code, and this moves it to the Gallium driver. But effectively,
this means PanVK is the only driver that sees a change of behavior.
Backport-to: 25.0
Reviewed-by: John Anthony <john.anthony@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33972>
(cherry picked from commit c34c7b1f3b)
