LLVMpipe is the only driver that actually has supported the instructions
that this cap reports about. But TGSI is a dying IR, and this helps very
little; the compiler back-end will optimize this away anways.
So let's drop it to reduce complexity.
Acked-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
These instructions were never supported on Iris, as it never supported
TGSI. This didn't lead to any issues because tgsi_to_nir normalized the
result. This mistake got carried forward when creating crocus as well.
Let's just stop reporting it; it doesn't do anything useful.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
This hasn't been supported since the TGSI envvar was ripped out. When
converted to NIR, we don't see these instructions at all.
Fixes: c3cbe610df ("nouveau: Delete the NV50_PROG_USE_TGSI env var.")
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40993>
Remove the TU_DEBUG_FLUSHALL option that was force-enabled for a8xx chips.
The problematic CTS cases that required it were failing due to indirect
draw commands sourcing draw data from buffers whose content was prepared
by compute tasks.
Up until a8xx, firmware was managing an implicit wait before any indirect
draw parameters were read, with a delayed CP_WAIT_FOR_ME emitted only when
necessary or on devices enabling indirect_draw_wfm_quirk due to bugged
firmware. That implicit wait is gone on a8xx, so CP_WAIT_FOR_ME should be
emitted immediately, which also matches behavior of the proprietary driver.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40550>
The HW supports larger buffer-sizes on v11 and later, so let's bump
this up.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
The HW supports larger resource-sizes on v11 and later, so let's bump
this up. But since we have a knob to limit the usable VA space, we need
to take that into account here as well.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
While we used to need this, we no longer do, thanks to handling
maxResourceSize. From the Vulkan spec:
> If the size of the resultant image would exceed maxResourceSize,
> then vkCreateImage must fail and return VK_ERROR_OUT_OF_DEVICE_MEMORY.
> This failure may occur even when all image creation parameters satisfy
> their valid usage requirements.
Handling of this was added in 86068ad1ee ("panvk: implement sparse
resources"), so we no longer need to make sure of this when reporting
the limits.
The hardware-fields for these are 16 bits, so let's allow the full range
for all of these.
This is effectively a revert of e25a91d919 ("panvk: Lower
maxImageDimension{2D,3D,Cube} to match the HW caps").
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
In order to be able to properly check for maxResourceSize on Vulkan, we
need to be able to report the size even for resources that overflow that
limit. Otherwise we end up failing to find a usable modifier rather than
properly report the problem to the application. This means we need to move
the check out of the mod-handler.
There's no need to validate the slice-stride. The reason is a little bit
complicated, but we have two possible cases:
1. V10 and before: the image-size and the slice-stride are both limited
to UINT32_MAX. Since the image-size is always at least as large as the
slice-stride, it's enough to check the image-stride.
2. V11 and later: 37 bits is large enough to store any valid
slice-stride. The only way we could blow this one up, would be to
pass out-of-range width or height, which is already either validated
by higher-level logic (gallium) or UB (vulkan). This is important,
because we don't have another mandate to reject large resources on
Vulkan; we can only reject due to maxResourceSize, not an individual
plane.
So let's move this out to the call-site. We don't need to do anything
for PanVK, becuase it already checks for maxResourceSize.
To keep the Gallium and Vulkan driver as similar as reasonably possible,
check against the whole resource even in Gallium, where we could have
gotten away with checking a plane at the time instead.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
We can't expose large texel-buffers if we don't emit the high bits.
Whoopsie!
Fixes: 4db7958edc ("pan/bi: Change texel buffer limits")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
A few cases of UINT32_MAX were missed, whoops.
Fixes: c2c91e78fd ("pan/layout: Allow bigger size/surface stride on v12+")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40999>
This is a follow-up to:
- commit e27e41a8 ("vulkan,spirv: update headers")
- commit c4cecd9d ("gfxstream: cereal: fix 'None' in gfxstream codegen")
The second commit fixed compile, but still produced a
crash on the host side:
$0 __memcpy_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:833
$1 0x00007f116f8ee285 in memcpy (__dest=0x7f0d258cd340, __dest@entry=0x7f0ed55e9458, __src=0x7f0e78072ff7, __src@entry=0x72795f61, __len=1920556897)
at prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8/sysroot/usr/include/x86_64-linux-gnu/bits/string3.h:51
$2 gfxstream::host::vk::VulkanStream::loadStringInPlaceWithStreamPtr (this=this@entry=0x7f0e78022b50, forOutput=forOutput@entry=0x7f0d97fff018,
streamPtr=streamPtr@entry=0x7f0ed55e9458) at hardware/google/gfxstream/host/vulkan/vulkan_stream.cpp:100
$3 0x00007f116f8ee3de in gfxstream::host::vk::VulkanStream::loadStringArrayInPlaceWithStreamPtr (this=0x7f0e78022b50, forOutput=<optimized out>,
streamPtr=0x7f0ed55e9458) at hardware/google/gfxstream/host/vulkan/vulkan_stream.cpp:122
$4 0x00007f116f9f2fcb in gfxstream::host::vk::reservedunmarshal_VkDeviceCreateInfo (vkStream=vkStream@entry=0x7f0e78022b50,
Fix up lenAccess string marshaling to prevent this.
TEST=launch_cvd --gpu_mode=gfxstream_guest_angle_host_swiftshader
Reviewed-by: David Gilhooley <djgilhooley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41059>
This change was tested on plam and cayman. Here are the tests fixed:
spec/arb_gl_spirv/execution/uniform/atomic-uint-aoa-cs: fail pass
spec/arb_gl_spirv/execution/uniform/atomic-uint-aoa-fs: fail pass
spec/arb_gl_spirv/execution/uniform/atomic-uint-array-cs: fail pass
spec/arb_gl_spirv/execution/uniform/atomic-uint-array-fs: fail pass
spec/arb_gl_spirv/execution/uniform/atomic-uint-cs: fail pass
spec/arb_gl_spirv/execution/uniform/atomic-uint-fs: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40822>
This change adds a minimal support for gl_PointSize to
be used alongside gl_ClipDistance/gl_CullDistance.
This change was tested on palm and cayman. Here is the test fixed:
khr-gl4[5-6]/gl_spirv/spirv_validation_builtin_variable_decorations_test: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40701>
This functionality was not working.
To fix this issue, the texture mode needs to be set to
V_030000_SQ_TEX_DIM_2D_MSAA. When this mode is processed
the gpu only takes the layer 0. This change implements
this functionality by copying the layer to a new resource.
This change was tested on palm, barts and cayman. Here is the
test fixed:
khr-gl4[2-6]/texture_view/view_sampling: fail pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40567>
This change extends r600_lds_constant_buffer to
implement a fully conformant gl_PrimitiveID at
the tes and tcs stages.
This change was tested on cayman and barts. Here are the tests fixed:
spec/arb_tessellation_shader/execution/tcs-primitiveid-instanced: fail pass
spec/arb_tessellation_shader/execution/tes-no-tcs-primitiveid-instanced: fail pass
spec/arb_tessellation_shader/execution/tes-primitiveid-instanced: fail pass
khr-gl4[4-6]/tessellation_shader/tessellation_shader_tessellation/gl_invocationid_patchverticesin_primitiveid: fail pass
khr-gles31/core/tessellation_shader/tessellation_shader_tessellation/gl_invocationid_patchverticesin_primitiveid: fail pass
khr-glesext/tessellation_shader/tessellation_shader_tessellation/gl_invocationid_patchverticesin_primitiveid: fail pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40297>
The atomic offset implementation was incomplete.
This change was tested on cayman, it fixes all the
variants of this test:
khr-gl4[2-6]/shader_atomic_counters/advanced-usage-multi-stage: fail pass
khr-gles31/core/shader_atomic_counters/advanced-usage-multi-stage: fail pass
Fixes: 06993e4ee3 ("r600: add support for hw atomic counters. (v3)")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40170>
Here is the new line:
GL_EXT_texture_shadow_lod DONE (asahi, crocus/gen6+, iris, llvmpipe, nvc0, radeonsi, r600/evergreen+, virgl)
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39915>
The support needed only a minor adjustment.
Note: As far as rv770 is concerned: khr-gl33 (4/12),
the support needs some work and is disabled.
This change was tested on palm, barts and cayman: piglit (3/3)
khr-gl46 (15/16). The failing test: sampler2darrayshadow_vertex
is referenced as "Bug 21620051" (VK-GL-CTS) and seems to have
a problem.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39915>
This change is inspired by b56f47611a ("radeonsi: fix
alpha-to-coverage + alpha-to-one used together for
gfx6-10.3") and implements the same algorithm.
This change was tested on rv770, palm and cayman. Here are the tests fixed:
spec/arb_framebuffer_object/execution/msaa-alpha-to-coverage_alpha-to-one: fail pass
spec/arb_framebuffer_object/execution/msaa-alpha-to-coverage_alpha-to-one_write-z: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39779>
Reading the buffer size (GET_BUFFER_RESINFO) does not work
on cypress. This issue is the main difference on a test
basis between cypress and other gpus like palm and cayman.
This change adds a dedicated function which extends the
previous workaround algorithm for cubearray to this end.
This change assumes that all the gpus between cedar and
hemlock have the same issue.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39650>
The extension permits a SPIR-V OpTypeRuntimeArray as the trailing
member of a UBO block.
panvk's compiler path handles this correctly without changes: UBO
access goes through nir_lower_explicit_io with address formats that
carry no compile-time size (bounds are enforced by the hardware UBO
descriptor at runtime), so a runtime array inside a UBO is
indistinguishable from any other dynamically-indexed UBO access.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40963>
Previously the output length of pvr_get_driver_build_sha() is changed to
BUILD_ID_EXPECTED_HASH_LENGTH, but the array defined to receive its
output, the driver_build_sha array inside struct pvr_instance, is
declared with BLAKE3_KEY_LEN, which is longer than
BUILD_ID_EXPECTED_HASH_LENGTH.
This leads to uninitialized memory being accessed when creating
pipelineCacheUUID value, and the pipelineCacheUUID value would become
random in each run, defecting the purpose of it.
Refactor the code copying the build ID to follow other drivers: changing
the parameter from the buffer to the instance pointer, inserting a
static assert thanks to being able to retrieve the destination buffer
length (as an array inside the instance structure) and using
copy_build_id_to_sha1() to do the final copy.
Fixes: 6a42493c94 ("pvr: Use BUILD_ID_EXPECTED_HASH_LENGTH")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Ella Stanforth <ella@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40673>
