The Vulkan runtime and panvk already handle unused attachments
correctly. Enable the extension and feature flags.
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/40920>
Repairing SSA was creating invalid PHI nodes with source swizzles !=
BI_SWIZZLE_H01. PHI sources can't have non-identity swizzles.
In most cases the repair logic only replaces sources, in which case the
swizzle is taken from the old source that is getting replaced. However,
in add_phi_operands there is no old source because the phi is new, and
so the result from resolve_read is assigned directly. This falsely
carries over the destination swizzle to the source.
Since it never makes sense for resolve_read to carry over the swizzle
from the instruction writing the value, we can make it so that
resolve_read always returns the identity swizzle on indices.
resolve_read returns one of:
- An index stored by record_write
- An index created by bi_temp_like
- The result of a recursive resolve_read call
bi_temp_like already correctly sets the swizzle to H01. Setting it in
record_write leads to both base cases returning the desired swizzle.
Fixes: dd94d183 ("pan/bi: Fixup bi_repair_ssa.c for bi")
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40969>
PANVK_DEBUG_HSR_PREPASS and PANVK_DEBUG_NO_EXTENDED_VA_RANGE have the
same value, meaning they both get toggled when one is.
This commit moves PANVK_DEBUG_HSR_PREPASS to the following value.
Fixes: 2d9be41706 ("panvk/v13: Support HSR Prepass")
Reviewed-by: John Anthony <john.anthony@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41106>
The disassembly file had a lot of inconsitencies in indentation, so
align on the standard IndentWidth: 3
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41062>
The current implementation prints FAU entries as 32-bit entries. While
this works, it does not align with the DDK.
Rather than treating FAU as a set of 32-bit entries, treat is as 64-bit
entries that can be split in two words.
This aligns with the DDK and has allows for differentiating 32-bit and
64-bit reads based on whether a word modifier is used.
Finally, add entry values to FAU printing to easily look up specific
reads.
For example:
Vertex FAU @ffd93950:
43000000 43000000
3F800000 43000000
43000000 00000000
C7000000 47000000
00000001 00000000
FMAX.f32 r3, r3^, u6
FMIN.f32 r3, r3^, u7
vs
Vertex FAU @ffd93950:
u0 43000000 43000000
u1 3F800000 43000000
u2 43000000 00000000
u3 C7000000 47000000
u4 00000001 00000000
FMAX.f32 r3, r3^, u3.w0
FMIN.f32 r3, r3^, u3.w1
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41062>
This makes it clear that both registers are read/written, and aligns
with DDK disassembly.
For example:
STORE.i128.istream.slot2.reconverge @r0:r1:r2:r3, r4^, offset:0
vs
STORE.i128.istream.slot2.reconverge @r0:r1:r2:r3, [r4^:r5^], offset:0
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41062>
With SPV_KHR_constant_data, it's allowed to specialize array of
constants.
RustiCL changes are from Karol Herbst <kherbst@redhat.com>.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41046>
The Vulkan spec states that if VK_KHR_shader_clock is supported,
shaderSubgroupClock is a required feature. So let's not enable that
extension unless we can...
Fixes: e9c2c32409 ("panvk: enable VK_KHR_shader_clock")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40944>
The Vulkan spec states that if VK_ARM_shader_core_builtins is supported,
shaderCoreBuiltins is a required feature. So let's not enable that
extension unless we can...
Fixes: dff1d91c64 ("panvk: Enable VK_ARM_shader_core_builtins")
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40944>
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>
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>
Add the missing layout which do not need implemented anything in
mali gpu.
Fixed: dEQP-VK.image.host_image_copy.properties.properties
unifiedImageLayouts feature is supported, but layout
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL was not included in
VkPhysicalDeviceHostImageCopyProperties::pCopySrcLayouts.
Fixes: 1cd61ee ("panvk: implement VK_EXT_host_image_copy for linear color images")
Signed-off-by: Ryan Zhang <ryan.zhang@nxp.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40899>
Map X6R10X6G10X6B10X6A10_UNORM to the native R10X6G10X6B10X6A10X6_UNORM
HW format on PAN_ARCH >= 11 where it is supported.
Enable the extension with formatRgba10x6WithoutYCbCrSampler in the
physical device, allowing VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
to be used as a regular color format without YCbCr sampler conversion.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40653>
Ideally there should be only sysval lowering in the middle.
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40844>
Ints and floats do not need to match between VS and FS, some crazy
shaders might write an uint from the VS and read a noperspective float
from the FS. There will be new tests in the conformance tests that
check that too shortly.
Is this a performance regression? yes.
Can we fix this easily? No, we'll need dynamic prolog/epilog linking.
Since maybe_noperspective is almost useless after this fix, the whole
logic has been removed
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40844>
VS does not need to write the position, it can also leave it as
undefined. We agree that there isn't much sense in noperspective
varyings with undefined perspective, but we still do not want to crash.
This does lead to some real crashes if we mistake some int varying to
noperspective (see next commit).
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40844>
Doing stores first, loads second doesn't work because there can be
chains of store, load, store... .
Use a fixed point approach instead to calculate sizes for all
destinations.
Fixes: 2fd5b8a391 ("pan/bi: Account for MEMMOV in bi_record_sizes")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40915>
These are based on nightlies. It's unclear if one of the t760 flakes
should really be a fail or a flake, but I have another MR that tries to
clean up the flakes pending; I'll address that there, as there's other
related flakes that probably should change as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40943>
Some code in gallium was making assumptions of how the gpu_id is laid
out, which will not work for 64 bit gpu_ids.
Expose pan_prod_id and pan_rev from the model to collect this logic in a
single place.
Reviewed-by: Marc Alcala Prieto <marc.alcalaprieto@arm.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40921>
For Valhall, use SHADDX instruction for 64-bit integer addition instead
of lowering it to 32-bit operations. The instruction sequence for doing
it in 32-bit costs 3 cycles but SHADDX only takes 2 cycles to perform.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40841>
va_mark_last currently expects 64-bit registers to always be split in
two, this commit changes it to check first if a 64-bit register is split
or not.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40841>
Without this, printf messages that were sent before a crash will be
lost, which makes shader printf pretty useless for debugging crashes.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40816>
Some video decoders spit out AFBC(16x16,sparse,split) images. Advertise
support for this modifier so we can import such images.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40746>
The old implementation only worked for 16-bit because we assumed scalar
so we could stomp the whole destination as if it was 32-bit. This
version works for v2i16.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
Now that bi_byte() does the right thing, we can just use it and not
worry about the rest.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
We call bi_optimize_nir() a few lines later.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
This isn't hard to do and it gives us a lot more flexibility in what NIR
we can consume.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
Add asserts this time that we don't miss any and that the buckets
actually match the enum in bifrost/compiler.h.
Fixes: 82328a5245 ("pan/bi: Generate instruction packer for new IR")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
It appears nowhere so I don't know why we have it in the enum.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40769>
