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

On 2026-09-04 at 22:08 +1000, Danilo Krummrich [off-list ref] wrote...

On Fri Sep 4, 2026 at 1:13 PM CEST, Gary Guo wrote:

quoted

You mentioned in an earlier email about the typing, but we could still have
meaningful impl IDs fully typed like this:

    pub enum Arch {
        Turing(impl_id),
        Ampere(impl_id),
        ...
    }

and some langauges can do better, e.g. TypeScript allow you to write

    enumn ArchId {
        Turing,
        Ampere,
        ...
    }

    enum TuringImplId { ... }
    enum AmpereImplId { ... }

    type Id =
        { arch: ArchId.Turing, impl: TuringImplId } |
        { arch: ArchId.Ampere, impl: AmpereImplId };

So I think it's a reasonable design to have it.

Of course we could encode this implementation detail, but I think there's no
reason to do so.

For instance currently we refer to GA100 as

	Chipset::GA100

but with the above we'd refer to GA100 as

	Arch::Ampere(AmpereImpl::GA100)

which is not buying us anything, is it?

It also would be confusing because both the architecture and the specific chip
would now be both represented by a type called Arch.

quoted

True, but I think the chip ID is as bad as impl ID. Feature detections should
use dedicated featuire detection mechanism, not looking up IDs directly. I.e. we
should have userspace not having to use either chip ID or impl ID as much as we
can.

Yes, I agree this would be quite lovely for a whole host of reasons. But both
our HW and our FW are a long long way from being able to do that so I don't
think it's really feasible as of now.

This I agree with, which is also why I mentioned we should export SM if GSP
already provides it to us.

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

quoted

That said, I do think looking up tables are unavoidable, for getting names or
applying some quirk fixes. And I agree with Alistair that if we include it,
including impl ID is better than the chip ID, as we should rather not having
user space relying on an arbitrary encoded chip ID.

Yep. Sadly without better capability mechanisms I can't see how we're going to
avoid lookup tables in user-space. If we had better capability mechanisms maybe
we could, but we don't.

No, the only thing userspace ever uses to distinguish between things is either
by architecture or by chip. If we instead provide architecture and some ID
userspace will just go

	if (arch == Ampere && id == 0)
		chip = GA100;
	else if (arch == Ampere && id == 2)
		chip = GA102;
	[...]

and after that never care about the ID again. Whereas with giving userspace the
chip and architecture as separate fields userspace is done.

Right. That's because what user-space needs and wants is the chip-id so it
can figure out the exact ISA, among other properties.

 - Alistair