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

[Alistair Popple <apopple@nvidia.com>]

On 2026-08-25 at 17:13 +1000, Alistair Popple <apopple@nvidia.com> wrote...
> On 2026-08-25 at 05:24 +1000, Danilo Krummrich <dakr@kernel.org> 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 <apopple@nvidia.com> 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).

Userspace has to commit to some kind of encoding about HW though. If we're going
to assume everything and anything about HW can change there's also no reason to
assume HW would continue using a chip architecture and a chip implementation as
having any meaning at all.

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

On the other hand we don't need to ignore the lessons of Nouveau either and try
and refactor everything - I agree there are plenty of UAPI choices that should
and will be different and we shouldn't limit ourselves - but if an interface has
been working well for 30 years and hasn't been causing anyone any issues then
perhaps we should just stick with it for Nova as well?

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

Thinking about this some more I think I conflated the architecutre and
implementation a bit. A new arch would _probably_ require other driver changes
anyway, so perhaps my example is a little contrived. The point I was trying to
make was that requiring backporting of kernel patches and forced driver upgrades
just to get a new impl (or maybe arch) decoding would be unfortunate.

We may well never get to the point of being able to have a (slightly) older
driver support a new impl, but I still think it would be best not to bake that
requirement in.

> 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