RADV Exploring "A Driver On The GPU" In Moving More Vulkan Tasks To The GPU

[phoronix]

Phoronix: RADV Exploring "A Driver On The GPU" In Moving More Vulkan Tasks To The GPU

In order to fully support Direct3D Indirect Drawing for allowing more rendering tasks to be moved from the CPU to the GPU, the open-source RADV Radeon Vulkan driver is working on experimental code for effectively hosting "a driver on the GPU."..

https://www.phoronix.com/scan.php?page=news_item&px=RADV-Exploring-Indirect-Draw

[Linuxxx]

I wonder if this also has anything to do with the recent discussions about the limitations of Linux's implicit sync model for GPU drivers?

AFAIR, nVidia already exposes a custom vendor extension for indirect execution in their Linux Vulkan driver.

Any comments from knowledgeable GPU hackers appreciated! (You know who you are... )

[BNieuwenhuizen]

I wonder if this also has anything to do with the recent discussions about the limitations of Linux's implicit sync model for GPU drivers?

No, that is seeing unrelated work, which probably deserves its own blog post.

[kiffmet]

Is this conceptually similar to what Microsoft does on the Xbox Series S/X with the GPU's command processor in order to offload more D3D12 commands? IIRC Microsoft spun their own GPU firmware to make this work.

[rmnscnce]

From what I see, I think this will be similar to Ubershaders by Dolphin Emulator (which its write up is one of the most fun to read through).

[shmerl]

What exactly are they offloading to the GPU? It would be cool if part of the shaders' compilation could be using GPU itself

After all it's not too different from a compilation for the CPU using the CPU (besides all the GPU SIMD focus and specialization of course).

[smitty3268]

Are you planning to fully support VK_NV_device_generated_commands then, or would it be easier to create a new MESA extension that's more tailored to the AMD hardware and what proton needs?

[Linuxxx]

No, that is seeing unrelated work, which probably deserves its own blog post.

Thanks for answering!

However, there's one more question I have after reading this on Your blog:

This functionality happens to be a subset of VK_NV_device_generated_commands and hence I’ve been working on implementing a subset of that extension on radv. Unfortunately, we can’t really give the firmware a “extended indirect draw call” and execute stuff, so we’re stuck generating command buffers on the GPU.

Do You have any idea how nVidia implemented this extension on their driver?
Shouldn't they also face the same issues You are encountering?
Or is there a fundamental difference in hardware capabilities?
(I'm guessing not because Xbox Series seems to handle ExecuteIndirect with RDNA2 just fine, so why are these problems occuring on Linux?)

Thanks for any answer in advance!

[jorgepl]

I wonder if this also has anything to do with the recent discussions about the limitations of Linux's implicit sync model for GPU drivers?

AFAIR, nVidia already exposes a custom vendor extension for indirect execution in their Linux Vulkan driver.

Any comments from knowledgeable GPU hackers appreciated! (You know who you are... )

I would love to know more about this topic, and also the pros and cons of implicit vs explicit sync model. AFAIK it's not a limit sync model, but a Wayland sync model, but that's as far as I could read on the internet. I can't find more info. Do you know where could I read more about this?

[Venemo]

What exactly are they offloading to the GPU?

Most current applications generate a command buffer on the CPU, and then ask the GPU to execute that. A command buffer is basically a list of draws, copies, dispatches etc. which is executed by the GPU's command processor.

This new feature Bas is working on, makes it possible for applications to generate a command buffer on the GPU, and then executing that on the GPU without CPU intervention.

The main difficulty here is that these command buffers are more difficult to debug and analyze.

It would be cool if part of the shaders' compilation could be using GPU itself

That is not actually feasible. GPUs are not really geared towards this kind of work.

After all it's not too different from a compilation for the CPU using the CPU (besides all the GPU SIMD focus and specialization of course).

It's very different.