* [PATCH v1] drm: add ARM interleaved 64k modifier @ 2026-01-23 21:23 Caterina Shablia 2026-01-26 9:05 ` Boris Brezillon 0 siblings, 1 reply; 3+ messages in thread From: Caterina Shablia @ 2026-01-23 21:23 UTC (permalink / raw) To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter Cc: kernel, Caterina Shablia, Boris Brezillon, Steven Price, Liviu Dudau, dri-devel, linux-kernel This modifier is intended to be used by panvk to implement sparse partially-resident images with better map and unmap performance, and no worse access performance, compared to implementing them in terms of U-interleaved. With this modifier, the arrangement of texel blocks is very similar to block U-interleaved. Tiles are laid out linearly. Tiles are always 64k bytes in size and are 1:1-sided rectangles when texel block is 1 byte or a multiple of 4 bytes, and 2:1-sided otherwise. Only power of two byte texel blocks can be used with this modifier. Within a single tile, texels are arranged according to U-interleaving. Unlike block U-interleaved, the layout depends solely on texel block size and doesn't change depending on whether the image format is compressed or not. The hardware features corresponding to this modifier are available starting with v10 (second gen Valhall.) The corresponding panvk MR can be found at: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38986 Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com> --- include/uapi/drm/drm_fourcc.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index e527b24bd824..0da2c880e08c 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -1422,6 +1422,16 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) #define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \ DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL) +/* + * ARM 64k interleaved modifier + * + * This is used by ARM Mali v10+ GPUs. It's basically the same as 16x16 block + * U-interleaved, but within 64k-byte 1:1 or 2:1 -sided tiles. Tiles themselves + * are laid out linearly. + */ +#define DRM_FORMAT_MOD_ARM_INTERLEAVED_64K \ + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 2ULL) + /* * Allwinner tiled modifier * base-commit: f08f665f8cda9520d98ee24545d306a92f386616 -- 2.47.3 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v1] drm: add ARM interleaved 64k modifier 2026-01-23 21:23 [PATCH v1] drm: add ARM interleaved 64k modifier Caterina Shablia @ 2026-01-26 9:05 ` Boris Brezillon 2026-01-27 11:06 ` Caterina Shablia 0 siblings, 1 reply; 3+ messages in thread From: Boris Brezillon @ 2026-01-26 9:05 UTC (permalink / raw) To: Caterina Shablia Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter, kernel, Steven Price, Liviu Dudau, dri-devel, linux-kernel Hello Caterina, On Fri, 23 Jan 2026 21:23:25 +0000 Caterina Shablia <caterina.shablia@collabora.com> wrote: > This modifier is intended to be used by panvk to implement sparse > partially-resident images with better map and unmap performance, > and no worse access performance, compared to implementing them in > terms of U-interleaved. > > With this modifier, the arrangement of texel blocks is very similar > to block U-interleaved. Tiles are laid out linearly. Tiles are > always 64k bytes in size and are 1:1-sided rectangles when texel > block is 1 byte or a multiple of 4 bytes, and 2:1-sided otherwise. It's not all that clear that we're dealing with mega tiles formed with a set of U-interleaved tiles. Also, the 1:1-sided rectangle sounds like a complex way to qualify a square. " This modifier is a exposing mega tiles of 64 KiB. It's formed of U-interleaved tiles laid out linearly to cover a square or a rectangle whose width is twice the height. " > Only power of two byte texel blocks can be used with this modifier. > Within a single tile, texels are arranged according to U-interleaving. > > Unlike block U-interleaved, the layout depends solely on texel block > size and doesn't change depending on whether the image format is > compressed or not. Hm, are you sure of that? I'd assume the inner tile size to still depend on compressed vs !compressed, meaning the overall layout is also dependent on the compressed vs !compressed property. > > The hardware features corresponding to this modifier are available > starting with v10 (second gen Valhall.) > > The corresponding panvk MR can be found at: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38986 > > Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com> > --- > include/uapi/drm/drm_fourcc.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index e527b24bd824..0da2c880e08c 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -1422,6 +1422,16 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > #define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \ > DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL) > > +/* > + * ARM 64k interleaved modifier > + * > + * This is used by ARM Mali v10+ GPUs. It's basically the same as 16x16 block > + * U-interleaved, but within 64k-byte 1:1 or 2:1 -sided tiles. Again, it's not clear from this description that this modifier is exposing "mega" tiles formed with a set of U-interleaved tiles spanning a 64KiB section. The way I read this is that it's U-interleaved, but over a bigger region, like 256x256 U-interleaved. Regards, Boris > Tiles themselves > + * are laid out linearly. > + */ > +#define DRM_FORMAT_MOD_ARM_INTERLEAVED_64K \ > + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 2ULL) > + > /* > * Allwinner tiled modifier > * > > base-commit: f08f665f8cda9520d98ee24545d306a92f386616 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v1] drm: add ARM interleaved 64k modifier 2026-01-26 9:05 ` Boris Brezillon @ 2026-01-27 11:06 ` Caterina Shablia 0 siblings, 0 replies; 3+ messages in thread From: Caterina Shablia @ 2026-01-27 11:06 UTC (permalink / raw) To: Boris Brezillon Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter, kernel, Steven Price, Liviu Dudau, dri-devel, linux-kernel El dilluns, 26 de gener del 2026, a les 10:05:45 (Hora estàndard d’Europa central), Boris Brezillon va escriure: > Hello Caterina, > > On Fri, 23 Jan 2026 21:23:25 +0000 > > Caterina Shablia <caterina.shablia@collabora.com> wrote: > > This modifier is intended to be used by panvk to implement sparse > > partially-resident images with better map and unmap performance, > > and no worse access performance, compared to implementing them in > > terms of U-interleaved. > > > > With this modifier, the arrangement of texel blocks is very similar > > to block U-interleaved. Tiles are laid out linearly. Tiles are > > always 64k bytes in size and are 1:1-sided rectangles when texel > > block is 1 byte or a multiple of 4 bytes, and 2:1-sided otherwise. > > It's not all that clear that we're dealing with mega tiles formed with > a set of U-interleaved tiles. Also, the 1:1-sided rectangle sounds > like a complex way to qualify a square. > > " > This modifier is a exposing mega tiles of 64 KiB. It's formed of > U-interleaved tiles laid out linearly to cover a square or a rectangle > whose width is twice the height. > " > > > Only power of two byte texel blocks can be used with this modifier. > > Within a single tile, texels are arranged according to U-interleaving. > > > > Unlike block U-interleaved, the layout depends solely on texel block > > size and doesn't change depending on whether the image format is > > compressed or not. > > Hm, are you sure of that? I'd assume the inner tile size to still > depend on compressed vs !compressed, meaning the overall layout is also > dependent on the compressed vs !compressed property. Yes, this can be confirmed using panvk and vk cts by making panvk use INTERLEAVED_64K for images with BLOCK_TEXEL_VIEW_COMPATIBLE and then running the CTS exercising this feature. Using a modifier that changes under whether a format is compressed, such as 16X16_BLOCK_U_INTERLEAVED, will result in failures. > > > The hardware features corresponding to this modifier are available > > starting with v10 (second gen Valhall.) > > > > The corresponding panvk MR can be found at: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38986 > > > > Signed-off-by: Caterina Shablia <caterina.shablia@collabora.com> > > --- > > > > include/uapi/drm/drm_fourcc.h | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > > index e527b24bd824..0da2c880e08c 100644 > > --- a/include/uapi/drm/drm_fourcc.h > > +++ b/include/uapi/drm/drm_fourcc.h > > @@ -1422,6 +1422,16 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 > > modifier)> > > #define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \ > > > > DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL) > > > > +/* > > + * ARM 64k interleaved modifier > > + * > > + * This is used by ARM Mali v10+ GPUs. It's basically the same as 16x16 > > block + * U-interleaved, but within 64k-byte 1:1 or 2:1 -sided tiles. > > Again, it's not clear from this description that this modifier is > exposing "mega" tiles formed with a set of U-interleaved tiles spanning > a 64KiB section. The way I read this is that it's U-interleaved, but > over a bigger region, like 256x256 U-interleaved. > > Regards, > > Boris > > > Tiles themselves > > + * are laid out linearly. > > + */ > > +#define DRM_FORMAT_MOD_ARM_INTERLEAVED_64K \ > > + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 2ULL) > > + > > > > /* > > > > * Allwinner tiled modifier > > * > > > > base-commit: f08f665f8cda9520d98ee24545d306a92f386616 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-01-27 11:07 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-23 21:23 [PATCH v1] drm: add ARM interleaved 64k modifier Caterina Shablia 2026-01-26 9:05 ` Boris Brezillon 2026-01-27 11:06 ` Caterina Shablia
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox