this really just means to nuke the counter buffer, and this can be done
by using a special bind_history bit that can be unset when the buffer has
been rebound
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9546>
this creates new backing objects for the invalidated resource and, if
needed, rebinds it to any descriptor sets it might be used in by invalidating
the descriptor state and creating new view objects
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9546>
the resource object is now a state tracker for the inner resource_object,
so it can safely be destroyed even if the backing resource is still in use
this also requires updating various things to keep descriptor states/caches working
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9544>
this was only needed to cover up some other bugs:
* missing barriers for buffer sampler/image descriptors
* weirdness with first frame handling
there's better ways of handling both cases, and now they're handled better
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9566>
this stores a number (currently 5) of backing allocations for resources
for later reuse when creating matching resources
because this is on the screen object it requires locking, but this is still
far faster than allocating new memory each time
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9540>
we can pass the offset of the 'invalid' flag directly to the resources
to let them run through and invalidate their sets in time for us to detect
it when we recycle the set during batch reset and throw it onto our allocation array
additionally, by adding refs for the actual objects used in a descriptor set, we can
ensure that our cache is as accurate as possible
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this is a lot of churn that more or less amounts to hashing the descriptor
state during draw and then performing lookups with this to determine whether
we can reuse an existing descriptor set instead of allocating one
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
Use debug_printf more consistently, normalize formatting a bit, and
trace a few more places you're likely to care about.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9436>
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>
