At the interfaces which query the pitch of the clear color plane in GL
and Vulkan, we've been returning 64B for various reasons. Unify the
rationale under a macro.
The documentation for the macro is picked from anv, which reflects the
most recently synchronized copy of drm_fourcc.h. See the notable changes
at 8cd8f3d697.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
Our implementation is a no-op for the following reasons :
- ISL always tries to go for the smallest tiling mode (see
isl_surf_choose_tiling())
- In the few cases where we need to use Tile64 for compression
workarounds, VK_MESA_image_alignment_control doesn't require use
to disable compression
- vkd3d-proton has the ability to disable compression using
VK_EXT_image_compression_control, disabling Tile64 requirements
and ensuring ISL can select a 4k tiling mode
So vkd3d-proton should always be able to get a 4k tiling mode if it
wants to.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29175>
Same as the nvc0 patch pretty much, similar improvement.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
---
v2: remove tmp_info as per Karol Herbst suggestion
v3: nv50_draw_vbo -> nv50_draw_single_vbo per Karol's suggestion
v4: mutex assertion and remove num_draws
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641>
This patch is to avoid the high overhead that exists when trying to
kick ever single draw during multidraw.
glMultiDrawArrays performance profiling:
342.5 thousand draws/second -> 40 million draws/second
Special thanks to Arthur Huillet for helping getting this profiled
in irc.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
---
v2: fix typos pointed out by Arthur
v3: nvc0_draw_vbo -> nvc0_draw_single_vbo, intialize count
v4: remove num_draws from wrapped function and add mutex assert
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641>
Having this in one place is better.
When I wrote the old I wasn't aware that checking the kill flag on definitions
is the same as checking zero uses.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29512>
On newer hardware, the hi operation reads the lo half of the inline constant.
On older hardware, it reads the hi half (zero).
I tested this on Navi31 for gfx11 and Raphael for gfx10.
Foz-DB Navi31:
Totals from 4 (0.01% of 79395) affected shaders:
CodeSize: 36832 -> 36448 (-1.04%)
Latency: 20362 -> 20334 (-0.14%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29512>
Indeed, the access to the array is done with a 4x multiplier.
The size of the array should be calculated accordingly.
For instance, this issue is triggered on radeonsi with
"piglit/bin/arb_direct_state_access-gettextureimage-formats -auto -fbo":
==3419==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc31f804b0 at pc 0x7fac7ef81b2d bp 0x7ffc31f803d0 sp 0x7ffc31f803c8
WRITE of size 1 at 0x7ffc31f804b0 thread T0
#0 0x7fac7ef81b2c in do_span_rgba_unorm8 ../src/mesa/main/mipmap.c:160
#1 0x7fac7ef83549 in do_row ../src/mesa/main/mipmap.c:258
#2 0x7fac7ef83986 in make_2d_mipmap ../src/mesa/main/mipmap.c:371
#3 0x7fac7ef8670b in generate_mipmap_compressed ../src/mesa/main/mipmap.c:1062
#4 0x7fac7ef8670b in _mesa_generate_mipmap ../src/mesa/main/mipmap.c:1119
#5 0x7fac7e5472aa in check_gen_mipmap ../src/mesa/main/teximage.c:2910
#6 0x7fac7e5472aa in check_gen_mipmap ../src/mesa/main/teximage.c:2904
#7 0x7fac7e5472aa in teximage ../src/mesa/main/teximage.c:3315
#8 0x7fac7e5472aa in teximage_err ../src/mesa/main/teximage.c:3342
#9 0x7fac7e550cfa in _mesa_TexImage2D ../src/mesa/main/teximage.c:3413
Address 0x7ffc31f804b0 is located in stack of thread T0 at offset 96 in frame
#0 0x7fac7ef814ff in do_span_rgba_unorm8 ../src/mesa/main/mipmap.c:132
This frame has 3 object(s):
[32, 96) 'result' (line 145) <== Memory access at offset 96 overflows this variable
[128, 384) 'rowA' (line 144)
[448, 704) 'rowB' (line 144)
Fixes: dd8fb7139d ("mesa/main: rewrite mipmap generation code")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29572>
Usually this is lowered in NIR, but GFX12 needs to use an intrinsic.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29466>
It was set to "always run" for amd common files changes when I obviously
meant for it to be manual and messed up my copy/paste when I wrote that.
Fixes: ebaede788e ("amd/ci: limit radv jobs to radv + aco files changes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29550>
