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

On Tue, Sep 8, 2026 at 12:57 PM Danilo Krummrich [off-list ref] wrote:

On Tue Sep 8, 2026 at 4:48 PM CEST, M Henning wrote:

quoted

On Thu, Sep 3, 2026 at 6:42 AM Danilo Krummrich [off-list ref] wrote:

quoted

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.