[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOFGe972S7S23LGKxEmVq_beyRMpDJE-2rMt0aobPj4HnmWSXw@mail.gmail.com>
Date: Fri, 22 Aug 2025 16:44:11 -0400
From: Faith Ekstrand <faith@...strand.net>
To: James Jones <jajones@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Lyude Paul <lyude@...hat.com>,
Faith Ekstrand <faith.ekstrand@...labora.com>, nouveau@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Joel Fernandes <joelagnelf@...dia.com>
Subject: Re: [PATCH 0/3] drm/nouveau: Advertise correct modifiers on GB20x
On Mon, Aug 11, 2025 at 5:57 PM James Jones <jajones@...dia.com> wrote:
>
> This series adds new format modifiers for 8 and 16-bit formats on GB20x
> GPUs, preventing them from mistakenly sharing block-linear surfaces
> using these formats with prior GPUs that use a different layout.
>
> There are a few ways the parameteric format modifier definition
> could have been altered to handle the new layouts:
>
> -The GOB Height and Page Kind field has a reserved value that could
> have been used. However, the GOB height and page kind enums did
> not change relative to prior chips, so this is sort of a lie.
> However, this is the least-invasive change.
>
> -An entirely new field could have been added. This seems
> inappropriate given the presence of an existing appropriate field.
> The advantage here is it avoids splitting the sector layout field
> across two bitfields.
>
> The chosen approach is the logically consistent one, but has the
> downside of being the most complex, and that it causes the
> DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro to evaluate its 's'
> parameter twice. However, utilizing simple helper functions in
> client code when accessing the parameteric format modifier fields
> easily addresses the complexity, and I have audited the relevant code
> and do not believe the double evaluation should cause any problems in
> practice.
>
> Tested on GB20x and TU10x cards using the following:
>
> -kmscube w/NVK+Zink built with these patches applied:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36336
Both the Mesa and kernel pieces are now reviewed so I think we're good
to start landing. I've independently tested with kmscube to verify.
~Faith
>
> with various manually specified formats
> and both manually specified and automatically
> selected modifiers.
>
> -drmfmtmods, a tiny test program that lists modifiers:
>
> https://github.com/cubanismo/drmfmtmods
>
> Changes since the RFC version here:
>
> https://lore.kernel.org/nouveau/20250703223658.1457-1-jajones@nvidia.com/
>
> -Dropped the helper macros & static inlines in
> drm_fourcc.h as requested by Faith Ekstrand,
> who noted these aren't helpful for UMD code,
> which is all written in rust now. I may re-
> introduce some of these in a subsequent series,
> but we both agreed we do not want to delay
> progress on the modifiers themselves while we
> debate the details of those cometic details.
>
> -Reserved an extra bit for future sector
> layouts.
>
> -Fixed handling of linear modifiers on GB20x
> and NV5x/G8x/G9x/GT2xx chips.
>
> James Jones (3):
> drm: define NVIDIA DRM format modifiers for GB20x
> drm/nouveau/disp: Always accept linear modifier
> drm/nouveau: Advertise correct modifiers on GB20x
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++
> drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 +
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 25 ++++++++++++++--
> drivers/gpu/drm/nouveau/dispnv50/wndwca7e.c | 33 +++++++++++++++++++++
> include/uapi/drm/drm_fourcc.h | 25 ++++++++++------
> 5 files changed, 76 insertions(+), 11 deletions(-)
>
> --
> 2.50.1
>
Powered by blists - more mailing lists