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

["Danilo Krummrich" <dakr@kernel.org>]

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?

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.

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

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.

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