public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Caterina Shablia <caterina.shablia@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: Mon, 26 Jan 2026 10:05:45 +0100	[thread overview]
Message-ID: <20260126100545.08a4ffd1@fedora> (raw)
In-Reply-To: <20260123212327.83064-1-caterina.shablia@collabora.com>

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


  reply	other threads:[~2026-01-26  9:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 21:23 [PATCH v1] drm: add ARM interleaved 64k modifier Caterina Shablia
2026-01-26  9:05 ` Boris Brezillon [this message]
2026-01-27 11:06   ` Caterina Shablia

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=20260126100545.08a4ffd1@fedora \
    --to=boris.brezillon@collabora.com \
    --cc=airlied@gmail.com \
    --cc=caterina.shablia@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