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

[Alistair Popple <apopple@nvidia.com>]

On 2026-09-04 at 22:08 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Fri Sep 4, 2026 at 1:13 PM CEST, Gary Guo wrote:
> > 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.
> 
> > 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).

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