linux-kernel - [PATCH 0/3] drm/nouveau: Advertise correct modifiers on GB20x

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-next>] [day] [month] [year] [list]

Message-ID: <20250811220017.1337-1-jajones@nvidia.com>
Date: Mon, 11 Aug 2025 15:00:14 -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 0/3] 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 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