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>
* immediately terminate renderpass after flushing
this otherwise could persist and trigger a bad state where the
zsbuf is eliminated
* no-op if already in renderpass
this function can be called from within a renderpass, at which time
it should do nothing because clears will be flushed automatically
Fixes: 5de34e47ad6 ("zink: unify/fix clear flushing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37052>
Wine uses vkGetRandROutputDisplayEXT to query some GPU details on start
of a prefix that have to be exposed on the PE side.
Currently this causes minimum of 2 connector reprobes via
DRM_IOCTL_MODE_GETCONNECTOR. This can stall vblanks when timed just
right. In cases where prefixes are started over and over again (e.g.
Steam doing background processing) this causes periodic noticable
stutter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37026>
