Transaction Elimination on a RT is disabled until there's a full frame
render with all tiles forcefully written back. This is currently done
by letting the Gallium driver track states and fix up FB preload by
disabling clean_fragment_write on the pre-frame DCD and by setting the
pre-frame mode to "always" (instead of "intersect").
This commit forces the write-back of all the tiles by setting
clean_tile_write_enable on the FBD instead. This simplifies the code
and removes most of the CRC state tracking from the Gallium driver.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This commit doesn't really change the selection logic but tries to
make the reasoning more straightforward and prepare for future commits
where the CRC state will be cached.
A usable RT must pass a few conditional checks like the availability
of a CRC buffer. A selected RT must be usable and either have a valid
CRC buffer or be fully covered. In the MRT case, the first usable RT
with a valid CRC buffer is selected. If no RT has a CRC buffer
initialized, then the first usable RT is selected at the condition
it's fully covered.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
CRC RT selection for v5 and v6 (v4 isn't supported) currently returns
0 (instead of -1) as long as the CRC buffer is usable but without
checking its validity like it's done for v7+. While it doesn't
incorrectly enable Transaction Elimination, it uselessly makes
dependent CRC code paths taken.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Arch v5 and v6 should test the AFBC render block size too. In the
non-AFBC case, there's no need to check for the tile size which is
checked earlier by the caller.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Add function to retrieve whether the area of a pan_fb_info data
structure is fully covered by the draw extent.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Restrict the creation of a CRC buffer for an image to the 1st mipmap
level. At emit_fbd() time, Transation Elimination is only enabled if
CRC is enabled for the selected RT and if its first configured level
is 0.
This was previously enforced at the Gallium driver level but it needs
to be done at the lib level to later support PanVK too.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
It turns out we need the color sysvals recorded in system_values_read,
and PARAM_GEN is for point smoothing.
Acked-by: Pierre-Eric
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40556>
Some Max Payne 3 shaders are impacted by this and probably will fix some
issue there. The VK CTS isn't testing this, but it was verified to fix a
real problem by inserting 0 offsets into the instruction and having CTS
tests fail with the old ordering.
Totals from 3 (0.00% of 1163204) affected shaders:
CodeSize: 2496 -> 2736 (+9.62%)
Static cycle count: 732 -> 741 (+1.23%)
Fixes: ad01fbdda0 ("nak: Add a NIR texture lowering pass")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40957>
With the previous commit ("ac/surface: Filter swizzle modes for VCN"),
only video-compatible swizzle modes will be picked, so we can enable
tiling for VCN2+.
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40948>
This will allow compatible swizzle modes to be picked for RADV (radeonsi
filters modifiers when creating video surfaces).
This mirrors the logic from ac_modifier_supports_video, and in
addition ensures that XOR swizzle modes are disabled for image arrays
because VCN does not support slice indices.
Reviewed-by: David Rosca <david.rosca@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40948>
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>
The format has 4 x 16-bit words with 10-bit unorm values in bits [15:6]
and 6 padding bits in [5:0]. Since this requires 8 channel slots but the
format system only supports 4, use layout "other" with hand-written
pack/unpack conversion functions.
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>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40653>
The recent addition of PIPE_FORMAT_X6R10X6G10X6B10X6A10_UNORM caused
vk_format_to_pipe_format() to map VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
to a real pipe format, which made radv_physical_device_get_format_properties()
advertise BLIT_SRC/SAMPLED_IMAGE for it. The hardware samples the data as plain
R16G16B16A16 UNORM, which doesn't match the 10-bit UNORM semantics the spec
(and CTS) require, so dEQP-VK.api.copy_and_blit.core.blit_image.* tests with
r10x6g10x6b10x6a10x6_unorm_4pack16 as the source started failing on gfx1201.
Override the mapping to PIPE_FORMAT_NONE so RADV reports zero format features,
matching the behavior prior to the new pipe format being added. Proper support
can be restored once VK_EXT_rgba10x6_formats is implemented.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40653>
Latest VKCTS main uses way less memory than before, and increasing the
number of deqp instances to 16 seems to work just fine now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40918>
