image_gather4_b_o no longer exists apparently, so this is likely
broken.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19230>
Some tricky dynamic states still need to be implemented for full ds3
support with Zink, I will implement them later.
Pass dEQP-VK.pipeline.*extended_dynamic_state* on NAVI21.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18882>
Using dri2_create_image_khr_texture_error() here prints an error
like so:
command: eglCreateImageKHR, error: EGL_BAD_ALLOC (0x3003), message: "dri2_create_image_khr_texture"
This is confusing, because dri2_create_image_khr_texture() is
unrelated to this error.
Instead, print a more accurate error manually.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19156>
It's not just because we received dma-buf feedback that we should
re-allocate, as sometimes it is useless.
We must compare the most recent allocation parameters used and the ones
that we have with the newest feedback. So do that.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
Follow up of "vulkan/wsi/wayland: add default dma-buf feedback support".
The surface feedback is dynamic, differently from the default feedback.
When we receive per-surface feedback, that means that we could be using
a better DRM format/modifier pair for the chain's buffers. So the next
time that the client calls vkAcquireNextImageKHR(), we return
VK_SUBOPTIMAL_KHR instead of VK_SUCCESS. Some clients will re-create the
swapchain when receiving SUBOPTIMAL, and for those we'll re-create the
chain. An optimal DRM format/modifier pair from the per-surface feedback
will be used to create the images of this swapchain.
Note that for now we won't be able to change the DRM format, only the
modifier. That's good enough for many cases in which direct scanout
would not be possible because of the modifier. In order to be able to
switch the format, we'll need a mechanism to negotiate preferred formats
with clients. Currently we can only expose a set of supported formats
all with the same preference.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
This bumps the supported dma-buf version up to 4 and adds default
dma-buf feedback support. It follows the changes in the dma-buf protocol
extension to include dma-buf feedback.
From version 4 onwards, the dma-buf modifier events are not sent by the
compositor anymore, so we use the default feedback to pick the set of
formats/modifiers supported by the compositor.
In the next commit we add support for per-surface feedback.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
After "vulkan/wsi/wayland: move wl_surface and wl_display from chain to
struct wsi_wl_surface", refcount is being unused. So remove it and its
associated functions.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
When a swapchain is re-created, if the old swapchain is not passed to
us, we need to re-create the wl_display and the Wayland objects. As
described in "vulkan/wsi/wayland: introduce struct wsi_wl_surface", this
gets in the way when adding the dma-buf feedback implementation.
With this change now the lifetime of the Wayland objects is tied to the
VkSurface. When the swapchain gets re-created, we won't have to
re-create the wl_display (and consequently the Wayland objects).
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
When we create a swapchain, take ownership of a struct wsi_wl_surface.
When the chain gets destroyed, the ownership is dropped.
We can safely do that because only a single swapchain can be associated
with the surface at a time, according to vkCreateSwapchainKHR spec:
"If pCreateInfo->oldSwapchain is VK_NULL_HANDLE, and the native
window referred to by pCreateInfo->surface is already associated
with a Vulkan swapchain, VK_ERROR_NATIVE_WINDOW_IN_USE_KHR must
be returned."
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
In the following commits we add dma-buf feedback support. In order to do
that, we need to keep the feedback tied to the lifetime of the surface,
instead of tied to the lifetime of the chain.
Why do we need this change?
The reason is per-surface feedback and swapchain re-creation. If we
receive feedback and return SUBOPTIMAL to the client in the next
acquireNextImage() call, it may re-create the swapchain. If it
doesn't pass us the oldSwapchain, we won't have access to the surface
feedback data (as it was tied to the oldSwapchain). We could bind
again to the surface feedback, but compositors may have a transient
state when we bind to surface feedback, and send a non-optimal batch
of dma-buf feedback which is updated when the drawing loop starts. So
we would re-create the chain with this non-optimal batch, and after a
few moments receive new feedback. This could potentially lead into an
allocation loop, so it is not safe.
Tying the feedback to the lifetime of the VkSurface we don't have to
re-bind to the surface dma-buf feedback every time that the swapchain
is re-created, avoiding this dangerous allocation loop described
above.
So add struct wsi_wl_surface in order to add support for dma-buf
feedback. For now it is just the stub, but in the next commits we start
making use of that.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
We have arbitrary amount of spaces between structs fields types and
their names. That doesn't improve legibility and get in the way when
adding new fields/structs. So remove these spaces.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
There are some structs defined in the middle of the code. Move them
closer to where the other structs are defined.
This makes the code easier to read and also will help us in the next
commits, in which we add dma-buf feedback support.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
This reverts commit 940734630d.
radeonsi and radv now support opaque pointers.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
For argument of type AC_AR_..._PTR, this returns a ac_llvm_pointer.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
Mechanical changes (= use ac_llvm_pointer and adapt the callers/callees)
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
gs_ngg_emit is declared as a 0-size array so we can't store it as a
ac_llvm_pointer.
Instead, we simply modify the ngg_gs_get_vertex_storage to return
a properly typed pointer, when num_outputs is known.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
And switch to the xxx2 versions of the ac/llvm functions.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
The only useful information in pointer types is the address space and these
casts don't change it.
The type information is explicitely passed by the caller of GEP2 and similar
functions.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
This way we can pass the type information to LLVM when needed.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
This way we can pass the type information to LLVM when needed.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
And adapt the only user of this function.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
The cast was superfluous: GEP2 return value is a pointer to
the given type.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
This struct stores a pointer's value and the pointee type and
will be used everywhere LLVM requires us to pass the pointee
type.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19035>
