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>
Because these functions were introduced by VK_EXT_shader_objects, we
technically have to expose them even though they have to do with NV
extensions that no one else supports.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
We're supposed to just ignore samples above what we support, and there's
no VU matching this assert. Fixes a crash in
dEQP-VK.pipeline.shader_object_unlinked_spirv.extended_dynamic_state.misc.sample_shading_dynamic_sample_count.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
This is almost a 1:1 copy of the same function in libwayland. If the version
with the symbol propagates far enough the fallback can be removed again.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27511>
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>
We don't need to start iterating from `pProperties`, as the first member
is already handled in vk_common_GetPhysicalDeviceProperties2. Eliminate
this iteration by starting from pProperties->pNext.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27671>
MAILBOX reduced from 5 to 4 to be more inline with WL.
With xwayland_wait_ready = false now being the default,
add some extra consideration for non-FIFO present modes.
Add a lengthy rationale for why minImageCount = 3 is exposed on Xwl.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27074>
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>
I missed a bunch of things like input tracking. Also take the
opportunity to rename things.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: fe19405c46 ("vulkan/runtime: handle new dynamic states for attachment remapping")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27380>
The fallback in place ensures a good enough solution.
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>
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>
Avoids having to take extra locks in acquire/present.
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>
With present ID and IMMEDIATE/MAILBOX, waiting for completion
before submitting a new frame will limit frame rate to a multiple
of refresh rate, which is not ideal. We should be able to pump frames as
fast as IDLE callback, not limited by COMPLETE.
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>
Allow toggling between all presentation modes.
After the rewrite, this is now trivial to support.
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>
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>
This works better if vk_dispatch_table.h is inside some "genDir",
and not generated "src/vulkan/util" directory. This is the
case for the AOSP Soong build system.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26874>
Talos Principle and related games on that engine fail to handle
SUBOPTIMAL properly. Adds an option to ignore SUBOPTIMAL and pretend
it's SUCCESS.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27037>
When receiving SUBOPTIMAL_COPY, we need to consider that it can be a
false positive. Xwayland may send this suboptimal copy if there are
pending DRM modifier feedbacks from compositor, but it's likely the
modifier lists are identical.
Hash the modifier lists and compare them against the newly queried
modifier list when SUBOPTIMAL_COPY is received to work around false
positives.
This fixes crashes in games that cannot handle SUBOPTIMAL correctly,
and avoid needless stutters when entering full-screen modes.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27035>
Joshua Ashton pointed out we aren't copying these deeply,
and we really should be.
This introduces deep copies of all the h264/h265 parameter sets.
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27066>
