DXVK 0.41 Released, Slightly More CPU Efficient & Offers A Heads-Up Display

[artivision]

What makes you think that D3D11->Vulkan->Hardware would be faster than D3D11->Hardware? That's obviously not the case, native D3D11 is significantly faster.

First of all there is no such a think as D3D11->Hardware, D3D11 is a High Level API, so it is like D3D11->Vendor_IL->Hardware, same as DXVK and Gallium_Nine. Second, AMD's D3D11 solution is the one that reduces D3D11 Multi Threaded games to Single Threaded ones because they don't target the GCN Command Processor like D3D12 and Vulkan and Deferred_Contexts/Command_Lists are missing from AMD's D3D11. So i expect DXVK to end up with the 85% of Nvidia's speed because DXVK will never be heavily profiled like an entire driver and i also expect to end up 15% faster than AMD's solution duo to use Vulkan command abilities, but anyway slower than D3D12.

[VikingGe]

First of all there is no such a think as D3D11->Hardware, D3D11 is a High Level API

You know exactly what I mean. Do Windows drivers translate their stuff to Vulkan? No, they don't. Do they have to deal with the inefficiencies of a Vulkan-based implementation then? No, they don't, and their internal APIs can be designed to be a better fit for a D3D11 implementation than Vulkan will ever be.

Gallium is quite similar to D3D11 in many ways, Vulkan isn't. DXVK has it's own internal API as well, so if you're being pedantic, DXVK does D3D11 -> DXVK API -> Vulkan -> Hardware.

Second, AMD's D3D11 solution is the one that reduces D3D11 Multi Threaded games to Single Threaded ones because [...] Command_Lists are missing from AMD's D3D11

And nobody cares because hardly any game even uses Deferred Contexts for any significant amount of rendering.

For games that do, DXVK has the exact same issue as AMD's driver, it cannot record Vulkan command buffers on a deferred contexts because of various API quirks. Primary Vulkan command buffers don't work because they can't inherit active queries (unlike command lists in D3D11), Secondary command buffers don't work either because they don't allow new render passes to be bound. A mixture of the two where some commands are recorded directly into secondary command buffers and some are recorded to a primary buffer when the command list is executed on the immediate context is probably possible, but would end up being an unmaintainable mess with questionable gains and potentially even higher overhead when the command buffers end up being too small.

D3D11's ability to map resources on a deferred context further complicates this matter.

So i expect DXVK to end up with the 85% of Nvidia's speed [...] and i also expect to end up 15% faster than AMD's solution duo to use Vulkan command abilities

Then prepare to be disappointed. AMD's solution is faster, and sometimes by a significant amount, in both CPU- and GPU-limited scenarios.

[artivision]

You know exactly what I mean. Do Windows drivers translate their stuff to Vulkan? No, they don't. Do they have to deal with the inefficiencies of a Vulkan-based implementation then? No, they don't, and their internal APIs can be designed to be a better fit for a D3D11 implementation than Vulkan will ever be.

Gallium is quite similar to D3D11 in many ways, Vulkan isn't. DXVK has it's own internal API as well, so if you're being pedantic, DXVK does D3D11 -> DXVK API -> Vulkan -> Hardware.


And nobody cares because hardly any game even uses Deferred Contexts for any significant amount of rendering.

For games that do, DXVK has the exact same issue as AMD's driver, it cannot record Vulkan command buffers on a deferred contexts because of various API quirks. Primary Vulkan command buffers don't work because they can't inherit active queries (unlike command lists in D3D11), Secondary command buffers don't work either because they don't allow new render passes to be bound. A mixture of the two where some commands are recorded directly into secondary command buffers and some are recorded to a primary buffer when the command list is executed on the immediate context is probably possible, but would end up being an unmaintainable mess with questionable gains and potentially even higher overhead when the command buffers end up being too small.

D3D11's ability to map resources on a deferred context further complicates this matter.


Then prepare to be disappointed. AMD's solution is faster, and sometimes by a significant amount, in both CPU- and GPU-limited scenarios.

I see we count different things as speed, basically you don't separate API speed and Graphics speed, so let me explain it better: Lets take one of my Prime laptops with Tomb Raider 2013 Medium Settings. On Windowz D3D11=40fps@100%Gpu and D3D9=30fps@75%Gpu. Once i start to go to Higher Settings both Apis are equal on Gpu at 25fps, so both are Graphically equal but 25fps is not good enough for me. The same on Linux WineD3D11=40fps@100%Gpu and Nine=30fps@75%Gpu, both can meet at 25fps. So you only count when your GPU is filled at 100%, if the framerate is 60fps you are OK, if it is 25fps this is bad. Just because on Windowsz you can drop some quality to get to 80fps wile on Linux you will still be at 60fps, that is not a serious problem and that is happening only to a few games. Eventually a game will be at 100% Gpu wise because there is no magic to gain more on native closed platforms nor something dark to lose flops on free an non native implementations. It is what it is as the game developer did it and you cannot accelerate or decline the Graphics part, only the control part.

[VikingGe]

artivision I have no idea what your point is, but basically, if you have a GPU load of 100% on both native Windows and DXVK, and you get 60 FPS on Windows, you can expect 45 FPS on DXVK. That's the point I'm trying to make.

And assuming that games will never be CPU-bound is also not correct. Some will, some won't, and of course it depends on the hardware and settings used.

[artivision]

artivision I have no idea what your point is, but basically, if you have a GPU load of 100% on both native Windows and DXVK, and you get 60 FPS on Windows, you can expect 45 FPS on DXVK. That's the point I'm trying to make.

And assuming that games will never be CPU-bound is also not correct. Some will, some won't, and of course it depends on the hardware and settings used.

This simply means that the Image on Windows is graphically inferior. That can be done if setting are lower on Windows or if DXVK ignores some low stuff or there are various multi-sampling reduction cases on closed drivers, and goes on as i told you before DXVK is not highly profiled. There is also the case that DXVK is incomplete for this game and i was talking for a complete DXVK.

[VikingGe]

This simply means that the Image on Windows is graphically inferior.

No, it doesn't. How would you even come to that conclusion?

Just run stuff like the Ungine benchmarks on native Windows and on DXVK and see for yourself...

[artivision]

No, it doesn't. How would you even come to that conclusion?

Just run stuff like the Ungine benchmarks on native Windows and on DXVK and see for yourself...

With both Heaven and Valley i get exactly the same Fps per Gpu Utilization as on Windows. On one of my Laptops (Hainan) ~25fps@100%Gpu Low Settings.

[VikingGe]

Well I certainly don't (on Polaris), and on Nvidia it's actually slower than the OpenGL renderer. And only one of the games I regularly use for testing gets roughly the same performance as on Windows. Expecting it to consistently deliver the same performance or even to outperform Windows is expecting far too much.

[artivision]

Well I certainly don't (on Polaris), and on Nvidia it's actually slower than the OpenGL renderer. And only one of the games I regularly use for testing gets roughly the same performance as on Windows. Expecting it to consistently deliver the same performance or even to outperform Windows is expecting far too much.

That is what i'm trying to tell you: there is a configuration level that both have the same FPS and GPU usage and there are many levels that differ. The question is where that merging is, with DXVK is around 40-70fps@2K with WineD3D is at 20-30fps@4K, we search for the same effect at 80-120fps@1080p but it's difficult to do that inside a few months. Closed drivers have special profiles for many games over the years and they cut corners.

Also as a developer if i program an FX to consume 200Gflops for example, it will do that regardless how many layers passes. If i develop a variable FX that i'm giving you the ability go between 100-200Gflops and when a user chooses High in game options you almost always do 100 that means you actually cheating vs the implementation that does ~150 and you have more noise in your picture.

For X Gpu usage and Y shader information you will always take W FPS regardless of the Api or Emulation that is a rule, after that rule you are out of the Logic Region.

[Guy1524]

artivision

Are you talking out of your ass? Because that's what it looks like.