Previously, we update the sfb dst slot upon vn_SignalSemaphore so that
vn_GetSemaphoreCounterValue can poll just the feedback slot itself.
However, that can race with pending sfb cmds that are going to update
the slot value, ending up with stuck sync progression.
This change fixes it by disallowing vn_SignalSemaphore to touch the sfb
dst slot. To ensure counter query being monotonic, vn_GetSemaphoreCounterValue
now takes the greater of signaled counter and the sfb counter read.
Test with dEQP-VK.synchronization* group:
- w/o this: stuck shows up within 2 min with 8 parallel deqp runs
- with this: no stuck for multiple full runs of the same
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14304
Fixes: 5c7e60362c ("venus: enable timeline semaphore feedback")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38516>
There's a single underlying bo mapping shared by the initial alloc here
and the later import of the same. The mapping size has to be initialized
with the real size of the created blob resource, since the app can query
the exported native handle size for re-import. e.g. lseek dma-buf size
Similar to virtgpu_bo_create_from_device_memory, the app can do multiple
imports with different sizes for suballocation. So on the initial
import, the mapping size has to be initialized with the real size of the
backing blob resource.
Backport-to: 25.3
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38443>
If the allocation originates from the same instance, the tracker map
size follows the allocationSize. After export and re-import, mapping the
whole dma-buf can exceed the original map size. This change backs out
the offending changes.
Test: dEQP-VK.api.external.memory.*.suballocated.host_visible.*
Fixes: 442f242a49 ("venus: requests whole blob mem size for non-dedicated import")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38443>
This is helpful to tell which path is taken:
1. explicit modifier: legacy_scanout=0, prime_blit=0
2. prime blit: legacy_scanout=0, prime_blit=1
3. legacy scanout: legacy_scanout=1, prime_blit=0
To be noted, venus doesn't advertise legacy scanout support, but we
implicitly support it for gamescope compatibility.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38457>
To avoid incompatibility between the compiler implementations used by
the driver and the renderer, seq_cst ordering is picked here, which has
required a full mfence instruction. Then the renderer side acquire is
ensured to be ordered after the cache flush of ring cs updates.
Perf wise, there's no regression in headless vkmark runs. In theory,
the overhead introduced here weighs trivially as compared to the ring
cs encode/decode part. So we should go for better robustness.
Test: venus on windows guest works with renderer on Linux
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14277
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38435>
Now that lavapipe sparse resource support on external memory has been
fixed, expose sparse resource support from venus on lavapipe. Meanwhile,
make remaining failures explicit (failed in lavapipe as well).
This CL also drops an obsolete comment and updates expectations from
full nightly runs.
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38074>
Struct virgl_renderer_capset_drm has a varying size depending on whether
AMDGPU driver is enabled or not. This breaks offset of struct vdrm_device
members for non-AMD drivers when Mesa is built with multiple native context
drivers including the AMD driver. Place varying capsets in the end struct
vdrm_device to mitigate the issue.
Fixes: 5736280730 ("virtio/vdrm: add ENABLE_DRM_AMDGPU for c_args")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38096>
Now sfb cmd can be VK_NULL_HANDLE on incompatible queues. Avoid passing
that to set cmd, and explicitly assert below.
Test: dEQP-VK.synchronization2.basic.timeline_semaphore.multi_queue can
properly assert on the driver side when assert is enabled.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38049>
Previously, we either have to filter out incompatible queue or disable
fence feedback. Now we track whether the queue can do feedback, and will
mark the fence feedback not pollable if the fence is submitted on an
incompatible queue.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38049>
Feedback requires transfer capability, so we must skip feedback cmd
pool initialization on incompatible queue families. Meanwhile, use
pool_handle for all validity check needed.
- fence and semaphore feedback: skip feedback cmd alloc and record when
pool_handle is VK_NULL_HANDLE
- event feedback: not affected as we patch in-place upon recording
- query feedback: assert the feedback cmd alloc is on supported queue
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38016>
This was something that came up in the slop MR. Not sure it's actually a
good idea or not but kind of curious what people think, given we have a
sound tool (Coccinelle) to do the transform. Saves a redundant branch
but means extra noninlined function calls.. likely no actual perf impact
but saves some code.
Via Coccinelle patches:
@@
expression ptr;
@@
-if (ptr) {
-free(ptr);
-}
+free(ptr);
@@
expression ptr;
@@
-if (ptr) {
-FREE(ptr);
-}
+FREE(ptr);
@@
expression ptr;
@@
-if (ptr) {
-ralloc_free(ptr);
-}
+ralloc_free(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-free(ptr);
-}
-
+free(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-FREE(ptr);
-}
-
+FREE(ptr);
@@
expression ptr;
@@
-if (ptr != NULL) {
-ralloc_free(ptr);
-}
-
+ralloc_free(ptr);
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [v3d]
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> [venus]
Reviewed-by: Frank Binns <frank.binns@imgtec.com> [powervr]
Reviewed-by: Janne Grunau <j@jannau.net> [asahi]
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> [radv]
Reviewed-by: Job Noorman <jnoorman@igalia.com> [ir3]
Acked-by: Marek Olšák <maraeo@gmail.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Job Noorman <jnoorman@igalia.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37892>
This reduces duplication: we only need to distinguish between Windows
and Unix in one place.
The previous code was inconsistent about using either the `platforms`
option, or the `host_machine`. Following the logic described in
commit 94379377 "lavapipe: build "Windows" check should use the host machine, not the `platforms` option.",
I've assumed that checking the host machine is the more-correct version
and used that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
This consistently uses `NAME.dll` on Windows, `libNAME.dylib` on Darwin
derivatives such as macOS, and `libNAME.so` on Linux, *BSD and so on.
It's also consistent about using the local variable name `icd_file_name`
for this name in every Vulkan driver, which was already the case in many
but not all drivers.
Some of these drivers probably don't make sense (or don't work) on
Windows and/or macOS, but if this is kept consistent for all drivers,
it should avoid the need for driver-specific commits like
commit 611e9f29e "lavapipe: fix icd generation for windows",
commit 951f3287 "lavapipe: set empty dll prefix",
commit 13e7a39f "lavapipe: fixes for macOS support",
commit 7008e655 "radv: Update JSON generator if Windows" and so on,
each time a driver is found to be relevant on more platforms than
previously believed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
... to make it forward compatible / to make it not crash older
Gfxstream host builds.
Test: Capture guest and host trace and inspect in perfetto UI
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37410>
ENABLE_DRM_AMDGPU must be defined when amdgpu_virtio is enabled;
otherwise, vdrm and amdgpu_virtio will have different definitions of
struct virgl_renderer_capset_drm. As a result, on amdgpu_virtio side,
the content of struct vdrm_device will be corrupted.
Thanks Honglei Huang <honglei1.huang@amd.com> for pointing out the
different definitions of struct virgl_renderer_capset_drm.
Cc: mesa-stable
Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37023>
The regressed changes have been reverted for Linux 6.16 in commit 9d85a32f0e6bf6878676a9ec7ce3c8032c500c7c
This should now allow us to use Linux 6.16 for the rest of the testing
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36909>
Venus renderer side has strict entry points sanitization based on the
app requested app api version + physical device api version. So on the
driver, we should follow the same for legacy client apps.
Meanwhile, VK_PIPELINE_STAGE_NONE can't be used when we hit the sync2
emulation path, so we swap it with VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
placeholder for the 2nd sync scope there.
Fixes: 07cee75c39 ("venus: layer vkQueueSubmit2 over vkQueueSubmit w/o sync2")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36830>
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Downgrade to Linux 6.14 for venus-lavapipe jobs
In Linux 6.16 (and possibly 6.15 as well), the virtio gfx device
initialization seems to have regressed, resulting in device initialization
failure.
```
deqp-runner 0.20.3
+ deqp-runner suite --suite /builds/RickXy/mesa/install/deqp-venus.toml --output /builds/RickXy/mesa/results --skips /builds/RickXy/mesa/install/all-skips.txt /builds/RickXy/mesa/install/venus-skips.txt --flakes /builds/RickXy/mesa/install/venus-flakes.txt --testlog-to-xml /deqp-tools/testlog-to-xml --fraction-start 1 --fraction 60 --jobs 16 --baseline /builds/RickXy/mesa/install/venus-fails.txt
Error: Failed to invoke dEQP for dEQP-VK.info.device:
stdout:
Writing test log into /builds/RickXy/mesa/results/dEQP-VK.info.device
dEQP Core 3299a07b86cf0b15f86d1a441e323e515b15f255 (0x3299a07b) starting..
target implementation = 'Default'
stderr:
MESA-VIRTIO: debug: one of required kernel params (4 or 9) is missing
FATAL ERROR: vk.enumeratePhysicalDevices(instance, &numDevices, nullptr): VK_ERROR_INITIALIZATION_FAILED at vkQueryUtil.cpp:83
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Drop the test from the fail list
It is reported to pass with Linux 6.16
```
Unexpected results:
07:33:07.167: KHR-GL46.sparse_texture2_tests.UncommittedRegionsAccess_texture_cube_map_r32i,Crash
07:33:07.167: spec@!opengl 1.1@streaming-texture-leak,UnexpectedImprovement(Pass)
```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Update zink-avn-adl flakes list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add flake to zink-anv-adl skip list
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
ci: Add api@clgetdeviceinfo to Intel fails list
This api call is failing for Intel as well, like many of the other
types.
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36493>
In the C23 standard unreachable() is now a predefined function-like
macro in <stddef.h>
See https://android.googlesource.com/platform/bionic/+/HEAD/docs/c23.md#is-now-a-predefined-function_like-macro-in
And this causes build errors when building for C23:
-----------------------------------------------------------------------
In file included from ../src/util/log.h:30,
from ../src/util/log.c:30:
../src/util/macros.h:123:9: warning: "unreachable" redefined
123 | #define unreachable(str) \
| ^~~~~~~~~~~
In file included from ../src/util/macros.h:31:
/usr/lib/gcc/x86_64-linux-gnu/14/include/stddef.h:456:9: note: this is the location of the previous definition
456 | #define unreachable() (__builtin_unreachable ())
| ^~~~~~~~~~~
-----------------------------------------------------------------------
So don't redefine it with the same name, but use the name UNREACHABLE()
to also signify it's a macro.
Using a different name also makes sense because the behavior of the
macro was extending the one of __builtin_unreachable() anyway, and it
also had a different signature, accepting one argument, compared to the
standard unreachable() with no arguments.
This change improves the chances of building mesa with the C23 standard,
which for instance is the default in recent AOSP versions.
All the instances of the macro, including the definition, were updated
with the following command line:
git grep -l '[^_]unreachable(' -- "src/**" | sort | uniq | \
while read file; \
do \
sed -e 's/\([^_]\)unreachable(/\1UNREACHABLE(/g' -i "$file"; \
done && \
sed -e 's/#undef unreachable/#undef UNREACHABLE/g' -i src/intel/isl/isl_aux_info.c
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
