Re: [PATCH v5 05/11] drm: nova: Add an info ioctl

[Alistair Popple <apopple@nvidia.com>]

On 2026-09-02 at 19:40 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Wed Sep 2, 2026 at 4:38 AM CEST, Alistair Popple wrote:
> > So I'm ok with providing either a decoded architecture and implementation
> > xor an opaque chip-id. Or alternatively maybe architecture includes the
> > implementation (ie. we rename the opaque chip_id to architecture). But treating
> > the implementation and architecture values differently and only providing one
> > directly doesn't make much sense IMHO.
> 
> I think this is you still thinking about this in terms of register encoding.

No, this is just me trying to figure out what user-space would use the
architecture value for, as on it's own it's a pretty a useless value from a
user-space perspective. For user-space to do anything useful it needs to know
the implementation as well regardless of how that's encoded. It can't for
example run anything reliably knowing only the arch AFAICT.

Originally I thought the point of providing the decoded arch rather than
chip-id might have been to allow a kernel to support chips with a known arch
but unknown implementation, because as you rightfully point out the kernel
doesn't (currently at least) care much about the implementation, so an updated
user-space could maybe run fine on the same arch, different implementation.

But we agreed that wasn't desirable, so now I'm still left figuring out why we
need to provide an arch value? The chip-id already entirely encapsulates the
concept, so what can/should user-space use the arch value for?

> > Except the architecture/implementation tuple is exaclty what user-space needs to
> > eg. figure out what SM to compile for.
>
> It doesn't need an architecture/implementation tuple, it needs a chipid for this
> lookup. (Although it might be questionable whether userspace should have this
> lookup table in the first place; see below.)

Maybe I could've been clearer here - what I meant is that userspace needs the
architecture *and* implementation. Whether or not that comes via opaque chip-id
or some other means doesn't matter to me, what matters is that user-space needs
both bits of information - the architecture on it's own is not very helpful.

> Both the KMD and the UMD only ever care about the architecture or the chipid.
> The fact that the chipid is defined by an architecture/implementation tuple is
> an irrelevant implementation detail not even the kernel cares about.
>
> > And to be clear we don't care about the specific encodings in this example. The
> > point is the SM version can't be looked up from architecture alone, it needs the
> > implementation as well and if the only way to get that is from opaque chip-id
> > that's all user-space will look at. Eg:
> 
> Again, it doesn't need the implementation, it needs the chipid. Which also your
> code below correctly considers.

Right. This is what we had agreed on previously - provide an opaque chip-id
userspace can use to lookup whatever chip info it needs. You asked for the arch
value to be provided separately, but I can't figure out what the use-case for it
is and I don't think we should be adding things to the uAPI that we can't even
imagine use-cases for. We can always add it to the uAPI later if we do find a
need, but it's much harder to remove stuff and right now I can't see any reason
to provide it.

Also for a bit of background on this series, which I should have put in the
cover-letter and will next time, the goal is to get a basic deviceQuery sample
running. That's why I started with these properties first, as they're what CUDA
or Mesa need to fully populate their device properties.

> That said, if we know that userspace will never need to do an architecture based
> check, but always a chipid specific check, it is obviously pointless to expose
> it in the first place. But otherwise it should just be chipid and architecture.

That is where I ended and what I had originally - lets just provide the opaque
chip-id. If we provide the chipid why would user-space ever need the arch? What
can it do with an architecture value that it can't do with the chipid? Again I
don't think we should be adding things to the UAPI that userspace has no known
use for.

But it sounds like you might actually be ok with us just providing chip-id?

We already know the full chip-id is needed, so it makes sense to expose that
now.

> > static uint8_t
> > sm_for_chipset(enum chip_id chip)
> > {
> > 	switch (chip) {
> > 		case NOVA_GPU_CHIP_GA100:
> > 			return 80;
> > 		case NOVA_GPU_CHIP_GA101:
> > 			return 86;
> > 		case NOVA_GPU_CHIP_GA102:
> > 			return 86;
> > 		case NOVA_GPU_CHIP_GA10B:
> > 			return 87;
> > 		...
> > 	}
> > }
> 
> That looks reasonable and much better than what mesa has, but if we'd ever care
> about the SM value in the kernel, then the kernel should be the single source of
> truth for this value and expose it to userspace.

Yes, no problem with this.

> Now, in this case I don't think the kernel really needs the value, but I think
> the value is provided by GSP through GR_INFO_INDEX_SM_VERSION?

Argh. There is, shall we say, some nuance here :-) HW have not made our lives
easy and actually figuring out what the version that matters to user-space is
is not as straight forward as one might like, and may well not match what the
kernel would want (if it ever needs it).

> Given that, the kernel should query it and provide it via its GPU info structure
> rather than having userspace invent another lookup table?

It really boils down to how much static config info we want to encode into
kernel lookup tables vs. user-space lookup tables. I don't this we should be
filling the kernel with a bunch of static struct lookups just to ship those
struct definitions to user-space. It seems more reasonable to put that in
user-space, unless of course the kernel needs it.

So I think your "does the kernel need this" is a reasonable benchmark for
deciding this.

As I think you're hinting at it would be ideal if GSP or some other firmware
table could just provide everything in some nice static config table, but I
don't think that's currently possible and looking at other user-space drivers
we're certainly not alone there.

 - Alistair