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>
if we know that the descriptor set is cached and already in use by a given
batch, then we also know that all the resources in the set are tracked, which
means that we can skip over some looping during descriptor updates which would
otherwise be used to add tracking for sampler/image views/states
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9567>
this massively cuts down cpu time for hashing and lookups, resulting in
a noticeable performance increase
the sampler_state batch usage for now is just being set for future use when
it will be leveraged to permit immediate deletion
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9567>
If the availability has to be written it needs to be written
to the correct place.
The host query reset tests fall over this.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9594>
gfx and compute programs both end up with an extra ref from creation,
so they both need to lose a ref during creation after they get their
shader refs
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9470>
if we destroy a program object which is currently the "active" program then
we need to unset the pointer to avoid invalid access
also unset injected tcs pointers where appropriate
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9470>
we have implicit sync hooked up for drivers now so we don't need to worry
about drawing over our frontbuffer unexpectedly
still a weird issue remaining where we miss the first frame without an explicit
fence, but I expect that will get resolved eventually by wsi
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9290>
this is a global cache for all surface objects, enabling some memory
optimizations as well as improved reuse of cached descriptors
loosely based on patches from Antonio Caggiano
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9541>
we already have the batch usage info here for the resource, so if we know
the resource is already used on the batch then we don't need to also perform
a hash lookup to double check that it's really there
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9565>
Fix defect reported by Coverity Scan.
Uninitialized pointer field (UNINIT_CTOR)
member_not_init_in_gen_ctor: The compiler-generated constructor
for this class does not initialize r63.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9326>
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>
list_length() complexity is O(n), so it's better to store number of regs
separately and use it instead of list_length().
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9570>
This flag will be used by run from mesa-shader-db to trigger shader
compilation with default settings.
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9583>
The in-memory shader cache can get significantly
huge in some rare cases.
Limit its size to 64MB on 32 bits, and 1GB else.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9578>
The disadvantages of the DYNAMIC path over the
non-dynamic path are minor.
The advantages are many.
As we don't know if bad behaving apps use
non-dynamic SYSTEMMEM in a dynamic fashion,
let's be safe and always be dynamic.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
SW vertex processing buffers are supposed to be sorted in RAM
and to be immediately idle after use (thus you can write at the
same location again immediately).
DYNAMIC SYSTEMMEM is by far the best fit for now for these kind
of buffers, though it can be improved further. Indeed the use
pattern will cause a lot of syncs with csmt actived.
Thus disable csmt when full sw vertex processing is requested.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
Some apps use DYNAMIC SYSTEMMEM buffers and fill them in a
dynamic fashion with discard and nooverwrite locking flags.
To prevent uploading the whole buffer every draw call,
track the region needed for the draw call, and
upload only that region (or a bit more in order
to ease valid region tracking).
Try to aggressively upload with discard/unsynchronized.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
The tracking enables to avoid flushing the csmt thread
when locking repeatedly the same buffer, as long
as the locks are non-overlapping.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
Use the MANAGED path for SYSTEMMEM buffers.
Tests point out the locking behaviour of SYSTEMEMM
buffers is very close to MANAGED.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
So far we did nothing on EndScene, but the API
doc says it flushes the GPU command queue.
The doc implies one can optimize CPU usage
by calling EndScene long before Present() is called.
Implementing the flush behaviour gives me +15-20%
on the CPU limited Halo. On the other hand, do limit
the flush to only once per frame.
3DMark03/3Mark05 get a 2% perf hit with the patch,
but 5% if I allow more flushes.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9451>
the push set index isn't always 0, so the offsets need to be updated
in order to avoid clobbering other sets
Fixes: 6be19765cf ("lavapipe: add support for VK_KHR_push_descriptor")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9558>
gen_device_info will try to use the most recent uAPI to get this
number and will fallback to this get_param. So just use what was
queries by gen_device_info_from_fd().
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9052>
accidentally left this in while bisecting
Fixes: 929a748401 ("zink: avoid hashing states without descriptors")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9564>
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 reorder the pipeline state and avoid hashing the big arrays based
on context states that we already have available to us
also we can do incremental hashes for the shader modules to further reduce
hashing
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9539>
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>
Mike Blumenkrantz
Dave Airlie
Michel Zou
Pierre-Eric Pelloux-Prayer
Vinson Lee
Vasily Khoruzhick
Gert Wollny
Axel Davy
Eric Anholt
Lionel Landwerlin