lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2773531.vuYhMxLoTh@fedora-1.home>
Date: Tue, 27 Jan 2026 12:06:35 +0100
From: Caterina Shablia <caterina.shablia@...labora.com>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 kernel@...labora.com, Steven Price <steven.price@....com>,
 Liviu Dudau <liviu.dudau@....com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] drm: add ARM interleaved 64k modifier

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@...labora.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@...labora.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





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ