RADV Vulkan Driver Adds Option For Sisched

[phoronix]

Phoronix: RADV Vulkan Driver Adds Option For Sisched

The RADV Vulkan driver now has an option for being able to enable the LLVM SI machine scheduler...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-SISCHED-Flag

[boxie]

now this is rather interesting. I am def interested in this test

[kiffmet]

I thought that all GCN GPUs do have a hardware scheduler. Why is a software scheduler needed in addition to that? Or do they serve a different purpose? If yes, in what aspects do they differ? Please explain it to me as detailed as possible, as I would like to understand this.

[bridgman]

The "scheduler" here is alternative logic in the code generator which re-sequences instructions in the generated code in an attempt to minimize execution time. Probably best place to start is lib/Target/AMDGPU folder in llvm source then looking at any file with "sched" in the name. AFAIK the radv and radeonsi code changes for si_sched just pass a flag to the compiler and then LLVM code does the rest/

The HW schedulers in GCN operate on different time scales - shorter (eg choosing which thread each SIMD should execute the next instruction from) or longer (eg mapping user queues to HW queues in oversubscription scenarios, ie where there are more user queues than the HW ACEs can directly support, or choosing which ACE to launch threads from as thread slots (program counters) become available).

[kiffmet]

Ah I see. So basically speaking the software scheduler tries to avoid things like data hazards (eg why insert a NOP when you can safe a clockcycle by renaming registers), whereas the HW scheduler dispatches the work to the SIMDs and tries to feed them efficiently.

I am an IT student who just finished his first year and the things I've learned until now are very simplified/put out of context. This helps me to better understand how things are implemented in real world scenarios. Thanks for the informative and fast response, Brigdman!

[bridgman]

Take this with a grain of salt, but my (limited) understanding is that the default scheduler takes care of things like data hazards, while the si_sched option tries to give more consideration to things like hiding memory access delays by moving memory read operations ahead in the instruction stream relative to where the results will be used. The problem is that most of these optimizations also increase register usage (which hurts performance in other ways) so the tradeoffs are not simple.

BTW the tradeoff with register pressure comes from the fact that there are a finite number of registers in each SIMD (4 SIMDs in a CU) so the more registers each thread requires the fewer threads can be run in parallel. Memory access latencies are also hidden via threading (if one thread is waiting for a memory access another thread may still be able to run) so managing register pressure is also an important part of the optimization effort.