NVIDIA GPU driver infrastructure
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Danilo Krummrich" <dakr@kernel.org>,
	"Alistair Popple" <apopple@nvidia.com>
Cc: "nova-gpu" <nova-gpu@lists.linux.dev>,
	"M Henning" <mhenning@darkrefraction.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"David Airlie" <airlied@gmail.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Benno Lossin" <lossin@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Eliot Courtney" <ecourtney@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v5 05/11] drm: nova: Add an info ioctl
Date: Fri, 04 Sep 2026 12:13:58 +0100	[thread overview]
Message-ID: <DL6HKYRXHNFK.1D9HYNEPH4GCR@garyguo.net> (raw)
In-Reply-To: <DL5MA26KZEF9.3KHKQXZ4JD2G6@kernel.org>

On Thu Sep 3, 2026 at 11:42 AM BST, Danilo Krummrich wrote:
> On Thu Sep 3, 2026 at 3:12 AM CEST, Alistair Popple wrote:
>> Originally I thought the point of providing the decoded arch rather than
>> chip-id
>
> I think there never was a "rather than". The point was that if userspace has
> conditionals based on the architecture it shouldn't have to figure it out based
> on the chipid, as this has been done by the kernel already.
>
>> because as you rightfully point out the kernel doesn't (currently at least)
>> care much about the implementation
>
> I still don't see how that value will ever be meaningful, there is no such thing
> as "all GPUs of a certain implementation regardless of architecture" have
> something in common, is it?

I don't think it's an issue that implementation field is only meaningful when
you get the architecture. That's pretty common for other IDs, e.g. PCI product
ID is meaningless without having the vendor ID.

You mentioned in an earlier email about the typing, but we could still have
meaningful impl IDs fully typed like this:

    pub enum Arch {
        Turing(impl_id),
        Ampere(impl_id),
        ...
    }

and some langauges can do better, e.g. TypeScript allow you to write

    enumn ArchId {
        Turing,
        Ampere,
        ...
    }

    enum TuringImplId { ... }
    enum AmpereImplId { ... }

    type Id =
        { arch: ArchId.Turing, impl: TuringImplId } |
        { arch: ArchId.Ampere, impl: AmpereImplId };

So I think it's a reasonable design to have it.

>
> But since you say "currently at least", are there any plans to give this value
> some meaning beyond being a unique counter for chips within a certain
> architecture?
>
> If so, I think that'd be a horrible way to encode some chip commonality.

True, but I think the chip ID is as bad as impl ID. Feature detections should
use dedicated featuire detection mechanism, not looking up IDs directly. I.e. we
should have userspace not having to use either chip ID or impl ID as much as we
can.

That said, I do think looking up tables are unavoidable, for getting names or
applying some quirk fixes. And I agree with Alistair that if we include it,
including impl ID is better than the chip ID, as we should rather not having
user space relying on an arbitrary encoded chip ID.

Best,
Gary


  parent reply	other threads:[~2026-09-04 11:14 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  3:35 [PATCH v5 00/11] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple
2026-08-28  3:35 ` [PATCH v5 01/11] gpu: nova-core: Add public driver API to nova-core Alistair Popple
2026-08-31 20:08   ` Danilo Krummrich
2026-08-31 20:42     ` Gary Guo
2026-09-01  7:07       ` Alistair Popple
2026-09-01  7:14         ` Danilo Krummrich
2026-09-01  9:13           ` Alistair Popple
2026-09-01  9:21             ` Danilo Krummrich
2026-09-01 10:27       ` Danilo Krummrich
2026-09-01 11:35         ` Gary Guo
2026-09-01  3:53     ` Alistair Popple
2026-09-02  6:57     ` Alistair Popple
2026-09-02 19:30       ` Danilo Krummrich
2026-08-28  3:35 ` [PATCH v5 02/11] drm: nova: Add DRM registration data Alistair Popple
2026-08-28  3:35 ` [PATCH v5 03/11] drm: nova: Add GPU architecture enum to nova-drm UAPI Alistair Popple
2026-08-28  3:35 ` [PATCH v5 04/11] rust: uaccess: add UserSliceWriter::write_truncated() Alistair Popple
2026-08-28  3:35 ` [PATCH v5 05/11] drm: nova: Add an info ioctl Alistair Popple
2026-08-31  4:58   ` Alistair Popple
2026-08-31 14:23   ` Danilo Krummrich
2026-09-01  3:47     ` Alistair Popple
2026-09-01  4:50       ` Dave Airlie
2026-09-01  5:09         ` Alistair Popple
2026-09-01  7:29           ` Danilo Krummrich
2026-09-02  5:21             ` Alistair Popple
2026-09-02  7:05               ` Alistair Popple
2026-09-02 19:26                 ` Danilo Krummrich
2026-09-02 19:38                   ` Dave Airlie
2026-09-02 19:42                     ` Danilo Krummrich
2026-09-01  4:53   ` Dave Airlie
2026-09-01  5:24     ` Alistair Popple
2026-09-01 10:38   ` Danilo Krummrich
2026-09-01 17:01     ` Danilo Krummrich
2026-09-02  2:38       ` Alistair Popple
2026-09-02  9:40         ` Danilo Krummrich
2026-09-03  1:12           ` Alistair Popple
2026-09-03 10:42             ` Danilo Krummrich
2026-09-04  7:49               ` Alistair Popple
2026-09-04  9:34                 ` Danilo Krummrich
2026-09-04 11:13               ` Gary Guo [this message]
2026-09-04 12:08                 ` Danilo Krummrich
2026-08-28  3:35 ` [PATCH v5 06/11] drm: nova: Add usable VRAM size to GPU info Alistair Popple
2026-08-28  3:35 ` [PATCH v5 07/11] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter Alistair Popple
2026-08-28  3:35 ` [PATCH v5 08/11] drm: nova: Expose a render node Alistair Popple
2026-08-28  3:35 ` [PATCH v5 09/11] drm: nova: Report GPU name in GPU info Alistair Popple
2026-08-31 14:33   ` Danilo Krummrich
2026-09-01  3:09     ` Alistair Popple
2026-08-28  3:35 ` [PATCH v5 10/11] drm: nova: Report GPU short " Alistair Popple
2026-08-31 14:41   ` Danilo Krummrich
2026-09-01  3:10     ` Alistair Popple
2026-08-28  3:35 ` [PATCH v5 11/11] drm: nova: Report GPU GID " Alistair Popple
2026-08-28  6:04 ` [PATCH v5 00/11] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple

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=DL6HKYRXHNFK.1D9HYNEPH4GCR@garyguo.net \
    --to=gary@garyguo.net \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mhenning@darkrefraction.com \
    --cc=nova-gpu@lists.linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    /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