DebugMarkerSetObjectNameEXT is just a less powerful version of
SetDebugUtilsObjectNameEXT. Fixes the objectType cast warning as well.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27975>
vk_shader_init_cache_obj() is fast enough and the already-found case is
rare enough that there's no good reason to avoid the init. This allows
us to use vk_shader_unref instead of vk_shader_destroy which is probably
a touch safer over-all. It also fixes the assert that the two shaders
have matching keys.
Fixes: bb8b11d806 ("vulkan/pipeline: Handle fully compiled library shaders properly")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10752
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27993>
Some people seem to have systems with more than 8 GPUs installed at
once. 256 is the maximum number of devices returned by libdrm, so using
this seems like a good choice for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27901>
We can have multiple swapchains, and we can also have retired swap chains
that can continue to deliver events briefly after being replaced. It's
helpful to have both a surface id and a per surface swapchain id.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27852>
PresentWait can still be called on a retired swapchain, and pilfering
the WSI surface can cause issues. To avoid retired swapchains
interfering with non-retired swapchain event queue, flag a swapchain as
retired instead and immediately return OUT_OF_DATE from acquire and
present.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
Instead of coding our own polling function, use the (new) wayland
wl_display_dispatch_queue_timeout() function instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
If we want to use the new wl_display_dispatch_queue_timeout function
in libwayland we lose the ability to drop the lock while we poll
and pick it up again to dispatch.
That would cause other waiters to potentially block past their
timeouts while waiting for the dispatching thread's timeout.
Prepare for this change now by dropping the lock for the entire
dispatch, and reacquiring the lock in the functions being dispatched.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
We do own the lock if there's a timeout, and the code is written with that
in mind - but the comment seems to imply otherwise.
Drop it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
this is a bandaid fix that allows users (zink) to actually call the
functions intended to be called. the real fix would be to figure out
which extensions are enabled on the device and then only GPA the
functions associated with those extensions
that's too hard though so I'm slapping some flex tape on it
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27834>
In the fast-link case, we should just use the library shader and assume
that it's correct. We have to do this because we may not have a
precompiled shader in this case so we can't even generate the shader
hash.
In the link optimization case, we could still have a library shader
coming in from some library pipeline. That shader may happen to be
correct, in which case we can just use it and not even bother digging
around in the cache. In the more likely case, the keys won't match and
we should throw it away before we look up a different shader in the
cache and leak our reference.
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementation")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27860>
These implementations are built on top of vk_shader. For the most part,
the driver shouldn't notice a difference between draws consuming
pipelines vs. draws consuming shaders. The only real difference is
that, when vk_driver_shader_ops::compile() is called for pipelines, a
struct vk_graphics_pipeline_state is provided. For shader objects, the
state object will be NULL indicating that all state is unknown. Besides
that, all the rest of the differences between Vulkan 1.0 pipelines,
VK_EXT_graphics_pipeline_library, and VK_EXT_shader_object are handled
by the Vulkan runtime code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
We need to be able to thunk through a destroy callback if we want to
have different kinds of pipelines implemented in different parts of the
stack.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
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>
