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 enum is defined in EXT_framebuffer_object (available on desktop),
and was copied to OES_framebuffer_object (available in GLES1). The ES2
spec has no mention of such an enum. If the underlying implementation
does not support this, it will set a generic incomplete error (as is
done in st_cb_fbo.c if mixed_formats == false).
This should fix the following dEQP tests on ES2 drivers:
dEQP-GLES2.functional.fbo.completeness.attachment_combinations.rbo_tex_none_none
dEQP-GLES2.functional.fbo.completeness.attachment_combinations.tex_rbo_none_none
Fixes: fd017458bc (mesa: fix fbo attachment size check for RBs, make it trigger in ES2)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4444
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9572>
In compat GL, the gl_FrontColor/BackColor gets clamped unless you
explicitly turn it off with ARB_color_buffer_float, and most apps doing
floating point color rendering are going to be using non-compat varyings
anyway instead of hoping that ARB_color_buffer_float exists. Thus, guess
that the app will get clamping on the color outputs to reduce draw-time
recompiles.
Saves 60 VS recompiles on half-life-2.trace on freedreno (and similarly for
many other compat GL apps).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9509>
This ARB_debug_output is particularly useful in that default apitrace will
log it, so we can find when we're doing draw-time recompiles we shouldn't be.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9509>
Fixes the following issues I can see:
- Non-VS NIR shaders not gathering info after ucp lowering
- Non-VS NIR shaders not doing GL_CLAMP lowering
- Non-VS TGSI shaders not setting up stream output state.
- Non-VS TGSI shaders leaking lower_depth_clamp lowering across variant
compiles.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9509>
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>
On Gen11+ we tend to only use a single configuration, so just get rid
of the stalls in the command buffers by moving the config to device
initialization.
v2: drop NULL config check
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9534>
We're about to reuse this at device initialization.
v2: Handle NULL configs on Gen12+
v3: Handle NULL config in emission helper (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9534>
v2: Deal with line wrapping (Jordan)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9052>
All this code exists in gen_device_info. It will print out the same
warning.
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>
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>
We carry those warnings in i965/anv. Let's have them here. Next commit
we remove some code from the drivers.
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>