RADV Vulkan Driver Now Supports NVIDIA's Device Generated Commands

[phoronix]

Phoronix: RADV Vulkan Driver Now Supports NVIDIA's Device Generated Commands

As of this week in Mesa 22.2, the open-source Radeon Vulkan driver "RADV" has added support for the VK_NV_device_generated_commands extension. This NVIDIA-created extension that has been around for a few years with their hardware allows for the GPU to generate some of the most frequent rendering commands on the hardware itself...

https://www.phoronix.com/scan.php?page=news_item&px=RADV-Vulkan-DGC

[Linuxxx]

This extension may prove useful for VKD3D support with handling of D3D12's ExecuteIndirect functionality.

True, looks like the main dev of VKD3D-Proton has got Halo Infinite working on RDNA2, although another one reported GPU hangs with this.

Still, very much appreciated progress nonetheless!

[Sethox]

True, looks like the main dev of VKD3D-Proton has got Halo Infinite working on RDNA2, although another one reported GPU hangs with this.

Still, very much appreciated progress nonetheless!

Yeah, I saw that whole thread. Technically it's an early phase of test (developmental) so obviously other parts have to be bisected and researched to see solutions. But it's a step to the right direction to find solutions in other parts that gains problems (new problems that may occur).
I find usual response towards Nvidia "drivers"/releases/vulkan implementations are reached with skepticism and doubt that it can solve for anything in the open source community (same with Microsoft). But innovated and cunning people like Bas Nieuwenhuizen (this guy has helped a lot in the Linux sphere when it comes to Vulkan) has an "outside perspective".

Regardless, this is bound to become stable at some point and a good reason to thank Nvidia for. And if not... well I guess damn Nvidia?

[Venemo]

Small correction to the article. RADV actually only supports a subset of the NVidia device generated commands extension, and we only enable it for vkd3d-proton.

[MauganRa]

Is it common for vendors implementing support for other vendor's extensions? Or would this be the first step towards standardization as a proper core extension?

[shmerl]

Does it provide any performance improvement for vkd3d-proton?

[Venemo]

Does it provide any performance improvement for vkd3d-proton?

It's not for performance but rather for feature enablement.

It provides an implementation for generating commands on the GPU, which is a D3D12 feature used by some games. The main user that I know of is Halo Infinite. Other than that this new feature doesn't impact games that don't use it.

[shmerl]

It's not for performance but rather for feature enablement.

It provides an implementation for generating commands on the GPU, which is a D3D12 feature used by some games. The main user that I know of is Halo Infinite. Other than that this new feature doesn't impact games that don't use it.

I see, thanks. Was it something originally planned as Nvidia only? I.e. why wasn't it proposed as a common Vulkan extension?

[QwertyChouskie]

Small correction to the article. RADV actually only supports a subset of the NVidia device generated commands extension, and we only enable it for vkd3d-proton.

Are there plans to implement the whole extension, or only the subset needed for vkd3d-proton?

[arQon]

Is it common for vendors implementing support for other vendor's extensions? Or would this be the first step towards standardization as a proper core extension?

Very: say, about 8 times out of 10 or so?

For the other two times, either the other vendor already has something almost exactly equivalent, in which case both kick around for another generation or two and then Khronos rolls (generally, the union of) the functionality into the spec as a standard extension; or the vendor extension is for a specific case that was either briefly fashionable but then abandoned, or was unique to that hardware in some way - in either of those cases, it generally just sits around forever as-is until it either fades into oblivion or a "version 2" superset of it supercedes it.

You do occasionally end up with e.g. NV_xyz *and* ATI_xyz extensions that serve the same purpose but never advance to a standard API, and it's possible that will become more common, but I doubt it. Once a vendor has "won" one round of the hardware wars with a new feature, it hurts the industry as a whole to have to support multiple vendor-specific hacks, so once the competition catches up on the HW side the standard tends to move quickly these days. (As opposed to 15-20 years ago, when the GL spec sat on its ass doing nothing while D3D took over the world).