The Radeon Machine Scheduler Will Soon Come To AMDGPU LLVM

[phoronix]

Phoronix: The Radeon Machine Scheduler Will Soon Come To AMDGPU LLVM

Months after Axel Davy originally posted his patch-set for the SI machine scheduler to enhance the performance of AMD GCN GPUs on the open-source driver, it looks like the code will soon land in the AMDGPU LLVM back-end...

http://www.phoronix.com/scan.php?page=news_item&px=SI-Machine-Scheduler-LLVM

[darkbasic]

I'm the one who previously did the tests with the SI scheduler and as I stated on irc the boost was largely due to a big regression reverted in mesa while doing the first test. Only a little boost is accountable for the SI scheduler.

[cb88]

The utility of a hardware scheduler is to relieve the driver on the CPU from that work right? Which would make sense given AMD's weaker CPUs as well as making the catalyst and mesa drivers roughly equal at least in scheduling as it takes that last bit of optimization out of the hands of the driver.

[mannerov]

The "Machine Scheduler" is a compilation pass to determine a good instruction order.
The instruction order determines register usage and how well latencies are hidden (GCN also has a 'wavefront scheduler' on hw that tries to execute something else when something waits for a result, but the number of things it can pick from is limited, thus why the instruction order to limit latencies still matters).

Unless you are GPU-bound, you won't see any benefit from the patches.
Even there, the benefits will be a few %.

The version of the scheduler proposed for scheduling doesn't have the latest work done on it (because the improvements needed more work).
With the last version, some apps like heaven and hl2 get 10% boost.
So don't put your hype too high. It needs more improvements, but it is a good step toward reaching catalyst speed.

[pal666]

given AMD's weaker CPUs

amd's weaker cpus than nvidia's? you are hallucinating

[orome]

The utility of a hardware scheduler is to relieve the driver on the CPU from that work right? Which would make sense given AMD's weaker CPUs as well as making the catalyst and mesa drivers roughly equal at least in scheduling as it takes that last bit of optimization out of the hands of the driver.

wrong. the driver scheduler works at compile time. Hw scheduler works at execution time, it has to redo the same work every time. Moreover, most GPUs don't do out of order execution (I think nVidia tried that in one generation) because it's not energy efficient. i.e. it's better to add couple more in-order cores than to make one core out-of-order. Note that GPUs do use wave/warp schedulers to overlay long latency instructions, it makes OoO execution even worse idea for GPUs

[bridgman]

Note that there are multiple "schedulers" being worked on in the driver stack, so potential for confusion.

The "scheduler" in the amdgpu kernel driver is runtime code which gives each process its own queue for command submission and feeds commands from those queues to the HW, allowing fairer use of the GPU as well as more flexible synchronization between devices.

The scheduler being discussed here is part of the shader compiler backend, using knowledge of how the shader core processes instructions to improve how operations are sequenced and packed into the binary instruction stream.

[cb88]

wrong. the driver scheduler works at compile time. Hw scheduler works at execution time, it has to redo the same work every time. Moreover, most GPUs don't do out of order execution (I think nVidia tried that in one generation) because it's not energy efficient. i.e. it's better to add couple more in-order cores than to make one core out-of-order. Note that GPUs do use wave/warp schedulers to overlay long latency instructions, it makes OoO execution even worse idea for GPUs

Dude... how can you possibly say I'm wrong when I mentioned none of the specific things you say I am wrong about. In general a hardware scheduler's only purpose is to remove software scheduling of some form from the driver ( or to implement a new form of scheduling that couldn't didn't exist). And you do realize the *driver* compiles shaders which run on the GPU... so no it does not necessarily occur once but possibly every time the shader's cache is invalidated. So if this scheduler is what I think it is it would benefit where shader cache invalidation is frequent or non existent (for instance Mesa used to have to not have a binary shader cache) It would also probably help speed up the initial compile as well as simplifying the compiler design... somewhere AMD also lags in addition to CPU performance (IE they don't have the horsepower to schedule their next gen GPUs in software with low enough latency)