[PATCH v2] x86: Add support for AVX10 version and vec size in cpu-features

Noah Goldstein goldstein.w.n@gmail.com
Fri Aug 25 17:39:11 GMT 2023


On Fri, Aug 25, 2023 at 2:12 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Noah Goldstein via Libc-alpha:
>
> > +/* AVX10 version information is handled differently from all other CPUID
> > +   related logic.  Rather than being encoded in cpuid as discrete booleans, the
> > +   AVX10 version is encoded is a full byte that represents the version number
> > +   (greater than or equal to 1).  Since the CPUID API is only able to handle
> > +   boolean returns, we enumerate `x86_cpu_AVX10_V{1..255}` which can be queried
> > +   by the user and have special logic in `x86_cpu_{present,active}`.  This is
> > +   unpleasant on our end, but is the only way to make the existing API also
> > +   support version queries.  */
> > +
> > +  /* All 1s should never be a value feature index.  */
> > +  x86_cpu_AVX10_V255 = ~0,
> > +  x86_cpu_AVX10_V254 = x86_cpu_AVX10_V255 - 1,
> > +  x86_cpu_AVX10_V253 = x86_cpu_AVX10_V254 - 1,
> > +  x86_cpu_AVX10_V252 = x86_cpu_AVX10_V253 - 1,
> > +  x86_cpu_AVX10_V251 = x86_cpu_AVX10_V252 - 1,
>
> Is this really necessary?  We can define an x86_cpu_avx10_version inline
> function that calls __x86_get_cpuid_feature_leaf and extracts the
> version byte.  Is it really necessary to support something like this?
>

I agree it's not the best API. My feelings are two fold on this.
1) The existing API that users know should support the feature, even if its
not the best way for users query the logic. Adding support for specific version
queries in CPU_FEATURE_{ACTIVE,PRESENT} doesn't prevent us from
adding an API that allows for querying the full byte. But only adding the byte
might be disruptive to users that expect to be able to do all their querying
through the existing API.
2) For a lot of use cases, this is sufficient. Currently we only have
two versions
and I think the common use case is not "is feature above level X?",
but "do I have
feature X?". The latter can reasonably be supported with a single query of:
CPU_FEATURE_{ACTIVE,PRESENT}(AVX10_<MIN_VERSION_WITH_X>).

>   CPU_FEATURE_ACTIVE (AVX10_V2)
>
> This would be the alternative:
>
>   x86_cpu_avx10_version () >= 2
>
We do plan to propose a new byte API in a follow up :)

> Let's hope that version 0 means no AVX10. 8-)
>
versions start at 1.



> Thanks,
> Florian
>


More information about the Libc-alpha mailing list