I had originally intended to hook this up properly with synchronization et al,
but I didn't do it, and now it's seeming less smart anyway, so let's
remove the footgun
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17066>
this is basically just a wrapper around vulkan semaphores, so it maps
fairly well
the existing fence function was a big ??? and should never have been triggered
like it was
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14498>
it was useful to have this be a hash table back before timeline semaphores when
the batch state needed to be looked up every time to determine resource busy state,
but now in the modern world, this is almost never happening, and storing them like
this is actually worse for performance, so flatten it out into a simpler list
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13265>
this works by tracking 1024-member arrays of images and textures using idalloc
for indexing. each idalloc id is an index into the array that is returned as a handle,
and this handle is used to index into the array in shaders.
in the driver, VK_EXT_descriptor_indexing features are used to enable updates on the live
bindless descriptor set and leave unused members of the arrays unbound, which works as
long as no member is updated while it is in use. to avoid this, idalloc ids must cycle through
a batch once the image/texture handle is destroyed before being returned to the available pool
in shaders, bindless ops come in one of two types:
- i/o variables
- bindless instructions
for i/o, the image/texture variables have to be rewritten back to the integer
handles which represent them so that the successive shader stage utilizing them
can perform the indexing
for instructions, the src representing the image/texture has to be rewritten as a deref
into the bindless image/texture array
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12855>
unrefs here (almost always) mean destruction, which means eating the cost
of the atomics for the unrefs and then also the destructors
instead, handle this at the end of the next submit from this batch, since the
submit thread is never as busy as the driver thread
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12759>
this is a waste of cycles now that surfaces are accurately tracked;
no-attachment fbs are still deferred to avoid premature deletion
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12429>
batch tracking has until now been the same as refcounting, but this
is inefficient and incurs additional overhead from constant atomic ops,
so make them separate
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11684>
The way p_atomic_cmpxchg is implemented on Windows really wants us to
use integers instead of things like pointers. So let's use uintptr_t
here. It seems cleaner to use that than the value zero for the last
argument, because it shows the intent of the code more clearly.
Fixes: d80d9e1c93 ("zink: queue v3.0")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11424>
now that submission is serialized better, it's not actually the resource that should be
tagged for scanout sync, it's the batch state, as multiple contexts might reuse the same
resource, thus requiring synchronization on every submit
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
this doesn't seem to be a real issue now that tc doesn't break makeCurrent
anymore, but if such a thing were to once again become a problem, at least
there will be handling for it
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
this uses a pointer to a batch state substruct for timeline tracking,
which provides a few nice benefits:
* explicit ability to detect unflushed batches (even on other contexts)
* the context doesn't need to have a "current" timeline id
* timeline (batch) ids can be distributed during submit, not when recording begins
* an abstracted api which can be more easily changed under the hood
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
instead of storing separate batch_id values onto the tc fence for matching:
* use a fence pointer on the main context to indicate the current deferred fence
* add a monotonic counter to each batch state which double-increments on each use,
thereby enabling direct determination by the tc fence as to whether this is the same
batch state it was created with
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11437>
this shouldn't be necessary since usage can only be set from the context thread
and only needs to be accessed atomically for the cmpxchg when unsetting
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11399>
when emitting barriers, we don't need to end the renderpass in some cases
this handles the case of emitting barriers for new resources which have
never before been accessed and thus do not require synchronization at a
specific point in the batch
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10700>
I misread the spec, and it turns out timeline ids can't be reused across
semaphores. This is obvious in retrospect, but what can be done?
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Tested-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10115>
this includes:
* async buffer mapping/replacement
* async queue submission
* async (threaded) gallium flush handling
the main churn here is from handling async gallium flushes, which involves
creating multiple gallium fences (zink_tc_fence) for each zink fence (zink_fence).
a tc fence may begin waiting for completion at any time, even before the zink_fence
has had its cmdbuf(s) submitted, so handling this type of desync ends up needing
almost a complete rewrite of the existing queue architecture
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9935>
now that batches aren't limited and flushing is less costly, there's no
reason to keep these separate
the primary changes here are removing the zink_queue enum and collapsing
related arrays which used it as an index, e.g., zink_batch_usage into single
members
remaining future work here will include removing synchronization flushes which
are no longer necessary and (eventually) removing batch params from a number of
functions since there is now only ever a single batch
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9765>
this will be useful in the future when we need additional work to handle
resets of states that aren't detected as being "completed"
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9765>
Mike Blumenkrantz
Erik Faye-Lund