It's probably not needed and we also have draw merging on gfx10,
so we should be able to use total_driver_count in theory.
(I may be wrong, but I don't know if having avg_direct_count really
improves anything)
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8548>
si_set_clip_state unreferenced a NULL pointer = no-op.
si_set_tess_state can just pass the user buffer to si_set_rw_buffer directly.
Then si_upload_const_buffer can be static.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8548>
Some opengl features require shader recompilation to be implemented in
the mali400 and can only be detected at draw time. In some applications,
this could lead to recompiling shaders on every frame which could kill
performance. Introduce a shader cache to prevent this issue.
lima didn't have vertex shader recompilation yet but it is needed to
implement followup features, so include it here too.
Code heavily borrowed from the vc4 shader cache implementation.
One notable difference between the vc4 reference implementation and lima
is that lima still compiles the base shader at state creation time
without deferring it to the next draw (so that it stays compatible with
behaviour expected by unmodified shader-db, for example).
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Andreas Baierl <ichgeh@imkreisrum.de>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8357>
Removes repetitive code in exit on error paths in the derive image function.
Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8481>
Fixes some assertion failures in the GM107 emitter with the game
'tansei', noticed while debugging gitlab issue 4101.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8534>
there's a lot going on here, but the gist of it is:
* if we're not in a renderpass, use the no_rp clear helpers
* if we're in a renderpass, use our lord and savior u_blitter with a temporary
surface that we create just for the blit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8512>
we currently only handle clears inside renderpasses, but it's also possible
to perform clears outside of renderpasses, so we can break this logic up a bit
to open the door to handling the non-rp case
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8512>
we're going to have a bunch of clear code, so having it all in a concise
place that's consistent with other gallium drivers is helpful
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8512>
It is using the source level instead of the destiny level (base_level)
to compute the dest offset.
This fixes `framebuffer-blit-levels draw rgba -auto -fbo` piglit test.
Fixes: 976ea90bdc ("v3d: Add support for using the TFU to do some blits.")
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8491>
This is meant to decrease CPU overhead and reduce the use of cso_context when
better solutions are possible.
These functions are removed. Gallium frontends should just use pipe_context:
- cso_set_sampler_views
- cso_set_shader_images
- cso_set_constant_buffer*
Additionally, vertex buffers are passed through cso_context but they are not
saved there. The only remaining role of cso_context with regard to vertex
buffers is to decide whether to go through u_vbuf or skip it. u_vbuf also
can't save and restore vertex buffers anymore.
This is how the states are restored for meta ops:
- in st/mesa, set st->dirty |= flags to re-bind whatever state has been
touched
- outside of st/mesa, there is new interface st_context_iface::invalidate_-
_state that external modules can use to essentially set st->dirty through
it (like HUD)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8180>
These cso_context capabilities will be removed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8180>
These cso_context capabilities will be removed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8180>
Some cso_context save/restore capabilities will be removed to decrease
CPU overhead. This is the alternative solution that e.g. the HUD will use.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8180>
It will be removed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8180>
Since our source language only allows scalar offset/bits arguments,
virglrenderer only handled scalar values too. Just refuse to vectorize
these to prevent breakage.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8488>
a framebuffer is based on the surfaces attached to it
a renderpass is based on the operations being performed
a zink_framebuffer object doesn't necessarily need to be changed
if the renderpass changes, as this might just indicate that a clear operation
is being used instead of a load, so we can cache the corresponding vk objects
into the zink_framebuffer based on the renderpass ops being used to (eventually)
reduce fb object thrashing by doing more incremental updates
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8227>
