Instead of increasing the version number to describe which fields
are set, use the lower 16 bits for the metadata format version,
and the other bits as flags.
This way the version number defines the layout, and the flags
tell which values are set.
The format version is bumped to 3 (= can have flags), and 2 flags
are defined:
* AC_SURF_METADATA_FLAG_EXTRA_MD_BIT: replaces what was version
number = 2. This means the metadata contains extra information
for tools.
* AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT: if set, it means the
surface was allocated from a context that used an overriden gfx
family. This allows the importer process to fail the import early,
as the surface is likely to be invalid.
It also adds an extra dw at the end, to store the fake family.
This is a breaking change for existing code that interpreted
"version > 1" as 2, but only in one case:
AC_SURF_METADATA_FLAG_FAMILY_OVERRIDEN_BIT being set, but not
AC_SURF_METADATA_FLAG_EXTRA_MD_BIT, which produces a version number
of 0x20001 but there's not extra data.
I think this is ok, since both gfx family overriding and extra_md
are debugging tools.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31841>
Computing 'htile_size/meta_size' is allowed for RADEON_SURF_MODE_1D when
RADEON_SURF_TC_COMPATIBLE_HTILE isn't set.
Lacking of computing causes performance degradation in some scenarios.
Fixes: d4d9ec55c5 ("radeonsi: implement TC-compatible HTILE")
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31617>
For surfaces without a modifier, the surf_size check wasn't
necessary, but it was also invalid since surf_size is set later
(in gfx12_compute_miptree).
Since it's not required anyway, drop this check.
Fixes: 060d5dacfd ("ac: add gfx12 DCC shared code")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31683>
It's 58, not 59. The original 58 feature was not
ready so it was dropped.
Fixes: 0bb83a4060 ("ac/surface: finish display DCC for gfx12")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30212>
radv has a comment in radv_meta_dcc_retile.c:
* BPE is always 4 at the moment and the rest is derived from the tilemode.
radeonsi has in si_retile_dcc:
/* We have only 1 variant per bpp for now, so expect 32 bpp. */
assert(tex->surface.bpe == 4);
This fixes ext_image_dma_buf_import-modifiers for radeonsi.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29612>
It's not worth writing a compute shader for copying 3D textures yet.
I have a sophisticated compute shader that will do it properly.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28607>
Yet another iteration on the same YUV surfaces.
The change from 87ecfdfbf0 has 2 odd things:
* it's using MAX2(original value, new value) but the point of updating
surf_slice_size / surf_size is to make it correct relative to the new
value of surf_pitch
* it's multiplying surf_pitch (= number of elements per row) by height (ok)
by surf->bpe (= number of bytes per element) by surf->blk_w (= number of
"horizontal" pixels in an element) so the end unit doesn't make sense.
Fix this by computing a reasonnable value based on unit: the surf_slice_size
is the number of elements per row (surf_pitch) x number of bytes per element
(bpe) x number of rows.
This makes the expected size correct and thus fixes users of eglCreateImageKHR,
like the issue #6131.
I tested a bunch of gst pipelines and ffmpeg scripts on various files I have
and didn't notice any issues (on gfx10.3 and gfx9).
Fixes: 87ecfdfbf0 ("ac/surface: adapt surf_size when modifying surf_pitch")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6131
Acked-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26693>
This is loosely based on PAL. This seems to fix 3D PRT support with
RADV on Polaris10. THIN means the tile is a 2D slice. THICK means the
tile is a 3D box.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26260>
It was reported that it broke Stoney. Something probably uses a suboptimal
pitch, like minigbm.
Fixes: 7d066330e0 - ac/surface: relax custom pitch requirements to any multiple of 256B on gfx10.3+
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25540>
For z surfaces, flags.texture should be based on
RADEON_SURF_TC_COMPATIBLE_HTILE alone. Otherwise, addrlib could pick a
_X/_T swizzle mode for a MSAA depth texture, which is said to be broken:
When _X/_T swizzle mode was used for MSAA depth texture, TC will get zplane
equation from wrong address within memory range a tile covered and use the
garbage data for compressed Z reading which finally leads to corruption.
Fixes: de0885cdb8 ("amd/surface: add RADEON_SURF_NO_TEXTURE flag")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24767>
