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>
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>
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>
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>
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>
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>
The AFBC mode describes the mode of the plane-format, which is what is
stored in memory, not the image view format (which is the
interpretation of the *decompressed* memory).
This requires us to move the special S8 cases to a separate
pan_afbc_decompression_mode() helper, since those are
decompression-only mode which we need to view Z24S8 (AKA RGBA8)
as X24S8, or R8 as R8R8. While at it, get rid of PAN_AFBC_MODE_S8,
since it's not a thing in practice.
No Fixes or Cc-stable tag here, because things were working just
fine before that in the gallium driver, and AFBC is still an opt-in
feature in panvk.
Closes: https://gitlab.freedesktop.org/panfrost/mesa/-/issues/205
Reviewed-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 need to add a JM barrier after the memset(0) COMPUTE job if we want
to ensure the header reset happens before any texturing from this texture
in subsequent COMPUTE/VERTEX jobs.
Fixes: c95f899305 ("panvk: add a meta command for transitioning image layout
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>
cmd_clear_afbc_metadata() might be called before any other job, and it's
assuming dispatch_precomp() doesn't fail in that case. We could
explicitly open the batch in cmd_clear_afbc_metadata(), but checking for
cur_batch==NULL and opening a new batch seems to be okay too, and it
allows us to not special case for v7 in cmd_clear_afbc_metadata().
Fixes: c95f899305 ("panvk: add a meta command for transitioning image layout")
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>
There seems to be cases where we end up with a depth/stencil preload,
with no draw associated to it, so let's make sure we preload in that
case, otherwise we will write invalid data back.
Fixes: 0bc3502ca3 ("panvk: Implement a custom FB preload logic")
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>
In panvk_vX_cmd_meta.c, panvk_plane_index() is passed the bit position
instead of an aspect in a couple places.
Fixes: c95f899305 ("panvk: add a meta command for transitioning image layout")
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>
Commit 33eff977f6 ("panvk: Use pan_image_test_props() to do our
modifier check") removed the checks that are already done by
pan_image_test_props() from panvk_image_can_use_afbc(), but it didn't
account for the fact panvk_image_can_use_afbc() is also used to
report suboptimal setup when HOST_TRANSFER is set.
Reported-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 33eff977f6 ("panvk: Use pan_image_test_props() to do our modifier check")
Closes: https://gitlab.freedesktop.org/panfrost/mesa/-/issues/204
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>
It seems like everything involving the multithreaded ES2 tests is prone
to flaking out with a segfault. Just wildcard the lot until we can
bottom out what's actually going on.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37305>
The current code assumes 2M and 4k pages. If an allocation request
is larger than 2M, allocation will be aligned to 2M, otherwise to
4k.
The new code is informed by pgsize_bitmap. The allocation is
aligned to a particular page boundary, if the request is at least
as large as that page boundary. Note that given
pgsize_bitmap = PGSIZE_4K | PGSIZE_2M
2M requests will now be aligned to a 2M boundary, rather than 4k,
which is the case with the current code.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37288>
This function returns the page size of the VM that we're using. The
GPU page size might be different from what the host process uses.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37288>
pgsize_bitmap specifies the page sizes supported by the VM.
Aligning the mappings to huge-r pages can increase access perf.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37288>
When the host process is 32-bit, size_t can not express all of the
device address space. Note that there's still a lot of code that
uses size_t for device sizes remaining. Cleaning that up is left
for future MRs.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37288>
Blending should work properly those days.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37271>
This is wrong for SNORM and this is handled by nir_lower_blend.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37271>
The change to the implicit subpass barriers uncovered a CTS bug that is
now hitting CI. The issue is fixed in vulkan-cts-1.4.2.1, but CI is
currently on vulkan-cts-1.4.1.1.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36985>
On Valhall, we can end up with a lot of convertions for 8-bit and 16-bit
values.
However, since Valhall, we have access to a lot more swizzles on widen
sources.
The idea of this pass is to propagate replicate swizzle usages to
simplify things.
We do not attempt to propagate MKVEC.v2i16 as it is already handled by
bi_lower_swizzle.
This changes the following:
9 = V2S8_TO_V2S16 !7.b0
11 = IADD.v2s16 !9.h00, u4
88 = MKVEC.v2i8 11.b0, u256.b0, u256
13 = IMUL.v4i8 !88.b0, 8.b0
14 = V2S8_TO_V2S16 !13.b0
15 = IADD.v2s16 14.h00, !11.h00
89 = MKVEC.v2i8 !15.b0, u256.b0, u256
17 = IMUL.v4i8 !89.b0, !8.b0
Into this:
11 = IADD.v2s16 !7.b0, u4
13 = IMUL.v4i8 11.b0, 8.b0
15 = IADD.v2s16 13.b0, !11.h00
17 = IMUL.v4i8 !15.b0, !8.b0
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37167>
We are going to do more things here that will likely benefit from
possibly running multiple time.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37167>
It alwways comes in through the create flags now.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36957>
This moves the bit into vk_image.h and handles it automatically in
vk_image_view_init() so drivers don't have to.
This also means that Meta is now hitting the driver_internal path for
all its images so we need to do the same format fixups there that we
sould normally do on the !driver_internal path. We don't want to do
them unconditionally because v3dv and other drivers override
depth/stencil color formats and we don't want to break that.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36957>
When spilling registers on Valhall we are careful to leave the TLS
pointer aligned on 16 byte boundaries (so as to avoid accesses
crossing those boundaries). However, within the spill code we don't
need to have 16 byte alignment for spills of 32 or 64 bit values.
In the common case where most spills are 32 bits, we can save nearly
75% of the memory used by just aligning to 32 bit boundaries.
Reviewed-by: Aksel Hjerpbakk <aksel.hjerpbakk@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36676>
We were testing some conditions in the wrong order, so spilled
registers were being printed as if they were uniforms. This is
incorrect, but only subtly so, and lead to confusion.
Fixes: 6c64ad934f ("panfrost: spill registers in SSA form")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37092>
The intention of the code was to allow PHI values to be propagated
if they were in registers (as opposed to in memory). As written though
values were never propagated. I think this typo was due to some
debug code that wasn't removed properly.
Fixes: 6c64ad934f ("panfrost: spill registers in SSA form")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37092>
On v11+, all small integers instruction variants are gone, however we
can now use widen on src0 just fine.
That mean we can get ride of mid conversion by relying on swizzle
instead while respecting signess of the inner instruction.
This helps a little bit on clpeak with panvk+clvk, shader-db is also
happy:
Totals:
Instrs: 109541 -> 109354 (-0.17%)
CodeSize: 1110528 -> 1108864 (-0.15%)
Estimated normalized CVT cycles: 667.609375 -> 664.5625 (-0.46%)
Totals from 17 (2.12% of 803) affected shaders:
Instrs: 13637 -> 13450 (-1.37%)
CodeSize: 112256 -> 110592 (-1.48%)
Estimated normalized CVT cycles: 100.203125 -> 97.15625 (-3.04%)
Signed-off-by: Mary Guillemard <mary.guillemard@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/37125>
We already do this many places, let's add the missing ones for the core
Vulkan versions.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37136>
Similar to what we do for features here, let's group things a bit more
consistently.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37136>
The feature bits have been added a bit willy-nilly, let's clean that up
a bit.
The general structure here is that if something is part of a specific
Vulkan version, we list the feature under there in the order they are
defined in the version-specific structure. If not, we list it under
an extension. Clean up so each version is in it's own block.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37136>
These two properties reports how the interaction between MSAA coverage
and occlusion queries works. We need to report the correct value here,
otherwise applications might misbehave.
Fixes: 5ee3c10d1e ("panvk: advertise vulkan 1.4 on v10+")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37136>
Seems this just works, so let's enable it.
Unlike maintenance 4 through 8, VK_KHR_maintenance9 doesn't have a hard
dependency on Vulkan 1.1, and can also be supported on Bifrost.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36987>
Techically speaking, this isn't needed. Allocating a new BO should zero
out the memory in the first place.
But let's do this anyway, because that assumption might change at some
point. Besides, this adds fairly little overhead, and happens in a
non-critical code-path.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36987>
