From: Caterina Shablia <caterina.shablia@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
kernel@collabora.com, Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] drm: add ARM interleaved 64k modifier
Date: Tue, 27 Jan 2026 12:06:35 +0100 [thread overview]
Message-ID: <2773531.vuYhMxLoTh@fedora-1.home> (raw)
In-Reply-To: <20260126100545.08a4ffd1@fedora>
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
prev parent reply other threads:[~2026-01-27 11:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 21:23 Caterina Shablia
2026-01-26 9:05 ` Boris Brezillon
2026-01-27 11:06 ` Caterina Shablia [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2773531.vuYhMxLoTh@fedora-1.home \
--to=caterina.shablia@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome