VKD3D Is Beginning Flight As Wine's Direct3D 12 To Vulkan Library

[phoronix]

Phoronix: VKD3D Is Beginning Flight As Wine's Direct3D 12 To Vulkan Library

Back at WineConf 2017 VKD3D was announced for bringing Direct3D 12 to Wine by implementing Microsoft's latest graphics API atop the Vulkan graphics API. The initial code for this new library is beginning to take shape...

http://www.phoronix.com/scan.php?page=news_item&px=VKD3D-Taking-Flight

[R41N3R]

I'm very excited about the progress of VK9, DXVK and VKD3D and I will follow the development closely. I'm sure that all these efforts will pay-off.

[theriddick]

I'm very excited about the progress of VK9, DXVK and VKD3D and I will follow the development closely. I'm sure that all these efforts will pay-off.

Yes, once RADV gets more optimisations happening it should be right up near Nvidia Vulkan performance. Not sure how long that will take but the prospects of getting good performance out of DX11/12 games under Linux with these projects would be amazing.

[eydee]

Yes, once RADV gets more optimisations happening it should be right up near Nvidia Vulkan performance.

You mean the continuous crashing, lockups, rendering issues? You don't want that in RADV.

[theriddick]

Never heard of those issues with NVIDIA Vulkan usage. Perhaps you mean NVIDIA Vulkan under Wine?

[VikingGe]

You mean the continuous crashing, lockups, rendering issues? You don't want that in RADV.

If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)

[nanonyme]

If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)

Allowing segfaults sounds like a reasonable symptom of the desire to reduce driver overhead. Sounds like main problem there is the validation is not good enough. Permanent GPU hangs are of course inacceptable

[VikingGe]

Allowing segfaults sounds like a reasonable symptom of the desire to reduce driver overhead.

Don't get me wrong, it certainly is, and the good thing about RADV in particular is that you *can* actually debug them *at all* - I imagine this would be a lot more painful with a closed-source driver.

[jrch2k8]

If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)

Not looking to be an ass here but what you describe is exactly why Vulkan exists, you have to make sure the code is perfect not the driver

Remember DX11/OpenGL is akin to PHP in the CPU world while Vulkan is akin to ISO C 99, so is absolutely normal behavior in either case and about SPIRV compilation is pretty much as it should since on the CPU side is like that as well(no compiler is smart enough to detect segfaults, sigabrts, etc. at compilation time).

I do agree that Vulkan(and D3D12 as well) need more robust debugging tools

[GreenByte]

I am really looking forward to it. Might try to get involved in it.