if a resource is used multiple times with different samplers then this can result
in conflicting layouts, so it's better to just use the general case here
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this can be inferred from a resource's barrier usage, and then by merging
the batch-tracking for resources into the barrier loop, this deduplicates
calls for resources which are bound for multiple stages as well as removing
another iteration during descriptor updating
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
we can do this once here instead of accumulating the count all over later
also remove the debug value on the set which duplicated this
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
if we aren't invalidating the descriptor set then we can safely reuse its
barriers to avoid doing any sort of hashing during descriptor updating
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
now that we've split these into their own objects, we can reuse them across
programs with matching binding layouts for a given type, giving even more value to
the descriptor set cache by increasing reuse
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
if we're going to be sharing pools across programs, it's no longer sufficient
to check the hash populations, so we need a separate counter to know when we have
to flush
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
by pushing these into a separate struct, we can eventually reuse them between
programs to make the descriptor set caches even more valuable
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this is getting to be enough code that it's getting to be a hassle to
keep with the program stuff
also rename a couple of the moved functions
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
all the descriptor updates are now broken out, so update_descriptors is now just
a dispatch for calling the other update functions
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
now that we're doing incremental updates, we can refactor this to be much
more readable by having separate functions for each type of descriptor update
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
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>
now that we're guaranteed to know what our batch is earlier, we can move this
referencing around to reduce the number of hash lookups we'll perform here
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
no functional changes, but it moves the only point in the function where a
flush can occur out of the way which lets us get the batch we'll be using
immediately
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
we can avoid some hash lookups this way, and we can also avoid putting the null
descriptor sets back into the array since we know they'll always be the last-used
set
this also helps our null set reuse be more explicit since we never have to put these sets
back into an array or anything
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this greatly reduces the amount of on-demand hashing that we have to do,
as now in worst case we'll be hashing 2x uint32_t per sampler descriptor
vs 2x vulkan object pointer (sometimes a uint64_t) and a uint32_t
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this aims to track the states of descriptors so that we can do more incremental
updating
it also enables the descriptor cache to be more robust by providing the incremental
data as the key
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this uses multiple descriptor sets so that we can perform more incremental
updating and increase the value that we get from our cache by only invalidating
one state at a time
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
this lets us store sets that are valid but not currently used so that we
can either prolongue a cache entry's lifetime or cannibalize a valid entry
if necessary to avoid needing to allocate more sets
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>
now descriptor sets allocate in increasingly large batches based on how many
sets a program has allocated, multiplying by 10 any time the sets hit a power of
10, e.g., if 100 sets are allocated, we now allocate in batches of 100
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
now instead of allocating a single descriptorset at a time, we allocate
a defined count of descriptorsets (currently 10) at once and keep a separate
array of allocated-and-unused sets that we can pop sets off of
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
now that we do all our tracking and flushing per-program, we can throw
out the batch-based flushing and let our descriptors free-range
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
in addition to ensuring that all our batches stay under the max size by cycling
them whenever we get too many active descriptors going, we now do per-program
descriptor pools, so we can do some limiting there as well to ensure that we
aren't letting any one program hog all the resources
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9348>
