This adds a new base vk_shader object along with vtables for creating,
binding, and working with shader objects.
Unlike other parts of the runtime, the new shader object code is a bit
more sanitized and opinionated than just handing you the Vulkan
entrypoints. For one thing, the create_shaders() calback takes a NIR
shader, not SPIR-V. Conversion of SPIR-V into NIR, handling of magic
meta NIR shaders, etc. is all done in common code. [De]serialization is
done via `struct blob` and the common code does a checksum of the binary
and handles rejecting invalid binaries based on shaderBinaryUUID and
shaderBinaryVersion. This should make life a bit easier for driver
authors as well as provides a bit nicer interface for building the
common pipeline implementation on top of shader objects.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
wayland-client stores up to MAX_FDS_OUT (28) outgoing fds and
then release them in batch later through close_fds.
While this is not a problem in normal situation, because the
app would also have a reference to the same buffers, this is
an issue when these buffers are released (eg: because the
swapchain creation failed).
In this situation wayland-client owns the last ref to these
buffers and prevent their deletion.
This is an issue with dEQP-VK.wsi.wayland.swapchain.simulate_oom.image_extent
because it creates swapchains in a fast loop with a failing allocator
to fail the swapchain creation.
Without this change, on a 16GB dGPU the test peaks at 95% VRAM / 60% GTT and
completes in 1.5 sec.
With this change, the max usage is 65% VRAM / 10% GTT and completes it
in 0.3 sec.
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27592>
mesa-overlay with control arg fails to setup socket properly when multiple
adapters launched. First adapter listens to socket, blocking all remaining
adapters. This is a common occurrence with games using lauchers where the
launcher is also a vulkan app. Fixed by deferring socket listening to first
frame rendered, which should be the game.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27538>
DRM modifiers are a BSD/Linux phenomenon.
We can also remove a bunch of these checks too. No Linux specific
symbol or header is **actually** used, and the DRM modifier is
just represented as uint64_t. But kept the style of the file
as is.
Reviewed-by: Serdar Kocdemir <kocdemir@google.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27425>
When presentation feedback protocol is not supported,
fallback to using frame callbacks.
In some sense, frame callbacks functions like
present complete + latch delay, so it's a reasonable approach, given the
alternative.
Xwl uses frame callback for COMPLETE events, so it's not a new approach.
To guard against lack of forward progress guarantee,
add a timeout for present complete to avoid deadlocking applications.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27275>
The runtime is turning GENERAL layouts into FEEDBACK_LOOP ones when it
detects feedback loops in a render pass. This is breaking drivers that
would like to use a different HW layout for those 2 layouts because if
the application inserts barrier in the render pass, the barriers the
driver sees are inconsistent.
This could lead to barrier of this type :
- GENERAL -> FEEDBACK_LOOP (runtime)
- GENERAL -> GENERAL (app)
- FEEDBACK_LOOP -> GENERAL (runtime)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23523>
The current implementation has many different code paths which get very
messy to reason about and maintain.
- FIFO mode worked well enough.
- IMMEDIATE did not need a thread at all, but present wait
implementation complicated a lot of things since we had to handle
concurrent special event reads.
- MAILBOX (and Xwayland) adds even more jank on top of this where
have present thread, but no acquire thread, so there are tons of
forward progress issues to consider.
In the new model, we have two threads:
- Queue thread is only responsible for receiving presents, waiting for
them if necessary, and submitting them to X.
- Event thread pumps the special event queue and notifies
other threads about frame completions.
- Application thread does not interact with X directly, only through
acquire/present queues and present wait condvar.
Two threads are required to implement IMMEDIATE and MAILBOX well.
IDLE events can come back at any time and the queue thread might be
waiting for a new presentation request to come through.
This new model has the advantage that we will be able to implement
VK_EXT_swapchain_maintenance1 in a more reasonable way, since we can
just toggle the present mode per present request as all presentation
go through the same system.
Some cleanups were done as well:
- We no longer need the busy bool. Since everything goes through thread,
we just rely on acquire/present queues.
- SW/non-MITSHM path is also moved to thread. Move acquire-specific
logic to the thread as well.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26954>
Faith Ekstrand