we have src regions for all the blit/copy/map calls, so we can use those to
verify whether we actually need to apply the clears now or if we can keep
sitting on them a while longer
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9206>
instead, we can attach the clear to the next renderpass start and even add it to
the renderpass cache for reuse
also add handling for flushing clears on map or fb switching to avoid brekaing behavior
this should save us a lot of time with potentially beginning/ending renderpasses as well
as allowing drivers to do better batching of clears by passing in all the buffers at
once
this doesn't handle deferring conditional renders yet in a futile attempt to try and keep
the size of the patch down
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9206>
when discarding the whole resource on an unused resource, we can deinit the buffer
range here
in the future, ideally we should be doing something like creating a new vk buffer/image
entirely here and demoting the existing one to a queue that destroys/caches it when
the batch finishes in order to avoid fencing
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
we don't actually have to stall here, we just have to make sure the cs batch
is submitted before the subsequent buffer copy command goes into a gfx
batch in order to preserve the ordering
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
if we need to sync a resource for read-only mapping, we only need to wait on
the fence that was last flagged as having writes to the resource, not batches
that may have reads, as reads don't affect memory coherency
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
this now takes over from previous call sites in zink_transfer_unmap
we add a flush here if we had pending usage to ensure that the resource
gets properly synced
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9146>
this simplifies the barrier helper callsites as we no longer need
to check whether a barrier is needed beforehand in order to avoid potentially
ending a renderpass too early
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9205>
* VK_BUFFER_USAGE_STORAGE_BUFFER_BIT should be enabled always because we might need it
* VK_FORMAT_FEATURE* flags need to be used for detection
I hate these enums so much.
Fixes: 2bfa998960 ("zink: add more usage bits for buffer types")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9175>
we need more detail on some of these to ensure proper synchronization
and availability/visibility of image data between commands/stages
the signature for needs_barrier() is still funky here to avoid breaking
usage in update_descriptors()
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8945>
We don't need to create display-targets for shared or scanout, becuase
we never even see those in the sw-winsys case.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
The only type that should really require to be host-visible is the
display-target, and that's just because of our silly flush_frontbuffer
implementation.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
We only need these display-targets to be linear in the case of a
software winsys. In the DRM case, they can be tiled without issues.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
The reason we check for staging-resources here is really because they
are the only images guaranteed to be host-visible.
But on UMA architectures, it's quite likely to have memory that is
*both* host-visible *and* device-local, so let's see what we found
instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8858>
now that we have the capability to wait on specific batches, we can
check whether we need to sync with the compute queue here before trying
to map resources
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8781>
this is a huge perf hog that will be improved on later, but it's necessary for now
in order to correctly determine whether we can use resources as shader images
since gallium gives us no info about usage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8504>
This is close to a revert of commit
b5b25ee032, but it limits the scope a bit
to avoid needless performance degregation.
In the long run, we should really allow using tiled resources here, and
instead detile while presenting.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8115>
I got confused and:
* used the vkformat instead of the pipe format for getting format description
* incorrectly calculated bpp
but this time it's definitely 100% fixed I promise
Fixes: 456b57802e ("zink: fix direct image mapping offset")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8074>
the x and y offsets here were improperly calculated without taking into account:
* layer/level offset
* x/y coord bpp
Fixes: 8d46e35d16 ("zink: introduce opengl over vulkan")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8058>
We need to always have barriers between individual uses of resources
in the general-layout, because otherwise a write-cache might not be
flushed before the resource is used.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7652>
guard the drm includes that are not available on this platform
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/7432>
Some drivers will drop warnings about seeing these structs in the
pNext chain and not handling them. This change makes it so we
only include the structs with Vulkan drivers that are known to
require them for proper behavior (v3dv only for now) to avoid the
warnings.
It should be noted that here we are only supressing the messages
from Zink. Since the Mesa Vulkan WSI code will include these structs,
when native Vulkan Mesa drivers are used without Zink they might
still dump these messages.
Requested by Mike Blumenkrantz.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7523>
On MoltenVK/MacOS when mapping memory that should already have content it does not appear until flushed.
This noticably effects vertex attribute uploads to descrete devices.
Did also try to add the Coherent memory flag, which did work, until there the Coherent type could only be used for transfer usage only.
This is a known limitation of MoltenVK.
See https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/MoltenVK_Runtime_UserGuide.md#known-moltenvk-limitations
Seen when using MoltenVK 1.0.121, 1.2.131
Acked-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/7470>
Since Zink doesn't use swapchains to create presentable images, drivers
lose the capacity to identify memory allocations for them, which is a problem
when the underlying platform has special requirements for these, such as
needing to allocate them on a particular device. Including this struct in the
pNext chain, which is the same thing that the Mesa Vulkan WSI code does when
allocating memory for swapchain images, gives drivers a chance to identify
and handle these memory allocations properly.
v2: follow Zink's conventions for pNext chains (Mike)
v3: add scanout parameter for VkImage creation (Daniel)
v4: don't add a dependency on vulkan util (Erik)
v5: include vulkan directory for Zink builds
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> (v2)
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7378>
Zink doesn't support forwarding DRM modifiers yet, so whenever those are
used, we end up ignoring them. That's not going to do the right thing in
most cases, so let's reject them instead.
Since d686835171, the dri2 code tries to create a 0x0 surface without
any format when trying to import. This makes this go from
rendering-issues to asserting in debug builds, making things even worse.
Fixes: d686835171 ("gallium/dri2: Support I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS import")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3654
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7214>
we're using our (primitive) buffer r/w tracking here to ensure that our
src buffers are synchronized before we do any kind of read operation on them
this is pretty slow in some cases, but it fixes a bunch of piglit tests
Reviewed-by: Erik Faye-Lun <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6924>
