It's only used in assert. Avoids compiler warning/error with assertions disabled:
../src/freedreno/vulkan/tu_cs.h: In function 'tu_cs_reserve':
../src/freedreno/vulkan/tu_cs.h:208:13: error: unused variable 'result' [-Werror=unused-variable]
208 | VkResult result = tu_cs_reserve_space(cs, reserved_size);
| ^~~~~~
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11412>
If we build a dlist starting with a NOP (for alignment purpose),
we don't have to execute the NOP.
Instead shift the start value by one.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11493>
This reduces cache-misses in execute_list for apps using lots of small
dlist, like viewperf.
This is only done for small dlist (fitting in one block) because doing
this for larger ones wouldn't bring any benefit.
For instance, in vp13/snx test 10: the % of cache-misses events in
_mesa_glthread_execute_list/execute_list goes down from 17%/10% to 4%/3%.
If "struct gl_display_list" were stored in an array this would also
remove source of cache-misses since currently they're malloc-ed
individually.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11493>
Also add a 'bool copy_to_current' param to vbo_save_playback_vertex_list:
this way we can decide if we need to call playback_copy_to_current without
loading any cold data.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11493>
OpenGL 4.6 compatibility profile spec, Appendix B:
21. For any GL and framebuffer state, and for any group of GL commands and
arguments, the resulting GL and framebuffer state is identical whether the
GL commands and arguments are executed normally or from a display list.
The only exception to this corollary is for built-in shader variables
gl_VertexID and gl_PrimitiveID, which are not defined when drawing
geometry within a display list.
(thanks Ian Romanick for pointing this out in piglit !419 MR)
Remove the code introduced in ebb228bec5 to determine if merged draws can be used.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11493>
When EGL_KHR_mutable_render_buffer extension is enabled, advertised
configs unconditionally include EGL_MUTABLE_RENDER_BUFFER_BIT_KHR bit.
However, f61337b5 starts requesting front rendering usage bit when
EGL_MUTABLE_RENDER_BUFFER_BIT_KHR is seen on the SurfaceType, which
essentially forces linear usage on all winsys BOs for gallium dri and
i965 drivers on Android when cros gralloc is in use.
This patch dynamically appends or strips the front rendering usage bit
depends on whether EGL_RENDER_BUFFER is EGL_SINGLE_BUFFER or
EGL_BACK_BUFFER. The next dequeuBuffer call will switch the buffer
sharing mode while re-allocating winsys BOs given the updated gralloc
usage bits if necessary.
v2: handle ANativeWindow_setUsage on error
Fixes: f61337b5 ("egl/android: check front rendering support for cros gralloc")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Rob Clark <robdclark@chromium.org> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11787>
Android.mk files haven't really been supported by Mesa devs for a long
time. Most of us have been willing to update Makefile.sources if we
remember and sometimes we try to blind code some Android.mk for a new
generator. However, the reality is that it breaks regularly and ends up
being maintained by the Android community. To address this problem
another approach was implemented in !10183 utilizing the maintained
meson build system. The old Android.mk files are no longer required.
This commit was created with the following commands:
git rm **/Android.mk
git rm **/Android.*.mk
git rm **/Makefile.sources
git rm CleanSpec.mk
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4487
Acked-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9728>
I think there is no reason to keep this disabled because it improves
viewperf and it might improve other things.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11754>
We should always prevent 1 CU from executing VS and GS waves
to prevent a deadlock.
Fixes: c377f45c18 "radeonsi/gfx10: rewrite late alloc computation"
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11754>
Always execute the bbox code regardless of negative W, and then simply
use || to discard the result if any W is negative. This is expected to be
rare. (it only happens when a primitive intersects the near plane)
This allows us to eliminate the else statement, which is no longer
executed for accepted primitives with negative W, which are the only
primitives that needed the else branch.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11754>
We say that they're for debug only but we don't really have a good
policy around when to set them and when not to. In particular,
nir_lower_system_values and nir_lower_vars_to_ssa which are the chief
producers of SSA values which might reasonably have a name do not bother
to set one. We have some names set from things like BLORP and RADV's
meta shaders but AFAICT, they're setting a name more because it's there
than because they actually care.
Also, most things other than nir_clone and nir_serialize don't bother to
try and preserve them. You can see in the diffstat of this commit
exactly what passes attempt to preserve names. Notably missing from the
list is opt_algebraic which is the single largest source of SSA def
churn and it happily throws names away.
These observations lead me to question whether or not names are actually
useful at all or if they're just taking up space (8B per instruction)
and wasting CPU cycles (to ralloc_strdup on the off chance we do have
one). I don't think I can think of a single time in recent history
where I've been debugging a shader issue and a SSA value name has been
there and been useful. If anything, the few times they are there, they
just throw me off because they mess up the indentation in nir_print.
iris shader-db on my system gets runtime -2.07734% +/- 1.26933% (n=5)
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5439>
The intention is to pick the system memory for the prime blit dst, but
that is not possible when all memory types are advertised to be local.
This fixes venus over vtest (i.e., unix socket) because the driver
provides no PCI bus info and wsi_device_matches_drm_fd returns false. A
driver might also use can_present_on_device to force prime blit.
Fixes: 469875596a ("vulkan/wsi: Fix prime blits to use system memory for the destination")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11774>
This prevents the previous commit from being undone by the jump
optimizations in legalize, and fixes another potential case where
instead of a continue we have an if/else at the end of a loop.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6752>
When loops have continue statements, it's expected that when we execute
a divergent continue (i.e. a continue where not all of the threads
active at the start take it) we keep going with the rest of the loop
body and then reconverge at the start of the next iteration. However the
Adreno ISA seems to always take a branch that jumps backwards, assuming
it's the bottom of a loop, so we get a different, undesired convergence
behavior. There's no way I know of to control this behavior in the
instruction set, so we have to instead insert a "continue block" at the
end of the loop where continue statements reconverge which then jumps
back to the top of the loop. Since this doesn't correspond 1:1 with any
NIR block we have to make control flow handling in NIR->ir3 a bit more
complicated, unfortunately.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6752>
Michel Dänzer
Pierre-Eric Pelloux-Prayer
Marek Olšák
Connor Abbott
Andrii Simiklit
Samuel Pitoiset
Yiwei Zhang
Chia-I Wu
Alyssa Rosenzweig
Jason Ekstrand