[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPM=9tzMUi_9BRL8onjvXoj8Cb0eQFpFwmKHveGTCRU1Nc7O3Q@mail.gmail.com>
Date: Thu, 6 Nov 2025 11:10:25 +1000
From: Dave Airlie <airlied@...il.com>
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,
Simona Vetter <simona@...ll.ch>, Joel Fernandes <joelagnelf@...dia.com>
Subject: Re: [PATCH v2 0/2] drm/nouveau: Advertise correct modifiers on GB20x
I've pushed both of these to drm-misc-fixes.
Thanks,
Dave.
On Fri, 31 Oct 2025 at 04:07, 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
>
> 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 in v2:
>
> -Added "Fixes: 6cc6e08d4542" line since this can be considered a bug
> fix for the initial blackwell KMS support in nouveau.
>
> -Dropped the second patch from the v1 series as it has been merged.
>
> 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 (2):
> drm: define NVIDIA DRM format modifiers for GB20x
> drm/nouveau: Advertise correct modifiers on GB20x
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++-
> drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 +
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 24 +++++++++++++--
> drivers/gpu/drm/nouveau/dispnv50/wndwca7e.c | 33 +++++++++++++++++++++
> include/uapi/drm/drm_fourcc.h | 25 ++++++++++------
> 5 files changed, 75 insertions(+), 12 deletions(-)
>
> --
> 2.50.1
>
Powered by blists - more mailing lists