In 14b4160792 ("vulkan/wsi: Only test for dma-buf sync file support
once"), I moved the dma-buf sync file import/export check earlier. This
is fine for hardware implementations where we have real dma-buf
import/export but it broke lavapipe because the check itself ignored
whether or not we actually have dma-buf import/export. Add a couple
more checks to wsi_drm_check_dma_buf_sync_file_import_export() so it's
safe even for SW drivers. Also, in wsi_create_sync_for_dma_buf_wait(),
check if we actually have a dma-buf.
Fixes: 14b4160792 ("vulkan/wsi: Only test for dma-buf sync file support once")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37033>
v2: Rebase on ac2b072312 ("brw: Add more specific brw_builder
helpers"), and fix a bug that caused the new instruction to possibly be
put in the wrong place.
No shader-db changes on any Intel platform.
fossil-db:
All Intel platforms had similar results. (Lunar Lake shown)
Totals:
Instrs: 233675305 -> 233641585 (-0.01%)
Cycle count: 32593658094 -> 32591467794 (-0.01%); split: -0.01%, +0.00%
Totals from 33513 (4.25% of 789264) affected shaders:
Instrs: 5200332 -> 5166612 (-0.65%)
Cycle count: 1499831128 -> 1497640828 (-0.15%); split: -0.15%, +0.00%
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35444>
This makes lavapipe act like other DRM drivers whenever we have udmabuf
and just make everything a dma-buf even if it doesn't strictly have to
be. Without this we can end up in weird cases if the client asks to
allocate a memory object with multiple export types. Before, if this
happened, we would allocate a memfd and then return that when the client
calls GetMemoryFd() even if they asked for a dma-buf. In theory, we
could add additional plumbing to allow for using the memfd itself for
OPAQUE_FD and only wrap in a udmabuf if DMA_BUF is requested but this is
simpler and more in line with what hardware DRM drivers do.
Fixes: c1657de63c ("lavapipe: support VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13798
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37067>
We need to make sure that earlier gfx commands don't see the committed
resource. Also, the commit doesn't necessarily happen atomically,
because the kernel has to unmap the NULL page and then map the BO page,
so earlier gfx submits could race with the kernel an see an unmapped
page and fault. This is the same race when uncommitting but in reverse.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37065>
If implementation does not actually replay the VA, it must return 0
to not violate:
"If the memory object was allocated with a non-zero value of
opaqueCaptureAddress, the return value must be the same address."
Fixes RenderDoc capture replay, which asserts on the this spec rule
being followed.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: ed6d5c33 ("nvk: Implement VK_EXT/KHR_buffer_device_address")
Reviewed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Closes#13784
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37047>
When building with libdrm as an internal fallback dependency, i.e.
a submodule, meson does not find `amdgpu.h` from the installed external
dep, failing to build with the following error:
-----------------------------------------------------------------------
In file included from ../src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.c:10:
In file included from ../src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h:18:
../src/amd/common/ac_linux_drm.h:14:10: fatal error: 'amdgpu.h' file not found
14 | #include "amdgpu.h"
| ^~~~~~~~~~
1 error generated.
-----------------------------------------------------------------------
Make libvulkan_radeon depend explicitly on dep_libdrm_amdgpu to also use
the include_directories declared for that dependency in case it's an
internal dependency.
Acked-by: Valentine Burley <valentine.burley@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36932>
Don't include amdgpu.h directly in AMDGPU/RADV code, the only libdrm
pieces that are needed are handled in src/amd/common/ac_linux_drm.h
which already includes amdgpu.h
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36932>
This is a dynamic state. This also replaces the stride by a 16-bit
value because it's required to not exceed
VkPhysicalDeviceLimits::maxVertexInputBindingStride which is defined
to 2048.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37025>
It is a bit annoying to have the resulting increased duplication, but
the table magic doesn't play nicely with variant regs.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Registers declared as a "naked" array, ie:
<array offset="0x1234" name="SOME_REG" stride="1" .../>
were not getting register packers generated for them. Insert an
implicit <reg32> child for them, so the above would be equivalent
to:
<array offset="0x1234" name="SOME_REG" stride="1" .../>
<reg32 offset="0" name="REG"/>
</array>
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
When we have a variant range, we need to test against the inclusive
range. Ie. if we have variants="A6XX-A7XX" we can't just test for
chip == A6XX.
So switch the variant key to preserve the range (ie. "A6XX-A7XX" instead
of just "A6XX"), add a helper to sanitize the range for symbol/#define
names, and handle the three possible cases when generating the if/else
ladder:
- single variant, ie. variants="A6XX", keeps the current logic
- open ended range, ie. variants="A6XX-", generates a >=
- closed ended range, ie. variants="A6XX-A7XX", generates a
(CHIP >= A6XX) && (CHIP <= A7XX)
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Even if there is only a single variant currently. This will allow
porting code to use the new builders independently from adding new
hw support. Basically avoiding churny conflicty changes on a branch
during bringup.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Apparently the ignored bits have meaning.
- EOLM - Is set on a NOP after the last cat6 instruction.
Must be set outside of control flow including preambles.
Doesn't seem to affect correctness.
- EOGM - Is set on a NOP after the last cat5/cat6 instruction.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37009>
Fix the following warning, and others that are similar, as rustc
suggests:
warning: hiding a lifetime that's elided elsewhere is confusing
--> ../src/gallium/frontends/rusticl/mesa/compiler/nir.rs:282:22
|
282 | pub fn variables(&mut self) -> ExecListIter<nir_variable> {
| ^^^^^^^^^ -------------------------- the same lifetime is hidden here
| |
| the lifetime is elided here
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
= note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
|
282 | pub fn variables(&mut self) -> ExecListIter<'_, nir_variable> {
| +++
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37059>
