DXVK 1.2.2 Brings Minor CPU Overhead Optimizations, Game Fixes

[L_A_G]

Calling DXVK "dead end" sounds an awful lot like they're just annoyed by somebody making all of their D3D11 and D3D10 work unnecessary and just want to develop their own implementation to prove themselves rather than anything tangible. Not that this wasn't obvious considering the half-assed attempts at communicating with the lead DXVK dev and then claiming that they were being ignored by him.

Seriously thou, what the hell is it with people in the open source community and NIH syndrome? Having worked with both open and closed source software it seems like open source is just full to the gills with absolute control freaks who want to develop pretty much everything they can in-house when good open source third party alternatives exist.

[F.Ultra]

Calling DXVK "dead end" sounds an awful lot like they're just annoyed by somebody making all of their D3D11 and D3D10 work unnecessary and just want to develop their own implementation to prove themselves rather than anything tangible. Not that this wasn't obvious considering the half-assed attempts at communicating with the lead DXVK dev and then claiming that they were being ignored by him.

Seriously thou, what the hell is it with people in the open source community and NIH syndrome? Having worked with both open and closed source software it seems like open source is just full to the gills with absolute control freaks who want to develop pretty much everything they can in-house when good open source third party alternatives exist.

The developer of DXVK commented on GamingOnLinux where he agreed with what the WiNE dev said. To summarize, DXVK is only targeted at games while Wine3d also have to cover lots of applications where DXVK does not work at all (and never will), that is why DXVK is a "dead end" for WiNE.

https://www.gamingonlinux.com/articl...age=2#comments and scroll down to the second post.

[oiaohm]

That's just wrong. Here's a CPU-limited run of Unigine Valley, Ultra 640x360 no AA:
- Linux OGL: Score = 5788; AVG = 138.3; Min = 48.7
- DXVK: Score = 5746; AVG = 137.3; Min = 40.5
- WineD3D: Score = 3324; AVG = 79.4; Min = 29.8

That is showing something different to what you say. You need to in fact run a performance graphic because you will notice WineD3D is not taking advantage of the CPU.

It's still almost on par with the native version and is now 73% faster than wined3d (previously it was 18%). So where excactly is the "performance collapse" you're speaking of?

That is not DXVK being CPU limited. If you compare the two runs cpu usage you will notice that wined3d is using bascially the same amount of cpu both times. You will notice a single core ram into 100%. Lets say you restrict dxvk to the same number of cpu cores wined3d can currently use due to its opengl design.

Then name one. You still haven't backed up your claims with any actual results that weren't obtained from an over one-year old DXVK version.

You have the right program you are not running benchmark the right way with the right limitations to in fact compare them. Once you force dxvk to play with the same limitations wined3d is issues in the dxvk design start showing up.

[artivision]

That is showing something different to what you say. You need to in fact run a performance graphic because you will notice WineD3D is not taking advantage of the CPU.



That is not DXVK being CPU limited. If you compare the two runs cpu usage you will notice that wined3d is using bascially the same amount of cpu both times. You will notice a single core ram into 100%. Lets say you restrict dxvk to the same number of cpu cores wined3d can currently use due to its opengl design.




You have the right program you are not running benchmark the right way with the right limitations to in fact compare them. Once you force dxvk to play with the same limitations wined3d is issues in the dxvk design start showing up.

First year in university back then, some we had an analytic conversation about WineD3D. We had concluded (not performance wise speaking but overall code wise) that each one of us could do a better job with more advanced ideas even back then. So as i understand it (because it seams no one wants to tell them) they don't know what they are doing and believe me no one will ever co develop with them. WineD3D is like seeing a child programing.

[oiaohm]

First year in university back then, some we had an analytic conversation about WineD3D. We had concluded (not performance wise speaking but overall code wise) that each one of us could do a better job with more advanced ideas even back then. So as i understand it (because it seams no one wants to tell them) they don't know what they are doing and believe me no one will ever co develop with them. WineD3D is like seeing a child programing.

I learnt early on that wined3d code is not that simple to play with. Minor changes alter behaviour and you have like 100+ old applications businesses use explode in failure.

Lot of people have had the idea with PBA and other things of we will put a modern idea quickly into wined3d but then when a stack of application explode due to depending on particular behaviours you are in trouble. This is the problem there is a lot of stuff in WineD3D that looks like child programing/ineffective that turn out to have to be ineffective so that old windows applications in fact run right.

Even the dxvk developer has found out that its lot harder than it first appears to do a dx layer. Games and Applications are coded to depend on Microsoft oddness in the DX API/ABI. If you want the worst one for dependance on Windows API/ABI oddness its business applications.

believe me no one will ever co develop with them

There are many co developers of wined3d. Its really easy to go over a code base and say hey we could code it better. It comes a complete different thing when you have to. Part of the broken code quality of wined3d is in fact too many different developers work on the same project pushing it in different directions. DXVK is 1 lead developer. Wined3d history as 48 developers partly in the lead role. Its only been the last 3 years that particular person at codeweavers have been put in charge of wined3d to have final say on stuff. So basically you just got the problem backwards.

[cute2dgirl]

That is not DXVK being CPU limited. If you compare the two runs cpu usage you will notice that wined3d is using bascially the same amount of cpu both times. You will notice a single core ram into 100%. Lets say you restrict dxvk to the same number of cpu cores wined3d can currently use due to its opengl design.

Again, bullshit. You want to add restrictions to DXVK that it somply doesn't have.

Also, both wined3d and dxvk implement CSMT with one extra thread that does most of the work. There's no magic Vulkan multithreading goin on, that only affects resource creation. DXVK also has another thread for command submission, but guess what, OpenGL drivers do that too!

But anyway, let's run the thing on one core with two threads. Originally I wanted to use one thread for both, but wined3d just locked up entirely because it's busy-waiting on its CS thread, so here's a run with two threads:
- DXVK: Score = 4518; AVG = 108.0; Min = 35.4
- WineD3D: Score = 2366; AVG = 57.0; Min = 21.6

Oh look, it's 90% faster. That's even more than in the previous run.

It's quite obvious is that your only goal in this whole discussion is to shittalk my work. And from a wine perspective, DXVK sure has its shortcomings, but performance isn't one of them. If you're somehow trying to argue that OpenGL-based wined3d has better performance then you're going to lose, badly.

[oiaohm]

Again, bullshit. You want to add restrictions to DXVK that it somply doesn't have.

Also, both wined3d and dxvk implement CSMT with one extra thread that does most of the work. There's no magic Vulkan multithreading goin on, that only affects resource creation. DXVK also has another thread for command submission, but guess what, OpenGL drivers do that too!

But anyway, let's run the thing on one core with two threads. Originally I wanted to use one thread for both, but wined3d just locked up entirely because it's busy-waiting on its CS thread, so here's a run with two threads:
- DXVK: Score = 4518; AVG = 108.0; Min = 35.4
- WineD3D: Score = 2366; AVG = 57.0; Min = 21.6

Oh look, it's 90% faster. That's even more than in the previous run.

It's quite obvious is that your only goal in this whole discussion is to shittalk my work. And from a wine perspective, DXVK sure has its shortcomings, but performance isn't one of them. If you're somehow trying to argue that OpenGL-based wined3d has better performance then you're going to lose, badly.

Try again. 1 core 2 thread is a wrong test. If the problem is a core hammered you will not gain performance by having 2 threads on 1 core in fact you lose performance.

You need to run a benchmark tool like you can with bpftrace that will show you the cpu usage shape. You will notice WineD3D is locked in the opengl stack.

Originally I wanted to use one thread for both, but wined3d just locked up entirely because it's busy-waiting on its CS thread, so here's a run with two threads:

This is in fact coming from opengl where particular operations must only come from 1 thread. Yes you need to lock dxvk to 1 thread and give wined3d 2. You would have seen this if you were using performance graphs.

Notice how you are just quote FPS at me. This means you are not looking for low level performance. Not looking at where wined3d is crippled and what is causing it.

The fact this stall to death when having only a single thread can be fixed by using Vulkan and multi threaded allocations also is allowed in Vulkan this alters performance a lot.

I was very clear that you need to limit DXVK to the same cpu usage as wined3d was using to see the dxvk problem was I not. Wined3d is not that performance bad when you put DXVK and Wined3d on the exact same amount of used cpu resources.

[smitty3268]

...

I can't help but notice you still haven't provided any numbers based on current DXVK.

Since it's obvious that everyone else is having trouble reproducing the exact use-case you seem to be describing, why don't you do it yourself?

And if it's extremely difficult to come up with this scenario - well, maybe that says something important too.

[oiaohm]

I can't help but notice you still haven't provided any numbers based on current DXVK.

Since it's obvious that everyone else is having trouble reproducing the exact use-case you seem to be describing, why don't you do it yourself?

And if it's extremely difficult to come up with this scenario - well, maybe that says something important too.

The reality is is they have the right program benchmark. They have the wrong benchmark method. FPS tells you total does not tell you very much.

Remember wined3d is using opengl. dxvk is using vulkan and then they are benchmarking against OGL version of program.

If you were trying to make arguement that dxvk is better code than wined3d you need to perform 2 sysprofiles and level out cpu usage when dxvk is is running and wined3d is running. This is to remove opengl and vulkan performance differences being a factor in your reason for saying 1 is better than the other.

If you do this you will notice wined3d is using less cpu time to get the same amount of work done. Problem wined3d getting stuck in opengl very badly. Something virtgl developers who have started working on vulkan have noticed it is design IPC very well where opengl is not. Most of virtgl overhead in opengl is convincing opengl to IPC.

Yes vulkan inside wine to vulkan outside wine to start off with has lower overhead than opengl application inside wine vs outside wine. They don't allow that opengl in wine has a higher overhead than vulkan wine to start off with so Wined3d is behind just there to start off with.

Also they are not allowing that some of the areas where wined3d is getting stuck in opengl releate to buffer sharing stuff that dxvk does not support.

Dxvk does not really have that big of a performance advantage over wined3d other than it choice of backend and the fact it does not implement particular features.

There are many things in vulkan that may help wined3d with it pain points.

The horrible reality here dxvk should be beating the OGL version because if a Vulkan version of program ever gets release that is made well it going to be losing badly.

Gamers benchmark total solution. They have no clue on invidual part bench-marking to locate where defects really are. This is like people always blaming gnome javascript in it shell for the low shell performance and since they integrated sysprof it turns out people were wrong 99% of the time yes there is the 1% where they are in fact correct the javascript suxs.

Wine with dxvk using vulkan as a total solution is faster than wine with wined3d using opengl. Problem is when you look at sysprof and other proper compare numbers and you level out cpu usage time in dxvk libraries and wined3d libraries the wined3d libraries are using less cpu time. This says there is a possibility that wined3d is better code for the job just it using the wrong backend. So at this stage wined3d and dxvk both need to go forwards once they are both in fact using Vulkan then compare them with FPS then you will have 1 difference being wined3d vs dxvk. Currently you have multi differences when you compare wined3d and dxvk that by the sysprof and other data says you could be getting a completely false impression.

[smitty3268]

The reality is is they have the right program benchmark. They have the wrong benchmark method. FPS tells you total does not tell you very much.

That's an awful long response, but at the end of it I can't help but notice you still haven't posted any numbers. And in fact seem to be arguing that FPS performance no longer matters at all, which makes me think you've finally realized that DXVK wins at that in all cases.