The Triton XPU compiler retry to compile kernel with the different GRF mode if there was register spilling.
But it is hard coded with 128 and 256 GRF which doesn't make sense to CRI.
As the discussion with the IGC team, it is recommanded to use the auto-grf mode from IGC scalar backend.
We need to align the design with the IGC team for the auto GRF mode for CRI for those aspect:
- The GRF mode impacts the max number of sub groups with in a work group. The Triton need to annotate the number of sub-groups of the kernel to IGC to skip invalid GRF mode. (SPV attribute for
required_sub_group_number?)
- Need to make sure whether the default GRF mode is
auto or 128.
- Need to make sure the spill retry mechanism in Triton XPU now doesn't conflict it with IGC logic.
Note for 1: It is a not a common configuration of threadsPerWarp=16 and num_warps=32 used at
|
num_stages=s, num_warps=w) for s in [2, 3, 4] for (m, w) in ([('256', 32), ('128', 64)]) |
Maybe we can forbid to use num_warps > 32 to avoid the bugs.
The Triton XPU compiler retry to compile kernel with the different GRF mode if there was register spilling.
But it is hard coded with 128 and 256 GRF which doesn't make sense to CRI.
As the discussion with the IGC team, it is recommanded to use the auto-grf mode from IGC scalar backend.
We need to align the design with the IGC team for the auto GRF mode for CRI for those aspect:
required_sub_group_number?)autoor128.Note for 1: It is a not a common configuration of
threadsPerWarp=16andnum_warps=32used atintel-xpu-backend-for-triton/benchmarks/triton_kernels_benchmark/gemm_benchmark.py
Line 29 in 35379ed
Maybe we can forbid to use
num_warps > 32to avoid the bugs.