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>
This is based on:
1. external format handling has been made passive
2. blob mapping size has been made passive
3. common helper has improved mem type reporting
Reviewed-by: Antonio Ospite <antonio.ospite@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36388>
Use the convention for Rust subprojects that was adopted by Meson 1.5.0
and newer.
Distros would prefer to avoid vendored crate sources, and instead use
local sources from e.g. /usr/share/cargo/registry. While Meson does not
support a local registry, it can be emulated with MESON_PACKAGE_CACHE_DIR.
However, because the distro might not be using the exact version of the
package, but only one that has the same semver, packagers need to add
some hacks to rewrite the wrap files. For example, in Fedora:
export MESON_PACKAGE_CACHE_DIR="%{cargo_registry}/"
# So... Meson can't actually find them without tweaks
%define inst_crate_nameversion() %(basename %{cargo_registry}/%{1}-*)
%define rewrite_wrap_file() sed -e "/source.*/d" -e "s/%{1}-.*/%{inst_crate_nameversion %{1}}/" -i subprojects/%{1}.wrap
%rewrite_wrap_file proc-macro2
%rewrite_wrap_file quote
%rewrite_wrap_file syn
%rewrite_wrap_file unicode-ident
%rewrite_wrap_file paste
Having a common convention for the name of Rust wraps makes it possible
to perform this transformation with a script without listing
the wraps one by one, and to share the script across multiple packages
(which will be useful when QEMU starts using Rust in a similar way to Mesa).
For an example of such a script, see
https://lore.kernel.org/r/20250722083507.678542-1-pbonzini@redhat.com/.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36284>
For import, requested size might be smaller than the whole blob mem
size. Currently, venus virtgpu backend tracks the initial import size
and sanity checks with later re-import size. So let's add a way to
request whole blob mem size
No need vtest backend changes since dma_buf import is not supported.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36128>
Prepare for adopting common runtime so that we don't leave unused vars
after dropping codes from vn_AllocateMemory. It's trying to minimize
code changes in the venus adoption since that'd be huge.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36128>
Instead of failing the import, drop the mappable bit if blob size is
smaller than the requested alloc size, which defers the error to the
intended vkMapMemory api call if the client app requests Vulkan mapping
from the imported external memory.
Normally this won't occur if the app obeys the spec with a properly
implemented blob mem allocator. However, legacy allocators like minigbm
virtgpu_virgl backend could allocate via virgl w/o knowing the real blob
size from the guest side. The unsatified cases are external gralloc
images, which won't be mapped in any meaningful way after being
imported. This is to prepare dropping the force_unmappable workaround,
and to further prepare adopting common Android runtime.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36128>
It is a tech debt now since NV proprietary is on sw wsi path, and
rendering to the prime blit dst buffer may never get supported there.
For later, when performance optimization is needed for venus on nv, we
can downgrade the sw wsi device workaround to a venus dri config, so
that setups with tiled explicit modifier support can be perf optimal.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35984>
