When sparse binding functions submit batches, they may modify the
exec_obj_index field of anv_bo structs. This field is used to ensure a
unique list of buffers is sent to the kernel (i915). Add a lock in these
functions to prevent multiple threads from modifying this field during
the batch submission process. To avoid creating a deadlock, also rework
the locking done in anv_queue_submit().
When playing the Monster Hunter Wilds Benchmark on a mesa build which
enables slab allocation of batch buffers (6f7a32ec92), this avoids a
sporadic assert failure:
nsterHunterWilds.exe:
../../src/intel/vulkan/i915/anv_batch_chain.c:489:
setup_execbuf_for_cmd_buffers:
Assertion `execbuf->bos[idx] == first_batch_bo_real' failed.
This issue was seemingly first introduced in 04bfe828db
("anv/sparse: allow sparse resouces to use TR-TT as its backend")
Backport-to: 25.2
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12582
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37307>
The Vulkan spec requires that access to the queue parameter be
externally synchronized for vkQueueSubmit(). So, each submit call to a
specific queue will have a unique ID.
Backport-to: 25.2
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37307>
Indicates various properties about calls: Whether a program is an
indirect callee, whether a program or block contains function calls, and
whether registers used by a caller need to be preserved.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34531>
Since b3133e250e ("gallium: add pipe_context::resource_release to
eliminate buffer refcounting") we need to take a reference for every bound
buffer object.
As we create image views on buffers, and kinda take partly reference
already just do it properly for now so we don't end up with
use-after-frees in drivers.
Fixes: dee9600a ("zink: eliminate buffer refcounting to improve performance")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37350>
The value read was incorrect.
This change was tested on palm, barts and cayman, it fixes all the variants
of the advanced-sso-simple test:
khr-gl4[56]/es_31_compatibility/shader_image_load_store/advanced-sso-simple: fail pass
khr-gles31/core/shader_image_load_store/advanced-sso-simple: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37225>
This allows us to avoid accidental feature regressions, by verifying
that the reality matches the expectations in CI.
This is inspired by a similar change in r300.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37363>
The current -fmacro-prefix-map only handles removal of relative paths
but we still need to handle absolute paths.
The following path can be found in libvulkan_panfrost.so when building
with Yocto for example:
/work/build/tmp/work/cortexa76-cortexa55-crypto-poky-linux/mesa/25.2.0/sources/mesa-25.2.0/src/panfrost/libpan/../../util/bitpack_helpers.h
These paths currently seem to only appear in the binary in strings that
start with "Shader assertion fail at " which seems to indicate there are
calls to assert() with absolute paths as well as relative paths (which
are already patched with fmacro-prefix-map).
By stripping the project source and build root directories from the
paths with -fmacro-prefix-map, we get rid of this reproducibility issue
(which incidentally makes the build fail due to buildpaths QA issue).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36927>
From !37273 in commit db3501ec4f, the transition Fail to Crash on two tests
produced a duplication in the fails file. The pre-merge didn't catch it, but
in the nightlies and in the ci-uprev attempts to uprev Piglit the jobs report
the duplication error.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37364>
It allows us to use AFBC even if separateDepthStencilLayouts=true.
Unfortunately, AFBC(S8) is only supported on v9+, so we keep using
interleaved Z24S8 on earlier gens.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
panvk_image_can_use_afbc() doesn't know about depth/stencil format
lowering, and does the AFBC format check on the wrong format if planar
depth/stencil is enabled. Inline what we need from this helper in
panvk_image_can_use_mod(). Ultimately we should make it so that
panvk_image_can_use_afbc() uses panvk_image_can_use_mod() and not the
other way around.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We're going to support Z24S8 planar images, but only on v9+. Let's
pass an image to panvk_plane_index() so we can extract the stencil
plane index from the number of planes instead of basing it only on the
format.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We are about to use it at initialization time, so let's make sure it's
initialized as early as possible. We defer the initialization to a helper
because we will extend it to support planar Z24S8.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Only works on Valhall for now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Mali GPUs support Z24_UNORM stored on three bytes instead of four. Add
a new format for this case.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Use AFBC when we can.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We can't have separate depth/stencil layouts with Z24S8, so make sure
we always use a linear layout in that case.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Non-UNORM/non-RGBA8 formats forces blend shaders to be used when the
graphics pipeline is involved. We also have a few formats that can't
be used with AFBC, so let's consolidate the formats we pick when using
a graphics pipeline independently of the image modifier.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
All the meta stuff is per-gen anyway, and there's nothing in
pan_device.h needing the stuff defined in panvk_meta.h, so let's
just make this file per-gen, which will allow us to use PAN_ARCH in
the inline helpers.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We can't create texture descriptors with a format that's different
from the image format, because the texture format encodes the
compression mode on Bifrost. So let's forbid AFBC when
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT is set.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Thanks to the decorrelation of compression mode and texture format,
AFBC is type-agnostic on v9+. We can thus safely allow UINT, SINT and
SNORM variants. The FLOAT variants are still not supported though.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
AFBC(RAW24) is not supported on v9+. Use RAW32 instead, and let the AFBC
compression mode select the actual size.
No Fixes tag here, because AFBC(RAW24) is not a thing until we allow
non-UNORM formats with AFBC.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We are about to allow any type that is not FLOAT on v9+ at the
pan_afbc_format() level, but this regresses
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_16_bits.*_snorm*
tests because of the clamping that's done on values that fall outside
the [-2^(b-1)+1, 2^(b-1)-1] range (b being the number of bits in the
SNORM component).
In order to fix that, we would have to use a _UNORM type when copying,
but:
1. There are many places where internal copies can happen and it's hard
to identify all of them
2. If we do it at the panfrost_blit_no_afbc_legalization() level, we
might do format re-interpretation that's not wanted by the gallium
layer
Given AFBC(SNORM) has not been supported so far, let's just go for the
simple solution and filter it out explicitly in panfrost_should_afbc().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
One we have selected a pan_afbc_mode (AKA AFBC format) for an image,
there's no reason for it change, so let's cache that at the
pan_image_layout level and re-use it when we can instead of doing
the pipe format -> afbc mode conversion over and over again.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We are about to need new type converters for our AFBC mode selection
logic (AFBC is type agnostic, but we currently accept only UNORM
formats), so let's switch to an autogen solution for the existing ones,
and generate all missing type converters along the way.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Pass a pan_image_usage object to pan_image_test_props() and do the mod
selection in two passes: one where we only accept optimal modifiers,
and if none was found, a second pass to pick a non-optimal one.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
AFBC(Z32) has always been supported through AFBC(RGBA8), the entry was
just missing. AFBC(S8) on the other hand, is something that has been
added to v9.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We are about to extend pan_afbc_format() to support AFBC(Z32),
but the the AFBC(Z32) + S8 combination doesn't work on v7-, so
we need to filter AFBC(Z32) out in panfrost_should_afbc() on
v7-.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Mapping Z32_FLOAT to R32F works fine until we start using AFBC(Z32),
which triggers DATA_INVALID faults. That's not an issue on v9+
because the compression mode and texture format are decorrelated,
but we need this change if we want to support AFBC(Z32) on v7.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Testing if a modifier is supported for a set of image properties is not
enough when we're supposed to pick the best modifier among a selection
of modifiers. Extend the image/mod logic to report if a modifier is
optimal when supported.
This forces us to pass extra usage information through a new
pan_image_usage object. When this usage info is missing (NULL), the
mod layer assumes a set of usage that would make the modifier optimal.
Note that the usage info also allows us to reject a few more cases
that would otherwise need to be checked by the frontend.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
