The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Connor Abbott <cwabbott0@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
VK_KHR_pipeline_binary allows the application to take full control on
the cache and internal caches (disk or in-memory) can be disabled.
Though the shader hash should still be computed, otherwise all pipeline
binaries have a key with all zeroes.
Fixes: 8802612458 ("radv: advertise VK_KHR_pipeline_binary"
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31163>
Otherwise, if a pipeline is found in cache it will use a different
shader arena for allocation and the capture replay shader group handles
won't match.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31188>
There's nothing in spec that says that key is only written
if data is also written.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: be06bfcbed ("radv: add initial support for pipeline binaries")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31162>
This fix doesn't concern CDNA based chips such as gfx940 directly
but it fixes corruptions on other chips that use emulated image
loads and stores using buffers when AMD_IMAGE_OPCODES=false.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30891>
The expected PIPE_INTERLEAVE_BYTES size is ADDR_PIPEINTERLEAVE_256B on
gfx940 (or other CDNA based chips). Since CDNA based chips like gfx940
doesn't support image opcodes, it gets gibberish value from the kernel.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30891>
This is useless and causes hangs (eg: with Firefox).
Instead use a custom emit function for the sqtt state, and
add the pipeline BO to the buffer list at this point.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31171>
This was only a best effort fallback and it doesn't always work.
Driver is expected to only output slice NALs when packed headers
are not enabled, so let's just do that.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31126>
Some apps would default to smaller resolutions than we currently report
as supported, despite the hardware being able to encode it. It's also
common for test apps/suites to use small resolutions.
libva-utils/h264encode uses 176x144 resolution by default and vulkan cts
have video clips with the same resolution too which would previously
fail to encode.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31109>
We want barriers to only consider compute as a possibility, and CP DMA
has to work with that, which means barriers can't have code specific
to CP DMA.
Always executing the CP DMA sync seems acceptable because CP DMA operations
are usually small, and CP DMA is almost never used on GFX10+.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
This makes the CP DMA code simpler and reuses the logic we use for internal
compute shaders.
The only thing that can't be handled in the barrier functions is
"!cp_dma_has_L2 -> SI_CONTEXT_INV_L2" because the barrier functions should
assume that only compute shader coherency is required to make them usable
everywhere, and the CP DMA code has to deal with it.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
We don't need to access GDS with CP DMA, and L2 prefetches don't use this
codepath.
Some local variables are also moved closer to their use.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
Since the compute blit can execute multiple dispatches in a loop,
we shouldn't save/bind/restore images for every single dispatch.
This will help move that out of the loop.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
Other shader stages can't realistically read and render to the same
pixel of the same texture simultaneously.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
and into the new si_barrier functions.
The new barrier function parameters might be excessive for now, but they
will be used later, hopefully.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
This moves code from si_launch_grid_internal into 4 new functions:
- si_barrier_before_internal_op
- si_barrier_after_internal_op
- si_compute_begin_internal
- si_compute_end_internal
The goal is to move setting the flush flags into callers, which will
eventually become proper memory barriers.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
It didn't do anything. It only set INV_SCACHE and INV_VCACHE, which are
already set optimally by si_launch_grid_internal.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
