Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

On 2026-08-25 at 05:24 +1000, Danilo Krummrich <[email protected]> wrote...
> On Mon Aug 24, 2026 at 4:49 PM CEST, M Henning wrote:
> > On Tue, Aug 11, 2026 at 1:12 AM Alistair Popple <[email protected]> wrote:
> >> +/*
> >> + * Opaque chipids. These may be used to determine what chip a particular GPU is
> >> + * based on the identifier but the values themselves should not be assumed to
> >> + * carry any particular meaning.
> >> + */
> >
> > You say this is opaque, but the userspace MR you posted already treats
> > the values as non-opaque in eg. sm_for_chipset.
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352/diffs?commit_id=945a8e7c51939577526974b342c8dc6bafc3372f
> > So, I guess my question is, is is opaque or not?
> 
> The PR is outdated and goes back to the first version of this patch series;
> what's written here is correct.

Right - I was holding off on updating the PR until we'd settled on the UAPI
here.

> > I don't see much of a reason to make it opaque since the chipset has
> > had the same structure on the hardware level for 30 years, so I don't
> > expect it to change too often. Truly treating this as opaque would
> > likely require a small refactor on the userspace side without much
> > value. (I realize this has already been discussed a bit on the
> > previous version.)
> 
> I don't see much value in having userspace decode this value (again) after the
> kernel did it already and can easily provide the required information without
> making userspace commit to some encoding in the hardware (even though I do agree
> that it is unlikely).
> 
> OTH, the way chip IDs are derived has changed over the years (BOOT_0 / BOOT_42
> with different register layouts), and I'd rather not have userspace commit to
> any particular encoding when the kernel already provides the decoded
> information.
> 
> Regarding the refactor in mesa, the Nova uAPI won't follow nouveau anyway, so I
> don't want to limit ourselfs here.

I'm not particularly wedded to either approach but I think the approach is
either:

1) Keep the chip_id opaque, user-space looks up arch/implementation/etc. from a
   lookup table as required.

2) Keep the current scheme of just exposing the chip_id and letting user-space
   decode it assuming the register layout won't change.

In either case user-space needs to figure out arch/implementation/etc.

For (1) the kernel should not be responsible for decoding arch because if you're
assuming the register layout can change arbitrarily then the it can't reliably
figure out the arch anyway. For example if someone plugs a shiny new card with
a different chip_id register layout into a machine running an older kernel they
could get an incorrect arch which would be confusing. Users would get upset if
for example ShinyNewCard got reported as being Turing say.

So I think it makes sense to keep this decoding in user-space regardless of
whether that's exposed via documented opaque chip IDs and lookup tables for
arch/implementation or by a commitment to keep the chip ID register layout the
same.

Either of 1 or 2 seems fine to me.

 - Alistair