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

[Jordan Justen]

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.

-Jordan