As things are now, the pan_image_slice_layout::{offset,size}_B calculation
can exceed UINT32_MAX, and we silently droppin the upper 32-bit on the
floor. Same goes for the crc offset. Let's use a uint64_t to make sure
that doesn't happen.
While at it, move the two 64-bit field next to each other to avoid
padding, and document what size_B encodes.
It's hard to find the commit that introduced the problem with all the
code motion that happened this this struct was introduced, so I'll
just flag for backport.
Backport-to: 25.1
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
Commit f64a7c1506 ("pan/layout: Check the wsi_layout consistency in
wsi_row_pitch_to_row_stride()") introduced stricter alignments on pre-v7
for linear/tiled imports. It turns out alignment constraints on pre-v7 are
weaker than they are on v7+, and this got lost in the refactoring.
Let's fix linear_or_tiled_row_align_req() helper so we can import images
that don't have their base address/row_pitch aligned on a cacheline, and
only cacheline alignment for images we create ourselves.
Also add unittests to make sure we don't regress that in the future.
With this being tested, we can also use
pan_linear_or_tiled_row_align_req() in offset_align_for_mod()
(test-layout.cpp) instead of open-coding it.
Fixes: f64a7c1506 ("pan/layout: Check the wsi_layout consistency in wsi_row_pitch_to_row_stride()")
Fixes: 916f75a2a6 ("pan/layout: Test WSI import behavior on all supported format/mods")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
Maximum texture dimension is 2^16, but we're limited by the 32-bit
fields that are used to pass strides/sizes in various descriptors.
Assuming RGBA32_FLOAT is the biggest format we support, that gives us a
16k-1 image size for 2D and cube map, and 512 for 3D.
Change our GetPhysicalDeviceImageFormatProperties2() implementation so
that smaller formats can still advertise bigger image sizes.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
We will soon make pan_image_layout_init() return false even for
non-explicit layout case, which will allow panfrost_can_create_resource()
to properly report when the resource size doesn't fix some HW limits.
But before we can do that, we need to let panfrost_resource_setup()
return an error instead of asserting() that pan_image_layout_init()
always return true. Add a new panfrost_resource_try_setup() helper
and define panfrost_resource_setup() as wrapper around it with the
existing assert(valid), and make panfrost_can_create_resource() use the
new helper.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35555>
If we store the temporary value in a [u]int32_t, the result might be
silently truncated, making the overflow check in the u_pack helpers
useless.
Make sure we use 64-bit fields as soon as the size is greater than 31
bits to prevent that.
It forces us to fix some types in the xml and helper arguments (sint
wrongly defined as uint) and add explicit casts on u32 subtraction
whose result is stored in an s32.
Signed-off-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/35555>
The Vulkan spec is pretty clear and says:
"VUID-VkSamplerCreateInfo-None-04012
The maximum number of samplers with custom border colors which can be
simultaneously created on a device is implementation-dependent and
specified by the maxCustomBorderColorSamplers member of the
VkPhysicalDeviceCustomBorderColorPropertiesEXT structure"
So this check can be removed because it would be an application bug
otherwise.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35708>
In panvk we often need to allocate and free address ranges in the
address space represented by panvk_device::as::heap. In most
situations, panvk_device::as::lock has to be held while performing
an operation on panvk_device::as::heap, so there are a lot of
instances of exactly the same 3 locs locking the as::lock,
allocating or freeing a range in as::heap, and unlocking the lock.
These helpers are the less verbose replacements for these 3 locs
that should be used going forward.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35692>
Extend the panfrost resource screen interface with a function that lets
the pipe resource the BO belongs to share a label pointer for debugging
purposes.
Then append this resource label to the existing driver tag and label the
backing kernel BO accordingly.
A panfrost_resource::user_label field was added to store the argument
user label. Because in the case of an AFBC-packed resource, user tagging
can happen before the packed BO is created, we need to store it
separately, so that all the necessary label fields are available before
a complete label can be given to the kernel driver.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34224>
Boris Brezillon