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

[M Henning]

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. They correspond to either the shader isa or
which class methods are available, which are what it relevant for the
related code. Most of the checks don't look like those functions
you've pasted above. Most checks look something like `self.sm.sm() >=
86` or `info->cls_eng3d < MAXWELL_B`, which is to say that a
completely opaque enum isn't practical for our purposes. We typically
need to check if we're before or after the point where a specific
feature was added or removed.

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