internal_format is the "real" format of a resource, and the "real" format
of imported resources is the external-facing format, not the pipe format
this ensures the correct format is available for internal ops, such as nplanes queries
Fixes: 2e2775c11b ("zink: fix PIPE_RESOURCE_PARAM_NPLANES with format modifier")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20753>
Some format modifiers change the number of planes used by an image.
For instance AMD DCC modifiers uses 2 or 3 planes. However the
format modifier was ignored in the PIPE_RESOURCE_PARAM_NPLANES
get_param hook.
Fix this by using get_dmabuf_modifier_planes() instead of
util_format_get_num_planes().
This fixes wlroots-based compositors under zink.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: c025cb9ee9 ("zink: fix dmabuf plane returns")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20395>
this should be bug-free, as it passes cts/piglit/gaming on multiple drivers,
but since it's new, it stays behind an env var for at least one release
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20489>
some apps (most notably Wolfenstein: The New Order) have broken multi-context
buffer usage in which one context will attempt to write to a buffer while
another context holds unflushed usage, and the unflushed context will never
flush until the buffer write completes
it's impossible to handle this scenario correctly without deadlocking,
so add some handling to try waiting and then yolo the buffer write if
a deadlock would occur
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19141>
some allocations require a different memory heap even when using the
same memory bits, so allow iterating over heaps of the same memory type
to find the one that works
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19281>
it's possible for drivers to have multiple heaps with identical flags,
so this will enable passing the heap that should actually be used for
allocation
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19281>
an implicit feedback loop occurs when an app happens to bind the same image
as both a framebuffer attachment and a sampler for the same draw
an explicit feedback loop occurs when an app uses fbfetch to read data back
from the framebuffer using input attachments
fbfetch is already handled, but implicit feedback loops require more work:
* detecting them happens on-the-fly
* pipeline variants are required
this handles implicit feedback loops by detecting them at draw time during
barrier updates and then flagging pipeline state change to trigger variant creation.
the bits are then unset when the framebuffer/sampler binds are removed
fixes#7309
fixes (tu):
KHR-GL46.texture_barrier.disjoint-texels
KHR-GL46.texture_barrier.overlapping-texels
KHR-GL46.texture_barrier.same-texel-rw-multipass
KHR-GL46.texture_barrier_ARB.disjoint-texels
KHR-GL46.texture_barrier_ARB.overlapping-texels
KHR-GL46.texture_barrier_ARB.same-texel-rw-multipass
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18787>
instead of incurring all the overhead of tracking lifetimes for these,
it makes more sense to just let them delete whenever and then store
the vk object onto its parent image/buffer to be deleted when that gets
freed, as the parent object's lifetime will always be >= the view's lifetime
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18664>
this is only used by texture views, so use the same mechanism as STORAGE
to add the flag only as-needed
the mutable flag must be set before create_ivci is called for the imageview,
so zink_resource_object_init_mutable() is moved out to the callers of
zink_get_surface instead of being conveniently located in that function
fixes#7174
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18358>
these are supposed to be for dmabuf handling, so checking for mutable
swapchain is both pointless and wrong
Fixes: 28ee911ad6 ("zink: handle mutable swapchain images with dmabuf")
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18358>
Whenever we add or remove a flag here, we need to update a bunch of
drivers in a fragile way. Moving to flags here instead should make this
a bit easier to maintain in the future.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17959>
This reverts commit 247b8f2924.
this attempted to work around what is likely a bug in nvidia's modifier
support, namely their refusal to expose LINEAR as a valid modifier for
some bizarre reason
cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18148>
This reverts commit 49efa73ba1.
this happens to work with mesa (sometimes), but it's going to be
illegal most of the time since swapchain images are treated as though
they are created with OPTIMAL tiling
cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18148>
the non-negotiated path assumes that drivers know what implicit modifiers they're
using, but zink doesn't know what it's doing, so instead try to copy the
swapchain's modifier and reuse that since in theory it should work
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
the spec mandates that all modifiers passed to the driver be valid, so
iterate through all of them and delete the invalid ones
Fixes: 247b8f2924 ("zink: add all format modifiers when adding for dmabuf export")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
if srgb-ness isn't supported by the driver for dmabuf, bail out early with an
error message with the assumption that this would later (maybe) explode when
trying to create a view for srgb framebuffer
ref !17900
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18095>
this significantly untangles all the header includes and fixes an issue
where zink_descriptors.h couldn't be included by certain files due to
type conflicts
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18051>
For external image imports, we'd lose the mutable image format list,
causing turnip to get angry that we try to do UBWC despite not having a
UBWC-compatible format list.
Cc: mesa-stable
Fixes: 28ee911ad6 ("zink: handle mutable swapchain images with dmabuf")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17900>
transfer_map (the only consumer of the flag now) was doing direct mapping
on resources with modifiers (UBWC compressed images on turnip) and
accessing them as linear. We definitely want the staging blit path
instead.
Fixes glReadPixels() from gbm surfaces on turnip.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17549>
if a non-kopper swapchain image supports srgb, add a VkImageFormatListCreateInfo
to permit srgb mutability and avoid violating spec
cc: mesa-stable
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17773>
having this so far down in the BO allocation path meant that slabs were
getting demoted to device-local and then stored as BAR in the pb cache,
which broke the cache pretty badly
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17093>
flush_region is relative to the map, so passing in the offsets again
breaks the flush (if the flush hook is implemented correctly)
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17095>
