clearnature wrote:
@Malexandra-de SWMMAC and VALU share the same issue slot — that much is correct per
the ISA documentation. However, our scheduling model does not assume
VALU instructions execute concurrently with SWMMAC. It describes the
total occupancy of the ALU pipeline while a SWMMAC instruction is in
flight.
The key distinction:
Instruction-level overlap (wrong): SWMMAC + VALU execute in parallel
Wave-level staggering (correct): SWMMAC occupies XDL for N cycles;
other wavefronts fill ALU slots during
that window
Our latency table assigns HWVALU occupancy to WMMA instructions because
the ALU issue slot is blocked for the duration of the SWMMAC — it cannot
issue another VALU in the same wave. The scheduler uses this information
to stagger wavefronts: while wave A's SWMMAC holds the XDL pipeline,
wave B's independent VALU work fills the otherwise-idle ALU slots.
This is why K9 achieves 4326 TOPs vs the baseline 518 TOPs — not from
instruction-level parallelism, but from the scheduler knowing how long
the ALU slot is unavailable per wave and filling it with work from other
waves.
The HWXDL entries alone (which gfx1250 already has) only describe the
matrix pipeline. The HWVALU entries describe the ALU pipeline occupancy
that prevents the same wave from dual-issuing — which is exactly what
the ISA describes as "hardware may stall."
https://github.com/llvm/llvm-project/pull/202093