I conducted some tests using triton on v100, as shown in the figure. In the first piece of code of the kernel, most of the warps were stall due to not select, but this phenomenon did not occur later. Why is that? Is it because when a scheduler selects a warp in one segment, there is a high probability that it will continue to select that warp?
It is very hard to provide detailed information back to you without the full report so we can look at the active warps per SM, the instruction mix, and the type of dependencies.
When a thread block (CTA) is launched the warps are all at the same instruction range for a period of time. The warp scheduler is not round robin. As cycles pass the warps start to spread out over more address ranges which results in (a) warps requiring a larger selection of pipelines resulting in less math_throttle, and (b) warps starting to hit longer stalls such as for long_scoreboard.
In the first 100 cycles all of the warps of vying for the same pipelines. This is why you see backups on MUFU. I can’t tell why you see such a backup on IMAD without resolving the dependencies.
mamba2__selective_scan_update_kernel_250_full.zip (145.3 KB)
Thank you for your answer much. This is the full report.
In my understanding, if each warp has an equal chance of being scheduled, the ratio of not selected to selected should be the number of active warps for each scheduler. Also, I would like to ask if each pipe can receive one instruction per cycle.