GPU Scheduler Being Implemented For AMDGPU Kernel Driver

[phoronix]

Phoronix: GPU Scheduler Being Implemented For AMDGPU Kernel Driver

Alex Deucher ended out the month by releasing thirty-one patches that implement a GPU scheduler for the new AMDGPU kernel DRM driver...

http://www.phoronix.com/scan.php?pag...-GPU-Scheduler

[Veto]

Alex, Bridgman, Marek and all of you: Thank you for your big effort towards making the open drivers rock! My next GPU will (also) be an AMD.

[boxie]

As the proud owner of a shiny new R9 380 - I am looking forward to the 4.3 kernel with reclocking for my GPU

Alex, Bridgman, Marek and all of you: Thank you for your big effort towards making the open drivers rock!

here here! +1

[stiiixy]

I could have run out and gotten a new rig (Intvidia) and been smashing out the games I cant afford timewise to play for months. I'm happy to wait for all of this to mature before a new purchase of AMD+AMD.

[Ericg]

I could have run out and gotten a new rig (Intvidia) and been smashing out the games I cant afford timewise to play for months. I'm happy to wait for all of this to mature before a new purchase of AMD+AMD.

As someone WITH an AMD+AMD system (A10 7850K + R9 290) if youre only gaming then AMD+AMD is fine, but if you are doing some more intensive stuff (For me: Blender, x264 live recording, etc) you still probably want Intel + AMD/Nvidia

[smitty3268]

Is this for HSA? Or will it improve things like OpenGL workloads as well?

[bridgman]

This is more for OpenGL workloads (and compute going through kernel graphics driver I guess).

The HSA stack uses a hardware-based scheduler, but the primary purpose of that scheduler is to provide support for an arbitrary number of user-space compute rings. The kernel graphics driver doesn't need that because it uses a single kernel ring and allows multiple processes to take turns submitting to it. The GPU scheduler Alex just posted basically maintains a number of kernel rings that are not connected directly to the hardware, and feeds work from those rings into that "single kernel ring" which the HW pulls from.

[zanny]

As someone WITH an AMD+AMD system (A10 7850K + R9 290) if youre only gaming then AMD+AMD is fine, but if you are doing some more intensive stuff (For me: Blender, x264 live recording, etc) you still probably want Intel + AMD/Nvidia

Intel + AMD can also work. Beignet just got a new release, but its OpenCL works with Blender already on Arch and mesa-git. You may not have as many horses but a hundred fold speed increase is a lot more than a 3x speed increase from integrated to discrete.

[smitty3268]

This is more for OpenGL workloads (and compute going through kernel graphics driver I guess).

The HSA stack uses a hardware-based scheduler, but the primary purpose of that scheduler is to provide support for an arbitrary number of user-space compute rings. The kernel graphics driver doesn't need that because it uses a single kernel ring and allows multiple processes to take turns submitting to it. The GPU scheduler Alex just posted basically maintains a number of kernel rings that are not connected directly to the hardware, and feeds work from those rings into that "single kernel ring" which the HW pulls from.

Thanks for the info!

[wizard69]

This is more for OpenGL workloads (and compute going through kernel graphics driver I guess).

The HSA stack uses a hardware-based scheduler, but the primary purpose of that scheduler is to provide support for an arbitrary number of user-space compute rings. The kernel graphics driver doesn't need that because it uses a single kernel ring and allows multiple processes to take turns submitting to it. The GPU scheduler Alex just posted basically maintains a number of kernel rings that are not connected directly to the hardware, and feeds work from those rings into that "single kernel ring" which the HW pulls from.

I'm not sure I understand this! Why not maintain one scheduler that handles all work loads or does this assure that graphics always has at least one thread.