vkCmdUpdatePipelineIndirectBufferNV() can be called on any queue
supporting transfer operations and it's not required to call it on the
same queue as DGC execute. This is very annoying if the compute shader
has scratch because it needs to be configured per queue.
The solution is to gather the maximum possible scratch size used by
indirect compute pipelines and use that to configure scratch.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27495>
The kernel checks for UVD msgs and if there aren't any gets upset,
so don't submit 0 length on UVD rings either to avoid that.
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27186>
Following discussion on kernel mailing list[1], we are not gaining
anything from this right now, and it does not handle soft recovery.
We will hear about the context loss and rationale when we vkQueueSubmit
next.
We can come back to this if there is ever a Vulkan extension for
figuring out innocent vs guilty like GL_EXT_robustness.
This does mean however that we return VK_SUCCESS for cancelled semaphore
and fence waits, but this is legal per the Vulkan spec:
"Commands that wait indefinitely for device execution (namely
vkDeviceWaitIdle, vkQueueWaitIdle, vkWaitForFences with a maximum
timeout, and vkGetQueryPoolResults with the VK_QUERY_RESULT_WAIT_BIT
bit set in flags) must return in finite time even in the case of a lost
device, and return either VK_SUCCESS or VK_ERROR_DEVICE_LOST."
"If device loss occurs (see Lost Device) before the timeout has expired,
vkWaitSemaphores must return in finite time with either VK_SUCCESS or
VK_ERROR_DEVICE_LOST."
[1]: https://lists.freedesktop.org/archives/amd-gfx/2024-January/103337.html
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27091>
Otherwise we rely on check_status alone, and that's going away.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27091>
the vcn enc/unified rings don't do nop packets, and hang with 0 sized
cmd buffers. This just stops submitting 0 sized cmd buffers to the hw.
Fixes hangs with dEQP-VK.video.decode.h264_i on navi3x
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25932>
For working around improper usage of sparse in DOOM Eternal.
When fully explicit sync sparse binding is implemented, this path will
remain implicit sync to also deal with the improper semaphore usage.
radv_queue_submit_bind_sparse_memory will likely get a bool parameter to
control explicit / implicit sync in that case.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26464>
1) This better reflects the reality that we only have one timeline
of sparse binding changes.
2) Allows making it a threaded queue from the start in prep of
explicit sync stuff.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16935>
This makes sure that the semaphore is only written when all work
on the compute queue is finished.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25770>
It works with just one counter.
This mitigates https://gitlab.freedesktop.org/drm/amd/-/issues/2902
quite a lot when you run dEQP-VK.transform_feedback.* in parallel on
more than 16 threads with RDNA3.
For example, on my GPU the kernel reports 16 GDS OA counters which means
that if you run VKCTS with 16 threads (ie. 16 Vulkan devices are
created) it's fine. Otherwise, the kernel might report ENOMEM.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25619>
Otherwise, we have dangling BO pointers in the global BO list. Not
quite sure why this hasn't been triggered before.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25623>
Gang submissions are mostly only be used for task shaders to both
submit GFX and ACE command buffers in the same submission. Though,
the gang leader (the last submitted CS) IP type should match the
queue IP type to determine which fence to signal.
But if chaining is enabled, it's possible that all GFX cmdbufs are
chained to the first GFX cmdbuf, which means the last CS is ACE and
not GFX.
Fix this by resetting chaining for GFX when a cmdbuffer has GFX+ACE.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9724
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24966>
This was completely broken, for example in the following scenario:
- submits something which needs sample positions (this creates a new
descriptor BO with sample positions)
- submits something which needs the tess rings (this creates a new
descriptor BO with tess rings but without sample positions, ie.
add_sample_positions would be FALSE)
- submits something which needs sample positions again (this won't
create a new descriptor BO because it incorrectly remembered that
sample positions were set)
Fix this by always writing the sample positions.
This should fix the following flakes:
- dEQP-VK.fragment_shading_barycentric.*.weights.pipeline_topology_dynamic.msaa_interpolate_at_sample.*
- dEQP-VK.pipeline.fast_linked_library.multisample_interpolation.sample_interpolate_at_distinct_values.*
- dEQP-VK.pipeline.fast_linked_library.multisample_interpolation.sample_interpolation_consistency.*
- dEQP-VK.draw.renderpass.linear_interpolation.*
- dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.linear_interpolation.*
These flakes were extremely hard to reproduce!
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25529>
Starfield has a lot of empty ExecuteIndirect() calls. This optimizes
them by using the indirect sequence count as predicate.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25060>
This is done to better match the terminology used by the kernel
and also because the follower may not always be ACE in the future.
- Gang: a group of command streams that are submitted to
more than one HW queue at the same time.
- Leader: the main command stream of a command buffer that works
on the queue type of the command buffer.
- Follower: a command stream on a different HW queue that doesn't
have a separate command buffer state and is submitted together
with its leader.
During submission, a follower must always precede the leader in
the submitted command streams array.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23462>
The check for max_dw means that none of checks triggered reliably
when we had an issue. Use a stricter reserved dw measure to increase
the probability of catching issues.
Adds a radeon_check_space to some places after cs_create as they
previously relied on the min. cs size, but that would still trigger
the checks.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20152>
If the submission isn't chained for any reasons, we might end by
submitting the performance counter preambles without a command
buffer that added this BO to its list.
Found by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22627>
This packet is supported on GFX6 too, its name should relect that.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22406>
Also don't check whether chaining is enabled in radv_queue, the
winsys will take care of that anyway.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22406>
This will still make it so that RADV_DEBUG=hang will only submit
one command buffer at a time, but otherwise let's pass all CS
objects into one submission and let the winsys split them if
necessary.
The winsys can do a better job at splitting them because
radv_queue has no knowledge of IBs and ignores chaining in the
splitting logic.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22354>
For feature parity with initial preambles.
Previously, continue preambles were for GFX6 only, but this is
about to change in the next commits.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22354>
Skipping the continue preamble can allow other processes to mess
up some registers set by the current process.
Originally, we could omit generating the continue preamble when
no shader rings were used, because the register initialization
happened at the beginning of every main cmdbuf. However, this
isn't the case anymore.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22354>
