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

[M Henning]

On Tue, Sep 8, 2026 at 12:57 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> 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.)

I guess my point is that the entire compiler uses SMs everywhere. It
largely only knows what sm you're running. The is_blackwell()
functions are helper functions and are not typical of most checks in
the compiler. I don't consider this "two unnecessary indirections" and
I think the code you quoted is fine.