RADV's transfer queue implementation will use compute for
the transfer operations that aren't supported by the SDMA,
so we'll need gang submissions for that.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39057>
The following are not supported by SDMA:
- Sparse images (aka. PRT) on older GPUs
- Multisampled images
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39057>
When the "gang leader" is SDMA, we need to ensure that the
gang semaphores BO is coherent between SDMA and CP.
To achieve this, we need bypass the L2 cache when either SDMA
or CP are connected to L2.
Suggested-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39057>
Since we use atomic mode setting now, the wsi->fd we use needs to have
the atomic client cap.
There are several different code paths where wsi can acquire a file
descriptor. For drm masters, the atomic client cap is set in
wsi_display_init_wsi. For leased drm fds, there are AcquireDrmDisplayEXT
and AcquireXlibDisplayEXT.
According to a comment we previously assumed wsi_display_get_connector
is common among all code paths, and that's why the atomic client cap was
set there. But that assumption can be broken based on the particular
order which the application invokes vulkan APIs in.
This commit simply push the drmSetClientCap to all entrypoints where a
drm fd comes through.
Fixes: 513ffea1d3 ("wsi/display: use atomic mode setting")
Signed-off-by: Yuxuan Shui <yshui@codeweavers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38987>
Replace draw_entry_bytes with AC_TASK_DRAW_ENTRY_BYTES.
This is 16 on all AMD HW that supports task/mesh shaders.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39032>
The pass now uses the ring descriptors to figure these out.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39032>
Currently the number of task payload entry size is hardcoded
in shaders as a constant. This isn't a good idea because it
makes the code inflexible, eg. doesn't allow us
to change the number of entries dynamically.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39032>
Currently the number of task shader ring entries is hardcoded
in shaders as a constant. This isn't a good idea because it
makes the code inflexible, eg. prevents us from using the same
shader binary accross some chips as well as doesn't allow us
to change the number of entries dynamically.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39032>
Move the update of pan_shader_info into its own function. For now this
does nothing, but it will allow us to update the info before printing
stats, which will be useful in the future.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38961>
This isn't very useful yet (the info isn't fully filled
out at the point of the call) so the printed values should
be viewed skeptically.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38961>
We need a subset of the pan_shader_info struct for each variant,
and previously we were building a struct containing that subset and
passing the struct to bi_compile_variant_nir. Instead we should pass
a pointer to the whole struct and let bi_compile_variant_nir build the
substructure. This is both more efficient, and also gives the stats
code access to the full information.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38961>
Add the actual registers used (including uniforms used) by the shader
to stats. This is calculated by the stats gathering code, because the
scheduler and scoreboard passes run after register allocation and can
sometimes change the results.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38961>
These aren't new in RGP 2.6, they have been added since a while. But
because RADV wasn't supporting the new derived SPM chunk it wasn't
possible to expose them.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39013>
This is the new method to add performance counters to RGP captures.
This will be used to add the new RGP 2.6 counters too.
The previous SPM code will be deprecated at some point but it's hard
to support all generations in one batch. So, I will implement this
step by step.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39013>
Some blocks have two or more SPM counters and they should be used when
more than 4 counters are programmed (ie. 16-bit per counter).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39013>
