[DOC] Need clarity on SGV Layout in new Xe re-architecture

[sspintel]

Hi, I have several questions relating to the Copy Atoms. Opened this issue to seek clarification about them

1/

From this representation, I could understand that this 8x4 block load needs 2 subgroups of 16 threads to operate. However, it's confusing what the indices in the "Subgroup View" represent. If they stand for the linear indices for that block in memory, I don't get why it is called a Subgroup View.

2/
Are there any utilities to visualize SG-V partitioning similar to the tools to visualize TV partitioning in CuTe?

3/
Under the "Subgroup Scope and Thread-Local Data" section of the Xe-rearch documentation:

DPAS and block 2D copy atoms are subgroup operations, meaning that all 16 threads of the subgroup collectively execute these operations, and collectively own all input/output data.

If we take a block 2d copy operation like XE_LOAD_2D_TRANSPOSE of bits 32, height 32, and width 8, it is not immediately clear to me if it gets executed by a single work-item or a single sub-group or multiple sub-groups. If we go by the logic in the example above, then we have 32x8 = 256 elements to copy and we should need 256/16 = 16 sub-groups, where each work-item handles loading of 16 elements, is that so?

cc @petercad @mkumargarg

[petercad]

@sspintel On your questions:

From this representation, I could understand that this 8x4 block load needs 2 subgroups of 16 threads to operate

Block 2D copies are a single-subgroup operation. So there is 1 subgroup of 16 threads/work-items, each "owning" 2 values.

However, it's confusing what the indices in the "Subgroup View" represent. If they stand for the linear indices for that block in memory, I don't get why it is called a Subgroup View.

Yes, I should expand the documentation to make it more clear. The Subgroup View shows all the data that the entire subgroup owns. The idea here is that the subgroup owns 32 values, enumerated in the order shown. These indices represent the order of elements in registers. (Recall that Intel GPUs have no notion of a "register owned by a thread". Registers belong to subgroups, because it is a SIMD architecture.)

From there, we now split the subgroup into its 16 threads/work-items and distribute these 32 values between then. Thread 0 gets subgroup values 0 and 16. Thread 1 gets subgroup values 1 and 17, etc.

Are there any utilities to visualize SG-V partitioning similar to the tools to visualize TV partitioning?

These layouts are TV-layouts, so you can use the existing visualization tools.

If we take a block 2d copy operation like XE_LOAD_2D_TRANSPOSE of bits 32, height 32, and width 8, it is not immediately clear to me if it gets executed by a single work-item or a single sub-group or multiple sub-groups. If we go by the logic in the example above, then we have 32x8 = 256 elements to copy and we should need 256/16 = 16 sub-groups, where each work-item handles loading of 16 elements, is that so?

Every block 2D copy and DPAS operation is executed by a single sub-group, so in your example you have one sub-group, and each work-item owns 256/16 = 16 elements.