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

[Alistair Popple <apopple@nvidia.com>]

On 2026-09-03 at 20:42 +1000, Danilo Krummrich <dakr@kernel.org> 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.

I see. Maybe that was a bad assumption on my behalf, because I assumed that if
you make a precise hardware description available (chip-id) there'd be no point
making an imprecise subset of that description (arch) available as it isn't
particularly useful if you can't use it in isolation for any generic purpose.

Which is to say it's unclear what generic properties users are allowed to derive
from the kernel saying "this is a Hopper GPU". It's clearer for a chip-id as it
represents an (almost) exact piece of HW with the exact properties of that HW,
so userspace can derive everything from that.

Anyway guess I will just leave it in, time will tell what use it has, even
though I think it would be better to know that use upfront.

> > 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?
> 
> 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?

Oh I just meant AFAIK the kernel isn't currently looking at the implementation
because everything it cares about (like the HAL) can be keyed off the
architecture and that's been my experience with most of our GPU kernel drivers.

Or IOW, at the moment, from a kernel perspective the kernel doesn't care about
implementation beyond needing to encode that into a type. So supporting for
example GB203 instead of GB202 amounts to just adding the encoding for that.
If we didn't need to add the encoding the kernel could say claim support for all
Blackwell implementations.

Of course whether this remains true generally requires a fair bit of
co-operation from the HW, and I'm not sure we're actually there yet although I
think there has been some discussions in the past.

But it would be a nice place to be - having dealt with similar problems in
the past on the CPU side it all becomes a bit of a pain constantly backporting
patches to a bunch of distros just to allow a +1 on your minor HW version that
the kernel doesn't actually care about anyway.

But we already agreed this isn't something we can or want to solve here and now,
so this is really just an aside. Maybe one day we can get there, but not now.

> If so, I think that'd be a horrible way to encode some chip commonality.
> 
> > 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?
> 
> Because userspace otherwise has to figure out the architecture itself based on
> the chipid, while the kernel already did derive this information.

That wasn't my question. My question wasn't where should userspace get the
arch, it is what can user-space use the arch value for? Again, architecture
alone isn't entirely sufficient for user-space. There isn't for example a neat
mapping of arch to sm version for code generation once you start looking at all
our GPUs.

> There's many ways userspace could do this, and I don't want to incentivise any
> of them.
> 
> For instance, you previously showed how userspace derives the SM value from the
> chipid with sm_for_chipset() in mesa with its own lookup table.
> 
> Then in NAK (src/nouveau/compiler/nak/ir.rs), there's this code.
> 
> 	fn is_turing(&self) -> bool {
> 	    self.sm() >= 73 && self.sm() < 80
> 	}
> 	
> 	fn is_ampere(&self) -> bool {
> 	    self.sm() >= 80 && self.sm() < 89
> 	}
> 	
> 	fn is_ada(&self) -> bool {
> 	    self.sm() == 89
> 	}
> 	
> 	#[allow(dead_code)]
> 	fn is_hopper(&self) -> bool {
> 	    self.sm() >= 90 && self.sm() < 100
> 	}
> 	
> 	fn is_blackwell_a(&self) -> bool {
> 	    self.sm() >= 100 && self.sm() < 110
> 	}
> 	
> 	fn is_blackwell_b(&self) -> bool {
> 	    self.sm() >= 120 && self.sm() < 130
> 	}
> 	
> 	fn is_blackwell(&self) -> bool {
> 	    self.is_blackwell_a() || self.is_blackwell_b()
> 	}
> 
> That's two unnecessary indirections for something the kernel already has
> available.

Again though is what the kernel provides in the form of an arch actually useful
to user-space? Obviously the code above makes it look nice and simple like that,
but as I have been saying more complete implementations can't just rely on arch
alone and so are still going to have lookup tables both for SM and for other
info the kernel can't provide.

Anyway at this point I'll just leave chipset and arch in. Clearly you think
there is some value in providing it separately, and I suppose it doesn't make
much difference just to have it there.

> > 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.
> 
> Yeah, although if SM is correctly reported by the GSP, I'd rather have it
> exported in an info structure than have userspace create its own lookup table.

Yeah, although that would need to be a contract between HW and GSP and GSP and
user-space. That's fine, and can could probably do it one day, it just doesn't
currently exist AFAICT.

 - Alistair