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

[Danilo Krummrich]

On Tue Sep 8, 2026 at 4:48 PM CEST, M Henning wrote:
> On Thu, Sep 3, 2026 at 6:42 AM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>> 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.
>
> Userspace mostly uses sm id and engine id for feature checks, and I'd
> like to keep it that way.

Please note that I did not ask to change any of that in the context of
chipset/architecture enums.

What I said is that I don't want to incentivise userspace to derive the
architecture of a chip on its own, given that the kernel already does this. (If
it is never needed, that's fine too, then we don't need to export it. :)

Of course, architecture and engine class id can't be used interchangeably. The
engine class id is more fine grained. For instance, the engine class id is
different for GA100 compared to all other Ampere chips.

At a quick glance the code above looked to me as if it doesn't care about the
engine class id, because the granularity is architecture granularity and not
engine class id granularity. But at a second glance, I think you are actually
deriving the engine class id and it just happens that the code does not need to
consider e.g. AMPERE_A vs. AMPERE_B, which is why you don't have an
is_ampere_{a,b}() accessor I suppose.

That said, nova can easily export the engine class id information instead of the
architecture; the kernel will likely need the engine class id anyway. (Although
it depends a bit on the GSP-RM API, I think technically it could get away
without the driver passing it in.)

>> 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.
>
> As others have stated, the sm ids reported by firmware don't always
> match the sm ids documented in cuda-related materials. and nvk follows
> the cuda conventions here.

Yes, Alistair confirmed this too:

	Yes, I did look into this. Unfortunately the SM version GSP currently
	reports is different from the SM userspace code generation tools need (I
	have no idea why, there appear to be way too many SM versions).

However, I don't think we have to just give up on all this. We have NVIDIA
people working on the project and firmware changes are made specifically for the
project already. So, ultimately I think it would be great to understand why that
is and possibly provide the correct information.