mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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





      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