[PATCH v2] drm/xe/uapi: Expose SIMD16 EU mask in topology query

[Lucas De Marchi]

On Fri, Jul 26, 2024 at 04:00:22PM GMT, Jordan Justen wrote:
>On 2024-07-18 15:32:47,  wrote:
>> On Tue, Jul 16, 2024 at 06:39:26PM GMT, Jose Souza wrote:
>> >> humn... if we decide to set both for backward compatibility, why not
>> >> rather go with v1 of the patch?  v1 of the patch documents that the EU
>> >> reported in EU_PER_DSS is of type X. Having both masks here doesn't
>> >> answer that question and requires that we always convert back to the
>> >> simd8 number (and eventually to the simd16 number) for newer platforms.
>> >>
>> >> so suppose 5 years from now we have simd123 (using arbitrary/absurd name
>> >> on purpose to avoid people jumping to conclusions):  would we keep
>> >> exposing the simd8, simd16, simdX, fooY numbers for the sake of
>> >> backward compatibility with previous HW?  On the other hand, the
>> >> alternative means: if userspace X really supports platform Y, it has to
>> >> know about that type of EU if it's using that mask for anything.
>> >>
>> >> So my preference would be, in order:
>> >>
>> >> 1) v2
>> >> 2) v1
>> >> 3) v2-with-forever-bc-between-platforms
>> >>
>> >> Both (2) and (3) have the silent misbehavior in userspace if userspace
>> >> didn't adapt to new UAPI.
>> >
>> >option 1) v2 is better in my opinion.
>>
>>
>> great. I fixed a typo in the kernel-doc, added a few more
>> Acked-by's received offline and pushed to drm-xe-next.
>>
>> [1/1] drm/xe/uapi: Expose SIMD16 EU mask in topology query
>>        commit: 7108b4a589cd6d3a2c1276fd610b3500f46de66a
>
>Mesa 24.2.0 will support LNL using only DRM_XE_TOPO_EU_PER_DSS, since
>this new uapi is not in the upstream drm tree.
>
>After this change, Mesa 24.2.0 will be broken on LNL. Isn't this the
>sort of breakage that the kmd is supposed to avoid for platforms in
>the upstream drm tree?
>
>Unless this uapi can be added to the upstream drm tree before Mesa
>24.2.0 (August 7th), I think LNL should advertise either
>DRM_XE_TOPO_EU_PER_DSS only, or both.

We have been through this discussion a couple times. It's just the
enabling for a new platform under force_probe. I had commented on that
in the relavant mesa MR, but forgot to click the button "submit review".
I just did. See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30127

There's no support really in kernel 6.10, 6.11 etc to LNL. There will be
in 6.12 and distros wanting to support earlier version may bring the
needed patches back as backport, which includes this.

When we can support a new platform with the existing uapi we do, but in
this case we needed this introduce a new one.

We don't advertise both simd8 and simd16 because the platform doesn't
have both. What happens if it did?  Also in future there may not be a
1:1 conversion from one type of the EU to another, so requiring the
kernel to convert it for compatibility with previous platforms is not
very future-proof.

We can't advertise only DRM_XE_TOPO_EU_PER_DSS because then when we do
support the platform for real, we wouldn't be able to change it anymore
due to having a stable uabi.


Lucas De Marchi

>
>-Jordan