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

[Alistair Popple]

On 2026-09-02 at 03:01 +1000, Danilo Krummrich <dakr@xxxxxxxxxx> wrote...
> On Tue Sep 1, 2026 at 12:38 PM CEST, Danilo Krummrich wrote:
> > On Fri Aug 28, 2026 at 5:35 AM CEST, Alistair Popple wrote:
> >> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> >> index 0c12ef145981..740466af268d 100644
> >> --- a/drivers/gpu/nova-core/gpu.rs
> >> +++ b/drivers/gpu/nova-core/gpu.rs
> >> @@ -138,6 +138,11 @@ pub(crate) const fn arch(self) -> Architecture {
> >>          }
> >>      }
> >>  
> >> +    /// Returns the implementation identifier of this chipset.
> >> +    pub(crate) const fn implementation(self) -> u32 {
> >> +        self as u32 & 0xf
> >> +    }
> >
> > I missed this part in my previous reply. Besides being a bit unfortunate that we
> > have to reimplement what boot42.implementation() already gives us, I think the
> > value is not overly useful anyway.
> >
> > I get the intent, architecture and implementation complement each other, but in
> > practice we are not interested in the implementation bits, but either in a
> > unique chip identifier or the architecture.
> >
> > If you look at the nova-core code you will find exactly that, we either check
> > for a specific chip or an architecture and I think userspace will be intersted
> > in the same.
> >
> > So, I think the uAPI should provide the architecture and a unique chip
> > identifier.
> >
> > Before we circle back, I know that the unique chip identifier in nova-core
> > technically contains the architecture for obvious reasons, but my point has
> > always been that we can give the decoded architecture to userspace and not
> > require it to know about and extract it from the chip identifier we consider
> > opaque in the uAPI.

This is why I removed the opaque chip-id. If it's opaque, and the kernel
provides the architecture what information is user-space allowed to derive
about a GPU from the chip-id? Nothing? Everything? Or everything except the
chip architecture?

Nothing seemed like the only reasonable answer, as it's always best to have a
single source of truth and deriving everything except arch seemed odd. But then
architecture alone, as currently defined, isn't sufficient for user-space - it
needs the implementation in some form to derive the compute capabilities of the
GPU amoung other things.

> IOW, we should not think of this in terms of the numbers/values exposed by some
> register. All the users (including nova-core itself) don't really care about the
> values behind the enum, how it composes and how it is related to other values,
> that's just an implementation detail.

Right, the question isn't how this information is encoded but what gurantees
the kernel provide to user-space when it returns a particular architecture,
implementation or chip-id and what assumptions is user-space allowed to make
based on the results.

> All users care about is that they have an architecture and chip identifier to
> compare against. I.e. there's no value letting userspace think of the chip
> identifier as architecture/implementation tuple, since the implementation value
> by itself is rather useless.

Except the architecture/implementation tuple is exaclty what user-space needs to
eg. figure out what SM to compile for.

So yes, the implementation value by itself is rather useless, but so is
the architecture. That doesn't imply that providing it as a seperate value
is useless. I've done some research into our current SW stack to see how
implementation is used today and it's basically used to subclass each GPU.

For example the base arch value is used to fill in a *lot* of static information
about the GPU based on architecture, and then the specific implementation is
used to over-ride or fill in yet more static device information. In fact in
userspace it seems we very rarely look at the architecture in isolation from the
implementation, so in many senses providing an arch value on it's own is also
rather useless.

As a concrete example the way this is currently used, in both CUDA and Mesa, is
a lookup table for arch+impl to figure out eg. what SM version a chip supports.
So having architecture seperately decoded but a chip-id instead of a seperately
decoded implementation would mean user-space just has to look at chip-id for
most things and ignore the architecture anyway.

For example Mesa currently has this to figure out SM version:

static uint8_t
sm_for_chipset(uint16_t chipset)
{
	if (chipset >= 0x1b0)
		return 120;
	else if (chipset >= 0x1a0)
		return 100;
	else if (chipset >= 0x190)
		return 89;
	// GH100 is older than AD10X, but is SM90
	else if (chipset >= 0x180)
		return 90;
	else if (chipset == 0x17b)
		return 87;
	else if (chipset >= 0x172)
		return 86;
	else if (chipset >= 0x170)
		return 80;
	...
}

And to be clear we don't care about the specific encodings in this example. The
point is the SM version can't be looked up from architecture alone, it needs the
implementation as well and if the only way to get that is from opaque chip-id
that's all user-space will look at. Eg:

static uint8_t
sm_for_chipset(enum chip_id chip)
{
	switch (chip) {
		case NOVA_GPU_CHIP_GA100:
			return 80;
		case NOVA_GPU_CHIP_GA101:
			return 86;
		case NOVA_GPU_CHIP_GA102:
			return 86;
		case NOVA_GPU_CHIP_GA10B:
			return 87;
		...
	}
}

So I'm ok with providing either a decoded architecture and implementation
xor an opaque chip-id. Or alternatively maybe architecture includes the
implementation (ie. we rename the opaque chip_id to architecture). But treating
the implementation and architecture values differently and only providing one
directly doesn't make much sense IMHO.

- Alistair