On Tue, Sep 8, 2026 at 12:57 PM Danilo Krummrich <[email protected]> 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 <[email protected]> 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.
