Anon (no.delete@this.spam.com) on July 23, 2020 12:53 pm wrote:
> m (m.delete@this.bitsnbites.eu) on July 23, 2020 12:10 pm wrote:
> > Would it make sense to make the AVX512 instruction set available
> > on cores with narrower execution units (128- or 256-bit wide)?
>
> One have to make a lot of concessions to support AVX-512, first, it have more than 4 times
> the state of AVX-256, not just twice as was the case of previous x86 SIMD extensions, second,
> masking, on a non-destructive instruction format masking means going from 2 source operands
> to 4, good luck with your scheduller, third, gather/scatter/permute are hard to implement on
> smaller execution units, a very important class of instructions, but hard to implement.
>
> So, if someone goes and pays the price to implement AVX-512 he will likely prefer to
> go the full width at once, too much effort to not have the full implementation.

Narrower execution would facilitate the use of banking to reduce the number of register file ports (GPU register files can be single ported because four times the execution width of sources can be read each cycle), which would reduce the area cost.

In targeting lower performance, there are other simplifications that could reduce the cost of the extra state. (Limiting register renaming could also reduce the state overhead. With narrower execution, data level parallelism would provide some of the benefits of more extensive out-of-order execution discovering instruction level parallelism.)

The extra state could also be used for checkpointing or multithreading when full width SIMD storage is underutilized.

There is also the issue of thermal throttling. Narrower execution might provide some design benefits in this regard.

"too much effort to not have the full implementation" is a strong argument, especially when adding marketing factors. The pressure to support AVX-512 outside of high SIMD performance targets seems modest; scatter/gather and predication are nice and having a single functionality target is nice, but a lot of software does not seem to care. AVX-256 may be "good enough" for a lower performance implementation.