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

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.

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