[API Proposal]: Revisit Avx10v2.V512 decision

[colejohnson66]

Background and motivation

Intel has recently backtracked on their "512-bit is optional" decision for AVX10.2. Likely because AMD forced their hand. In other words, going forward, all "E" cores on AVX10.2 chips will support 512-bit vectors.

Given this, the Avx10v2.V512 class from #109083 should be subsumed up into the base Avx10v2 class.

API Proposal

Delete Avx10v2.V512 (and nested Avx10v2.V512.X64) classes, then move the Avx10v2.V512 methods up into Avx10v2:

namespace System.Runtime.Intrinsics.X86;

public abstract class Avx10v2 : Avx10v1
{
    // VMINMAXPD zmm1{k1}{z}, zmm2, zmm3/m512/m64bcst {sae}, imm8
    public static Vector512<double> MinMax(Vector512<double> left, Vector512<double> right, [ConstantExpected] byte control) => MinMax(left, right, mode);

    // VMINMAXPS zmm1{k1}{z}, zmm2, zmm3/m512/m32bcst {sae}, imm8
    public static Vector512<float> MinMax(Vector512<float> left, Vector512<float> right, [ConstantExpected] byte control) => MinMax(left, right, mode);

    // VCVTPS2IBS zmm1{k1}{z}, zmm2/m512/m32bcst {er}
    public static Vector512<int> ConvertToByteWithSaturationAndWidenToInt32(Vector512<float> value) => ConvertToByteWithSaturationAndWidenToInt32(value);

    // VCVTPS2IBS zmm1{k1}{z}, zmm2/m512/m32bcst {er}
    public static Vector512<int> ConvertToByteWithSaturationAndWidenToInt32(Vector512<float> value, [ConstantExpected(Max = FloatRoundingMode.ToZero)] FloatRoundingMode mode) => ConvertToByteWithSaturationAndWidenToInt32(value, mode);

    // VCVTPS2IUBS zmm1{k1}{z}, zmm2/m512/m32bcst {er}
    public static Vector512<uint> ConvertToByteWithSaturationAndWidenToUInt32(Vector512<float> value) => ConvertToByteWithSaturationAndWidenToUInt32(value);

    // VCVTPS2IUBS zmm1{k1}{z}, zmm2/m512/m32bcst {er}
    public static Vector512<uint> ConvertToByteWithSaturationAndWidenToUInt32(Vector512<float> value, [ConstantExpected(Max = FloatRoundingMode.ToZero)] FloatRoundingMode mode) => ConvertToByteWithSaturationAndWidenToUInt32(value, mode);

    // VCVTTPS2IUBS zmm1{k1}{z}, zmm2/m512/m32bcst {sae}
    public static Vector512<int> ConvertToByteWithTruncatedSaturationAndWidenToInt32(Vector512<float> value) => ConvertToByteWithTruncatedSaturationAndWidenToInt32(value);

    // VCVTTPS2IUBS zmm1{k1}{z}, zmm2/m512/m32bcst {sae}
    public static Vector512<uint> ConvertToByteWithTruncatedSaturationAndWidenToUInt32(Vector512<float> value) => ConvertToByteWithTruncatedSaturationAndWidenToUInt32(value);

    // VMPSADBW zmm1{k1}{z}, zmm2, zmm3/m512, imm8
    public static Vector512<ushort> MultipleSumAbsoluteDifferences(Vector512<byte> left, Vector512<byte> right, [ConstantExpected] byte mask) => MultipleSumAbsoluteDifferences(left, right, mask);
}

API Usage

No response

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

It's not that simple since we have shipped Avx10v1 in stable state, with V512 nested class and optional support.

[saucecontrol]

512-bit was mandatory in AVX10.1 as well -- it's a strict superset of AVX-512 (or at least of the subset of AVX-512 they felt like supporting 😅). The nested V512 classes were designed around the expected changes in AVX10.2.

[colejohnson66]

AVX10.1 was specced as both AVX10.1/256 and AVX10.1/512. It's just that the only shipping chips are Granite Rapids, which uses "P" cores only, so they have AVX10.1/512. No chips with AVX10.1/256 exist AFAIK.

Theoretically, Avx10v1.V512 could be obsoleted and subsumed/copied into the base Avx10v1, but that's ugly. Another strike against the wonky inheritance style trying to force a linear evolution that doesn't exist.

The split can be kept is desired. I just figured it should be discussed/revisited based on Intel's new design. It doesn't make sense (to me) for a feature with no necessary "is supported" check to be kept separate with its own "is supported" flag. Because with Intel's new design, Avx10v2.V512.IsSupported will always be the same as Avx10v2.IsSupported.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[tannergooding]

This is being discussed internally still -- CC. @anthonycanino

I expect we're going to keep the V512 split. This makes it more consistent, makes it easier to have lightup for non-AVX512 capable hardware where ISAs have been backported, etc

We will be needing to remove the APIs that added various YMM based embedded rounding support, however.