On 09.08.2023 09:38, Hongtao Liu wrote: > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich <jbeul...@suse.com> wrote: >> >> On 09.08.2023 04:14, Hongtao Liu wrote: >>> On Wed, Aug 9, 2023 at 9:21 AM Hongtao Liu <crazy...@gmail.com> wrote: >>>> >>>> On Wed, Aug 9, 2023 at 3:55 AM Joseph Myers <jos...@codesourcery.com> >>>> wrote: >>>>> >>>>> Do you have any comments on the interaction of AVX10 with the >>>>> micro-architecture levels defined in the ABI (and supported with >>>>> glibc-hwcaps directories in glibc)? Given that the levels are cumulative, >>>>> should we take it that any future levels will be ones supporting 512-bit >>>>> vector width for AVX10 (because x86-64-v4 requires the current AVX512F, >>>>> AVX512BW, AVX512CD, AVX512DQ and AVX512VL) - and so any future processors >>>>> that only support 256-bit vector width will be considered to match the >>>>> x86-64-v3 micro-architecture level but not any higher level? >>>> This is actually something we really want to discuss in the community, >>>> our proposal for x86-64-v5: AVX10.2-256(Implying AVX10.1-256) + APX. >>>> One big reason is Intel E-core will only support AVX10 256-bit, if we >>>> want to use x86-64-v5 accross server and client, it's better to >>>> 256-bit default. >> >> Aiui these ABI levels were intended to be incremental, i.e. higher versions >> would include everything earlier ones cover. Without such a guarantee, how >> would you propose compatibility checks to be implemented in a way > Are there many software implemenation based on this assumption? > At least in GCC, it's not a big problem, we can adjust code for the > new micro-architecture level. >> applicable both forwards and backwards? If a new level is wanted here, then >> I guess it could only be something like v3.5. > But if we use avx10.1 as v3.5, it's still not subset of > x86-64-v4(avx10.1 contains avx512fp16,avx512bf16 .etc which are not in > x86-64-v4), there will be still a diverge.
Hmm, yes. But something will end up being odd in any event. Versions no longer being integral values is kind of indicating a "branch", i.e. v4 not being a successor. Maybe v3.1 would be better, for it to then have possible successors v3.2, v3.3, etc. Of course it would be possible to "merge" branches back then, into e.g. v5 covering AVX10.2/512 (and thus fully covering everything that's in v4). Jan > Then 256-bit of x86-64-v4 as v3.5? that's too weired to me. > > Our main proposal is to make AVX10.x as new micro-architecture level > with 256-bit default, either v3.5 or v5 would be acceptable if it's > just the name.
