[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251030181153.1208-1-jajones@nvidia.com>
Date: Thu, 30 Oct 2025 11:11:51 -0700
From: James Jones <jajones@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>,
	Lyude Paul <lyude@...hat.com>,
	Faith Ekstrand <faith.ekstrand@...labora.com>
Cc: 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>,
	James Jones <jajones@...dia.com>
Subject: [PATCH v2 0/2] drm/nouveau: Advertise correct modifiers on GB20x
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
 
