Vulkan Getting Another Extension To Help With DXVK/Direct3D Performance

[varikonniemi]

This situation reminds me of X vs Wayland except different.

Wayland has maintained rigidity and refused to expand the protocol to include features and functions necessary for a complete desktop. So instead every Wayland compositor implements these features differently.

Vulkan on the other hand sees the advantage of focusing on perfection but being practical and adapting so the maximum # of gamer could benefit.

I wish more projects could focus on what's practical instead of what's ideal.

You are so wrong. Wayland is one thing, the desktop features are another. It would make no sense to include them in wayland because then embedded devices would need a compositor that supports desktop features and make it much more complex.

Once the desktop interfaces are tried in practice and we see what works, then once consensus forms wayland can specify an official desktop extension. Until then nothing prevents compositor writers from cooperating one one standard.

[Weasel]

It was last changed in June 2010, you can check the very last DirectX redistributable that is still distributed by any windows game released at this moment. That's 8 years ago, when GPUs were graphics devices and not compute devices. Also most of the changes are just new d3dx editions, nothing in the actual core. Most relevant changes were made in 2007, 2 years before DX11 was released. Also if you think DXGI and stuff are just mere interfaces, you might also think Wayland is just a small country where ways live. And x.org is a website, right? Remember, Linux is not a religion, dude, and being an a** about it doesn't take you to heaven.

Alright, I won't go into details cause honestly nobody reads anyway and prefer to stay ignorant, but I'll provide a case that anyone hopefully knows.

If the runtime was the implementation then simply installing the redistributable with winetricks would enable perfect DirectX compatibility in Wine, but that's far from the case. The bulk of it is directly in the drivers, again, made by the GPU vendors. Installing it helps a bit tho.

[TemplarGR]

You can dream of higher performance than the original. M$ Directx implementation may not be perfect, and it's very old, not designed for modern hardware.

DXVK could potentially be used on Windows for better performance... As Vulkan drivers mature, and DXVK gets more optimization/bugfixes/compatibility, even Windows users could use it to squeeze more performance out of their hardware. DX11 is after all quite limited for multicore cpus, especially with the AMD D3D11 drivers. Plus DXVK allows setting max tesselation factor limits on Nvidia hardware too...

[TemplarGR]

Alright, I won't go into details cause honestly nobody reads anyway and prefer to stay ignorant, but I'll provide a case that anyone hopefully knows.

If the runtime was the implementation then simply installing the redistributable with winetricks would enable perfect DirectX compatibility in Wine, but that's far from the case. The bulk of it is directly in the drivers, again, made by the GPU vendors. Installing it helps a bit tho.

You are indeed ignorant... The redistributable IS the implementation, it is meant to update the Direct3D9 implementation on Windows. The only reason we don't have a redistributable for 10,11, and 12, is because Windows updates it centrally now with Windows updates. But for older versions of Windows there was a need for a redistributable(which installed during normal game installations) due to many pcs not being online back then.

As for WINE, yes installing the redistributable using winetricks installs the official D3D9 on your wineprefix, but this does not guarantee 100% compatibility because WINE needs to perfectly interface with it and perfectly translate it to Linux ecosystem output. And this is where imperfections come from, even with the official binary.

Please, stop commenting on things you don't freaking understand. You are only embarassing yourself.

[TemplarGR]

It was last changed in June 2010, you can check the very last DirectX redistributable that is still distributed by any windows game released at this moment. That's 8 years ago, when GPUs were graphics devices and not compute devices. Also most of the changes are just new d3dx editions, nothing in the actual core. Most relevant changes were made in 2007, 2 years before DX11 was released. Also if you think DXGI and stuff are just mere interfaces, you might also think Wayland is just a small country where ways live. And x.org is a website, right? Remember, Linux is not a religion, dude, and being an a** about it doesn't take you to heaven.

The DirectX redistributable only contained up to DirectX9. It never contained 10 or 11. Those were ONLY delivered through Windows update to appropriate Windows versions. Also it is hillarious that you believe Direct3D 11was last updated June 2010, while it has had many revisions after that date. For example Direct3D 11.2 released with Windows 8.

[Weasel]

You are indeed ignorant... The redistributable IS the implementation, it is meant to update the Direct3D9 implementation on Windows. The only reason we don't have a redistributable for 10,11, and 12, is because Windows updates it centrally now with Windows updates. But for older versions of Windows there was a need for a redistributable(which installed during normal game installations) due to many pcs not being online back then.

Prove it.

Windows doesn't implement the graphics processing, if anything it updates missing interfaces to the actual driver proper.

As for WINE, yes installing the redistributable using winetricks installs the official D3D9 on your wineprefix, but this does not guarantee 100% compatibility because WINE needs to perfectly interface with it and perfectly translate it to Linux ecosystem output. And this is where imperfections come from, even with the official binary.

Such bullshit. Where the fuck do you guys come up with this stuff? With this technobabble buzzwords?

WINE is required to interface with it PERFECTLY since otherwise it would crash. And that simply doesn't happen. It's required to implement the Win API's interface perfectly (note: interface, not implementation). I'm so sick of people using buzzwords like "interface" without understanding what it IS in the first place.

Obviously WINE lacks the actual drivers which do 90% of the work, which is exactly why it must translate them to OpenGL. It's also exactly why Gallium9 is faster than native sometimes, since it's the bulk of the implementation itself (well, the drivers are).

This is just cringy.

Please, stop commenting on things you don't freaking understand. You are only embarassing yourself.

Please put a mirror in front of yourself then say those words out loud.

It's much more realistic.

[Weasel]

DXVK could potentially be used on Windows for better performance... As Vulkan drivers mature, and DXVK gets more optimization/bugfixes/compatibility, even Windows users could use it to squeeze more performance out of their hardware. DX11 is after all quite limited for multicore cpus, especially with the AMD D3D11 drivers. Plus DXVK allows setting max tesselation factor limits on Nvidia hardware too...

Haha I took you seriously for a while but now I realize you're just a dummy.

Can't even logic.

You think DX11 on Vulkan will be faster? Because "quite limited for multicore cpus", lol. Any Vulkan implementation of D3D11 will be required to use the same interface so it will be just as limited, if not even more (due to missing features in Vulkan that don't map to D3D11 directly). This is kindergarten level logic.

I mean yeah, you can keep on using buzzwords, or use your brain, but since you don't believe me, you can at least talk to the DXVK dev and embarrass yourself since he did claim this as well.

[TemplarGR]

Prove it.

Windows doesn't implement the graphics processing, if anything it updates missing interfaces to the actual driver proper.

Such bullshit. Where the fuck do you guys come up with this stuff? With this technobabble buzzwords?

WINE is required to interface with it PERFECTLY since otherwise it would crash. And that simply doesn't happen. It's required to implement the Win API's interface perfectly (note: interface, not implementation). I'm so sick of people using buzzwords like "interface" without understanding what it IS in the first place.

Obviously WINE lacks the actual drivers which do 90% of the work, which is exactly why it must translate them to OpenGL. It's also exactly why Gallium9 is faster than native sometimes, since it's the bulk of the implementation itself (well, the drivers are).

This is just cringy.

Please put a mirror in front of yourself then say those words out loud.

It's much more realistic.

Ok you are either trolling, a 12 year old kid, or just completely ignorant.

1) The word "interface" i used was a verb, not a noun. I said WINE still needs to (verb) INTERFACE PERFECTLY with it, that means, the IMPLEMENTATION has to still be perfect in order to have 100% compatibility. You are just playing with words at this point.

2) Direct3D is a fucking system library that is COMMON for ALL WINDOWS DRIVERS. Do you fucking understand? Direct3D is not a fucking driver, and it has a single available implementation, MICROSOFT's. GPU vendors do not implement their own Direct3D implementation. They only modify their Direct3D frontend to implement its functions on their hardware. The code gpu drivers implement is very low level. To help you understand, Direct3D from Microsoft is what Gallium is for MESA. Gallium is the OpenGL implementation and each gpu needs a gallium backend in order to interface with Gallium and through it support OpenGL. But Gallium is COMMON for ALL GPUs. You don't get to write 1000x Gallium versions for each gpu driver...

3) You got it all wrong, Direct3D from the redistributable is like 90% of the complete implementation, the driver-specific part on the gpu is only the remaining 10%.

4) The reason WINED3D has low performance is because the translation to OpenGL adds latency. Still various optimizations could minimize this overhead considerably. Gallium nine does NOT re-implement Direct3D. Where the fuck did you get that idea from? Do you fucking realize how much time it took for WINE to implement Direct3D? With a far larger professional team of coders for decades? Do you really think Gallium nine could play D3D9 games with minimal effort in a couple of years if it had to re-implement the entirety of Direct3D? All Gallium nine does is implementing a d3d9 frontend on top of gallium, just like it would happen on a windows driver. So WINE does not have to stall the code while waiting for it to be translated to OpenGL code. Still, a game running on WINE needs either the WINE Direct3D implementation OR the official binary to work. Gallium9 only removes the translation part.

[TemplarGR]

Haha I took you seriously for a while but now I realize you're just a dummy.

Can't even logic.

You think DX11 on Vulkan will be faster? Because "quite limited for multicore cpus", lol. Any Vulkan implementation of D3D11 will be required to use the same interface so it will be just as limited, if not even more (due to missing features in Vulkan that don't map to D3D11 directly). This is kindergarten level logic.

I mean yeah, you can keep on using buzzwords, or use your brain, but since you don't believe me, you can at least talk to the DXVK dev and embarrass yourself since he did claim this as well.

Yes, D3D11 can potentially be FASTER on Vulkan due to the reasons i said. D3D11 to Vulkan translation does not add nearly the same latency it adds when translating to OpenGL. Vulkan is pretty close to metal so essentially it comes close to the official D3D11 driver implementation gpu drivers use on Windows. After all, a gpu D3D11 windows driver does the same fucking thing, it takes Direct3D11 calls from the official Microsoft binary and translates it to machine code for the gpu. Possibly using an intermediate layer first, i don't know, closed source gpu drivers are closed source.

But the thing is, the usual procedure on D3D11 is: game engine----> Microsoft D3D11 library ----> Intel/Nvidia/AMD direct3d11 layer on the driver ----> (possibly intermediate layer)-----> machine code on the gpu. All Vulkan does is removing the direct3d11 layer on the gpu driver, and the need for a large Direct3D11/OpenGL library. Game engine on Vulkan does most of the D3D11 library stuff (that is why it is harder to code for). And the intermediate layer is expanded to accept API calls directly and gets called "Vulkan driver"...

So it makes sense that if you use a Direct3D11 to Vulkan translation library, you essentially trade the d3d11 driver frontend with DXVK in the toolchain. So performance should be pretty close to native, assuming optimal Vulkan drivers and optimized DXVK.

And since official windows direct3d11 drivers have certain limitations, DXVK could POTENTIALLY improve performance in the future. For example, AMD drivers do not support command lists in direct3d11. This make them perform much worse than they could. DXVK could add support for them since Vulkan DOES support them, and thus provide better multicore performance for AMD gpus than the official drivers... Sure, this would add a lot of work and it is possibly too much for the DXVK developer alone, but it is potentially doable...

Also, you can get improved performance on Nvidia gpus right now, by limiting max tesselation factor to sane levels, something you can't do with Nvidia drivers.

I don't know what the DXVK developer claims, but he is hardly a guru on Direct3D and Vulkan. He is just a young guy beginning a translation library as a hobby and getting so succesful that got hired by Valve. He is just NOW learning the ropes. I am pretty sure once the proper implementation gets completed and he gets to only occupy himself with bugfixing and optimization, he will soon reach my own conclusion: DXVK has a lot of room for optimization and can potentially surpass direct3d even on windows.

[Weasel]

Ok you are either trolling, a 12 year old kid, or just completely ignorant.

1) The word "interface" i used was a verb, not a noun. I said WINE still needs to (verb) INTERFACE PERFECTLY with it, that means, the IMPLEMENTATION has to still be perfect in order to have 100% compatibility. You are just playing with words at this point.

No, interfacing properly means that all the function signatures are properly done and the program won't crash. It doesn't mean you will get the exact same output, pixel by pixel, don't be an idiot.

2) Direct3D is a fucking system library that is COMMON for ALL WINDOWS DRIVERS. Do you fucking understand? Direct3D is not a fucking driver, and it has a single available implementation, MICROSOFT's. GPU vendors do not implement their own Direct3D implementation. They only modify their Direct3D frontend to implement its functions on their hardware. The code gpu drivers implement is very low level. To help you understand, Direct3D from Microsoft is what Gallium is for MESA. Gallium is the OpenGL implementation and each gpu needs a gallium backend in order to interface with Gallium and through it support OpenGL. But Gallium is COMMON for ALL GPUs. You don't get to write 1000x Gallium versions for each gpu driver...

I don't care how low level it is, the point is that it is the one doing the BULK of the work. And also D3D is not lower level than OpenGL. Who the fuck cares about the rest?

3) You got it all wrong, Direct3D from the redistributable is like 90% of the complete implementation, the driver-specific part on the gpu is only the remaining 10%.

That must make D3D a complete CPU bound process since 90% of the code is in the redistributable. Unless you mean it's 90% of code just for initialization and crap like that, without loops in which case who the fuck cares?

4) The reason WINED3D has low performance is because the translation to OpenGL adds latency. Still various optimizations could minimize this overhead considerably. Gallium nine does NOT re-implement Direct3D. Where the fuck did you get that idea from? Do you fucking realize how much time it took for WINE to implement Direct3D? With a far larger professional team of coders for decades? Do you really think Gallium nine could play D3D9 games with minimal effort in a couple of years if it had to re-implement the entirety of Direct3D? All Gallium nine does is implementing a d3d9 frontend on top of gallium, just like it would happen on a windows driver. So WINE does not have to stall the code while waiting for it to be translated to OpenGL code. Still, a game running on WINE needs either the WINE Direct3D implementation OR the official binary to work. Gallium9 only removes the translation part.

WTF is your point? The fact is that this is where the important bits (and bottleneck) happens: in the fucking "driver code" or "Gallium".

You said Microsoft's implementation is old and yet the performance is THE SAME AS WINE's so clearly IT DOESN'T FUCKING MATTER because what matters is the driver. That's where the bulk of the work gets done.

I said that if you use winetricks to install the redistributable you won't get a magic perf boost because it doesn't matter much for performance (except for correctness) and this thread is all about performance. The bulk happens in the driver so deal with it.

And by bulk, I don't mean "lines of code", I mean "instructions executed" (also on the GPU). A tight loop is much more important than some massive amount of code that only gets executed once, but not like you'd know that.