There was a recent(?) example of muddling with units similarly, getting sued and losing the suit. Many had argued for years that it was just people not understanding the brilliance of Bulldozer sharing resources between cores... Though I cannot and will not attest to how much this is applicable to the situations with these SIMT lanes.
If this is the basis of “as confusing as Ampere”, GCN/RDNA do not even have a separate integer SIMD ALU pipeline to co-issue to…
If this is the basis of “as confusing as Ampere”, GCN/RDNA do not even have a separate integer SIMD ALU pipeline to co-issue to…
www.freepatentsonline.com
static const std::array<const char *, 12> InstIds = {
"NO_DEP", "VALU_DEP_1", "VALU_DEP_2",
"VALU_DEP_3", "VALU_DEP_4", "TRANS32_DEP_1",
"TRANS32_DEP_2", "TRANS32_DEP_3", "FMA_ACCUM_CYCLE_1",
"SALU_CYCLE_1", "SALU_CYCLE_2", "SALU_CYCLE_3"};
[...]
static const std::array<const char *, 6> InstSkips = {
"SAME", "NEXT", "SKIP_1", "SKIP_2", "SKIP_3", "SKIP_4"};delay VALU_DEP_3, SKIP_2, VALU_DEP_1delay VALU_DEP_4, NEXT, NO_DEPMight be a bit far fetched, but it reminds me of Bulldozer which supports -1 clk in latency with special bypass mode for consecutive FMA instructions (i.e., takes 5 clk instead of 6).
Where FMA instruction 1's result is consumed by FMA 2 as an operand, presumably as the addend?
fma r0, r1, r2, r3
delay FMA_ACCUM_CYCLE_1, SKIP_1, FMA_ACCUM_CYCLE_1
fma r0, r4, r5, r0
fma r0, r6, r7, r0
[etc]Figure 3 in the patent document makes this explicit, in my opinion.
SALU instructions are always a single cycle, aren't they?
The scalar ALU pipeline itself is probably single cycle execution with 1 extra stage for writeback (or a dest cache like VRF), but the results might not be ready in some edge cases with special scalar registers. MI200/GCN ISA manual gives a rough idea of what some of these cases are (in the Manually Inserted NOP section), which are all currently managed by hardware scoreboarding on RDNA 1/2.
So it seems to me that a VALU instruction of four clocks can be delayed from 1 to 3 clocks by specifying SALU_CYCLE_x and correspondingly a FMA_ACCUM_CYCLE_1 requires a 1 clock delay. I suppose the use of the CYCLE keyword implies that instruction issue occurs on the basis that an in-flight operand will be delivered in time for the referenced cycle, so the hardware knows that an operand is in flight, as opposed to DEP which specifies that an instruction has completed and so nothing is in flight.
So I'm wondering whether all previous cases of variable latency for LDS operations have been eliminated in RDNA 3.
LDS Direct Read is not new to RDNA3. It allows one dword (32-bit value) at the LDS offset held by the M0 register to be always available as a uniform/scalar operand to the VALU.
Are you suggesting that the second SIMD in Super SIMD is for 13 (or 16) instructions only? That would mean this second SIMD would be idle quite a lot.⚙ D128218 [AMDGPU] gfx11 VOPD instructions MC support
reviews.llvm.org
Looks like VOPD supports only co-issuing the core f32 instructions (add/mul/fma/etc) plus a few utility instructions (see: VOPDXPseudos and VOPDYPseudos), or in other words 16x13 combinations.
No co-issuing for integer things and packed maths...
The interesting bit is that patents were indicating potentially supporting single-cycle wave64 execution as well. Does this mean only this same subset of 13 instructions will be executed single-cycle in wave64 mode?
It seems vertex shaders (geometry, in general) are typically issued in wave32 mode, similarly compute shaders, while wave64 is primarily for pixel shaders.
I think there are two branches of possibilities…
| The 2nd ALU pipeline does only the listed 13 instructions. | There will be Wave64 single-cycle execution, but only for these 13 instructions. |
| The 2nd ALU pipeline does only the listed 13 instructions. | Wave64 remains double issuing over 2 cycles |
| The 2nd ALU pipeline does only the listed 13 instructions. | The second ALU pipeline is dynamically shared between the two SIMDs in a CU (!???!??!) |
| Both ALU pipelines are (mostly?) symmetrical. |
|
// TODO: In wave64 mode, double the number of cycles for VALU and VMEM
// instructions on the assumption that they will usually have to be issued
// twice? ; CHECK-LABEL: {{^}}valu_dep_1_same_trans32_dep_1:
; CHECK: %bb.0:
; CHECK-NEXT: v_exp_f32_e32 v0, v0
; CHECK-NEXT: v_add_nc_u32_e32 v1, v1, v1
; CHECK-NEXT: s_delay_alu instid0(TRANS32_DEP_1) | instid1(VALU_DEP_1)
; CHECK-NEXT: v_add_nc_u32_e32 v0, v0, v1# There's no need for SALU_CYCLE_2 here because the s_mov will have completed
# already.
[...]
; CHECK-LABEL: {{^}}salu_cycle_2:
; CHECK: %bb.0:
; CHECK-NEXT: s_mov_b32 s0, 0
; CHECK-NEXT: v_add_nc_u32_e32 v1, v1, v1
; CHECK-NEXT: v_add_nc_u32_e32 v0, s0, v0; GCN: ; %bb.0: ; %main_body
; GCN-NEXT: s_mov_b32 s3, exec_lo
; GCN-NEXT: s_wqm_b32 exec_lo, exec_lo
; GCN-NEXT: s_mov_b32 m0, s2
; GCN-NEXT: lds_param_load v1, attr0.x wait_vdst:15
; GCN-NEXT: s_mov_b32 exec_lo, s3
; GCN-NEXT: v_mov_b32_e32 v0, s0
; GCN-NEXT: v_mov_b32_e32 v2, s1
; GCN-NEXT: s_delay_alu instid0(VALU_DEP_2) | instskip(SKIP_1) | instid1(VALU_DEP_2)
; GCN-NEXT: v_interp_p10_f16_f32 v3, v1, v0, v1
; GCN-NEXT: v_interp_p10_f16_f32 v0, v1, v0, v1 op_sel:[1,0,1,0] wait_exp:7
; GCN-NEXT: v_interp_p2_f16_f32 v3, v1, v2, v3 wait_exp:7
; GCN-NEXT: s_delay_alu instid0(VALU_DEP_2) | instskip(NEXT) | instid1(VALU_DEP_1)
; GCN-NEXT: v_interp_p2_f16_f32 v0, v1, v2, v0 op_sel:[1,0,0,0] wait_exp:7
; GCN-NEXT: v_add_f16_e32 v0, v3, v0
; GCN-NEXT: ; return to shader part epilogI'd like to add a third: TRANS ALU seems to be very high in its throughput, seemingly 3 cycles, which implies it's 32 lanes I reckon. Add a fourth cycle and it can become the second VALU.
