This seems to simply be a mixup of what utility function to use.
util_clear_render_target clears on the CPU, whereas
util_blitter_clear_render_target clears on the GPU. Because we do the
zink_blit_begin dance, it seems reasonable to assume the latter was
intended.
Fixes: 622f8f6ed5 ("zink: add a pipe_context::clear_texture hook")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10211>
This is possible again thanks to
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9955 , and
this MR requires rebuilding all templates based docker images anyway,
so we can pull in the latest templates for free.
We need to exclude /dev/* when unpacking rootfs tarballs for the
arm_test image, since x86 container build jobs do not allow mknod
anymore with current templates. The baremetal test jobs have another
filesystem mounted on /dev anyway.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
Among other things, this gets us GCC 10 (was 6).
Requires some changes to third party components we use:
* Install apitrace (& waffle) from Debian; was hitting issues with the
local build, and it's the same version 9.0 anyway.
* Update Fossilize to a newer commit which builds with GCC 10.
* apt.llvm.org repositories are no longer needed.
* Use an SPIRV-LLVM-Translator commit which builds with LLVM 11.0.1.
* Install XCB packages from Debian, 1.13 fails to build with Python 3.9.
* Install wayland-protocols from Debian, 1.12 is too old for
libgtk-3-dev in bullseye.
LLVM 7/8 packages are no longer available.
Also adapt expected test results to Xvfb now exposing multi-samle
GLXFBConfigs.
v2:
* Install clang instead of clang-11.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3124
Reviewed-by: Eric Anholt <eric@anholt.net> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
Avoids warning with GCC 10:
../src/intel/blorp/blorp_blit.c: In function 'blorp_nir_combine_samples':
../src/intel/blorp/blorp_blit.c:702:25: error: 'texture_data[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
702 | texture_data[0] = nir_fmul(b, texture_data[0],
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
703 | nir_imm_float(b, 1.0 / tex_samples));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
Avoids warning with newer GCC:
../src/gallium/drivers/r600/sb/sb_sched.cpp: In member function 'void r600_sb::literal_tracker::reset()':
../src/gallium/drivers/r600/sb/sb_sched.cpp:1953:26: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct r600_sb::literal'; use assignment or value-initialization instead [-Werror=class-memaccess]
1953 | memset(lt, 0, sizeof(lt));
| ^
In file included from ../src/gallium/drivers/r600/sb/sb_sched.cpp:35:
../src/gallium/drivers/r600/sb/sb_bc.h:409:8: note: 'struct r600_sb::literal' declared here
409 | struct literal {
| ^~~~~~~
[ Michel Dänzer:
* Expanded commit log
v2:
* Clear all 4 members of lt[4] (Eric Anholt)
]
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833>
VK_KHR_spirv_1_4 is trivial because vtn already supports all the added
SPIR-V features that aren't gated behind Vulkan extensions. I've
observed some robustness2 CTS tests requiring this. However there are
a few tests currently failing due to lacking spilling.
VK_EXT_scalar_block_layout should also be trivial, since support for
"straddling" UBO loads was added recently for other reasons. This is
used by every robustness2 CTS test.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8695>
64 was a temporary and conservative "big enough" value, but we can do
better.
Note that as mentioned on the FIXME, we could be even more detailed,
adding a descriptor map allocate method based on the descriptor
type. That would mean more individual allocations, and slightly more
complexity.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
We had some cases were we have defined a value on v3dv_limits but
using other when setting it at GetPhysicalDeviceProperties (like
dynamic storage buffers).
Also we do a cleanup. So far we were adding on v3dv_limits only the
limits that were used on more that one place. But then we had the
definition of several limits on different places. It is clearer to
have a common place for those, even if it is used on just one place.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
There were two problems here:
* We were multiplying by 6, when for graphics pipelines, we only
support 2.
* Right now we are tracking descriptors through the descriptor
maps, and we have one per pipeline. So in practice there is no
difference between per-stage and per-pipeline limits. So far this
was not a problem, we could revisit in the future.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10207>
The Vulkan spec doesn't require the application to always binds
a depth/stencil attachment when a VRS attachment is used inside the
same subpass.
To handle this situation, the driver creates a global 4096x4096
VRS image that will be bind at draw-time if needed. This isn't
super ideal but we have to do that unfortunately.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10187>
Timur Kristóf