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>
This introduces tracking of the required semaphore values in pipelines,
which is then propagated to cmd_buffers on bind. Each queue also keeps
track the maximum count it has waited for, so that we can avoid the waiting
overhead once all the shaders are loaded and referenced.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16271>
