There are too many reports of instability in the wild,
even in scenarios where anti-lag isn't really being actively used,
making it questionable to load the layer by default.
By using enable_environment, a certain environment variable
must be set for loader to consider loading the layer.
This could be removed once the layer stabilizes.
Cc: mesa-stable
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37509>
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>
The hardware support for stencil texturing is unclear from RE and
the feature databases. Enable this extension on halti5 GPUs as a
conservative starting point.
This also enables ARB_texture_stencil8.
Passes:
- dEQP-GLES31.functional.stencil_texturing.format.stencil_index8*
- dEQP-GLES31.functional.stencil_texturing.format.depth24_*
- arb_texture_stencil8 piglit
- arb_stencil_texture piglit
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37578>
This is the header that's *actually* needed here, pvr_private.h just
pulls it in for us. Since this is a header-file, let's use as narrow
includes as we can to avoid including everything everywhere and terrible
build times.
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37554>
Because s_sendmsg dealloc_vgprs waits for every counter except vs_count,
and the message bus has limited throughput, we should only insert the dealloc
when we know that it's beneficial.
Foz-DB Navi31:
Totals from 5280 (6.58% of 80273) affected shaders:
Instrs: 4186851 -> 4197416 (+0.25%)
CodeSize: 21910004 -> 21952264 (+0.19%)
Latency: 31679067 -> 31679173 (+0.00%)
InvThroughput: 9182625 -> 9183417 (+0.01%)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37508>
Turns out just putting the u32 in doesn't work on big endian, so
put the proper u8/u16 values in.
Got a report that since the loop limiter got removed, a gtk4 blur
shader was looping forever on s390x. Turns out it was using a 16-bit
loop variable (because why wouldn't you), and the loop counter was
just staying at 0 all the time.
Cc: mesa-stable
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37593>
os_get_option() is a wrapper for getenv() that checks properties in
Android. It should be a no-op for other OS but will allow full use of
env vars in Android.
The environment variable names are automatically renamed by
os_get_option() and the order of precedence thus becomes:
1. getenv (non-Android)
2. debug.mesa.* (Android)
3. vendor.mesa.* (Android)
4. mesa.* (Android, as a fallback for older versions)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37587>
After commit 45eb3bfd32 (device-select: only try wayland/x11 if the
required vars are set, 2024-10-18), building `device_select_layer.c` can
results in compiler errors on some stricter build configurations
(-Werror,-Wunused-variable):
-----------------------------------------------------------------------
../src/vulkan/device-select-layer/device_select_layer.c:149:9: error: unused variable 'has_wayland' [-Werror,-Wunused-variable]
149 | bool has_wayland = getenv("WAYLAND_DISPLAY") || getenv("WAYLAND_SOCKET");
| ^~~~~~~~~~~
../src/vulkan/device-select-layer/device_select_layer.c:150:9: error: unused variable 'has_xcb' [-Werror,-Wunused-variable]
150 | bool has_xcb = !!getenv("DISPLAY");
| ^~~~~~~
2 errors generated.
-----------------------------------------------------------------------
So guard the declarations of the `has_wayland` and `has_xcb` variables
behind `VK_USE_PLATFORM_WAYLAND_KHR` and `VK_USE_PLATFORM_XCB_KHR`
respectively, just like the user code.
Note: the declarations are still kept outside of the loop body, in order
to assign the variables once and for all.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37571>
