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>
The H.264 baseline profile does not support interlaced content. Return
VK_ERROR_VIDEO_PICTURE_LAYOUT_NOT_SUPPORTED_KHR when a non-progressive
picture layout is requested with a baseline profile.
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40942>
