DXVK 1.2.2 Brings Minor CPU Overhead Optimizations, Game Fixes

[Panda_Wrist]

1/2 OT

I hope Haswell will be finally usable again with DXVK.

There was some new stuff posted to the bug tracker that seem to help,
but I fear it lacks progress to get it merged.

https://bugs.freedesktop.org/show_bug.cgi?id=105226

https://gitlab.freedesktop.org/mesa/mesa/commit/6230bfeb656f1de598e8ed58cef548dc1c1781aa

The patch has already been added to mesa git. Although I'm not sure what release of mesa will include it, but for sure a future mesa release will have it.

[rabcor]

Lol, DXVK a dead end, what are they even smoking?

1: DXVK completed the job that they themselves failed to do for over a decade.
2: It did it better than they ever could have (if wine's dx9 implementation is anything to go by)
3: D9VK based heavily on DXVK is a significantly better dx9 implementation than Wine's original one even in it's current 0.x state.

They should just go with the flow rather than trying to reinvent the wheel and refocus their efforts on their DX12 implementation, because the rest of the work has been done better than they ever could have done it themselves. Sure they can think of DXVK as a stopgap measure all they want, but how many decades will it tkae for them to catch up to DXVK in compatibility and performance with some internal crap?

[entropy]

https://gitlab.freedesktop.org/mesa/...f548dc1c1781aa

The patch has already been added to mesa git. Although I'm not sure what release of mesa will include it, but for sure a future mesa release will have it.

Thanks!

That's great.

It's in master so I guess 19.1.
First point releases typically get out soon to fix some fallout.

[Black_Fox]

https://gitlab.freedesktop.org/mesa/mesa/commit/6230bfeb656f1de598e8ed58cef548dc1c1781aa

The patch has already been added to mesa git. Although I'm not sure what release of mesa will include it, but for sure a future mesa release will have it.

So you're saying there's a chance. Thanks for the good news!

[oiaohm]

Lol, DXVK a dead end, what are they even smoking?

1: DXVK completed the job that they themselves failed to do for over a decade.
2: It did it better than they ever could have (if wine's dx9 implementation is anything to go by)
3: D9VK based heavily on DXVK is a significantly better dx9 implementation than Wine's original one even in it's current 0.x state.

They should just go with the flow rather than trying to reinvent the wheel and refocus their efforts on their DX12 implementation, because the rest of the work has been done better than they ever could have done it themselves. Sure they can think of DXVK as a stopgap measure all they want, but how many decades will it tkae for them to catch up to DXVK in compatibility and performance with some internal crap?

You need the DX11/10/9.... using compatible buffer outputs into DXGI for the DX12 implementation. So implementing DX12 does not mean that you don't have to interact with the other versions of DX.

Your point 1 is bogus because DXVK got to use Vulkan. There looks to be many cases where DXVK loses to wined3d in Dx10/11 applications due to buffer sync issues resulting in game performance competently screwing up. Wined3d has a over a decade of back data on ABI/API flaws.

Point 3 still has the same problem as DXVK under dx10/11 where there are parts of the API screwing it over.

2: It did it better than they ever could have (if wine's dx9 implementation is anything to go by)
So you have not been benchmarking DX11 to DX11.

What are you smoking really. Lets go though DXVK issue list. https://github.com/doitsujin/dxvk/issues/67 you will find multi different bugs where DXVK in fact under performs the wined3d implementation.

Basically lets stop the bull crap. The reality DXVK not better than Wined3d in all cases. There are quite a few cases where DXVK loses badly. We know wined3d performance is crippled by opengl handling of multi threading. With that how can there be cases at all where DXVK is losing to Wined3d by factor of 50% at times.

So maybe update Wined3d to Vulkan so keeping the bits of Wined3d that work well maybe the correct way forwards.

[R41N3R]

Key thing you said their is flagship. Once you move out of flagship models to the lower end models we still have phones being made opengl only. We are not to the point that all new devices contain Vulkan.



This is slightly off. https://moltengl.com/moltengl/ macOS opengl is a dog. So opengl es support is in fact both for MacOS and Android.



Please drop the works for me attitude and look back at the bigger market. We are still about 4 years before you will be able to go into a shop and be sure that the android phone you buy new has Vulkan.

There has been the odd driver/hardware glitch like intel haskell and different arm socs where Vulkan is advertised but does not work. Interesting point when you implement vulkan you need particular features in the hardware GPU that opengl and opengl es does not. This is why Vulkan and be broken in some arm soc chips by hardware defect yet openg; es function perfectly. Yes so that you phone says it got Vulkan unless you run Vulkan applications it may or may not work.. Android default interface depends on opengl es.

So there is a need to really support opengl compatibility for another 10 years particularly for the markets codeweavers are targeting. If you are running a business application and vulkan breaks like what happened on the haskell users you will be thankful for the secondary option. Of course the fact that Vulkan mandates using more features in hardware than opengl means on future slightly defective GPU opengl option will remain more likely to work.

Its not healthy to put all your support in 1 graphics interface at this stage. Vulkan support is not mature enough in the market.

Wine project is extend wined3d to support Vulkan and opengl. This will mean not needing to duplicate up test cases.

Vulkan is required at least with Android Q 64bit. A mobile without Vulkan support is probably anyway too slow for running anything serious on Android with Wine, at least I would prefer something native on low power devices and I never even had the thought to test Wine on Android either. If you look at projects like Angle then Google is serious about going Vulkan as well, so OpenGL ES might run on top of Vulkan at some point too. Mesa just added the new TURNIP Vulkan driver for Adreno.
On my desktop RADV is extremly stable, compared to RadeonSI I had far less issues with this driver. Nobody removed the possibility to use WineD3D if Vulkan is not available on old hardware and you can use it happily for the next 10 years, but I won't ;-)

[cute2dgirl]

Yes we are seeing DXVK resort to a lot of per game patches to catch up to wined3d where it not using any per game patches. Per game patches on graphics are done by Nvidia and AMD under windows but they are technically bad because you are no longer rendering the game how the developer intended. Yes they boost you FPS now but they also degrade the game when you get a newer video card that can handle the extra load.

Literally all of that is bullshit. None of the per-game hacks introduce incorrect rendering, most of them don't affect performance, and as a general rule they are only used when a game is broken and does not work properly out of the box.

Half of those "hacks" literally only change the GPU vendor reported to the game becasue these games are either trying to load libraries that don't exist on wine, or are trying to work around Windows driver bugs which aren't present on the Linux graphics stack either. The rest is mostly working around blatant game bugs that in some cases even affect native Windows drivers as well (e.g. the Fifa 19 black grass issue on Intel GPUs).

The fact that wined3d running on opengl that is known to have extra overhead at times can run rings around DXVK point to some very critical problems in DXVK core. When I say rings there are still some DX10 and Dx11 games where wined3d has double the frame rate at min and max to DXVK without any graphical artefacts.

When making such claims, it wouldn't hurt to give at least one example where wined3d is actually twice as fast. Or even faster at all.

I'm not here to shittalk wined3d, but it has well-documented major performance issues, and it is my understanding that the developers are well aware of them. One of them being Map() synchronization being slow, which was addressed by the unofficial PBA patch set, another one being the global mutex around all D3D11 entry points which I also saw mentioned in mailing list discussions. And while the former doesn't affect all applications (e.g. Unigine benchmarks don't really suffer from this as much as most games do), the latter most certainly does.

But DXVK does not always work well.
https://github.com/doitsujin/dxvk/issues/67

February 2018. Yeah, let's just ignore the fact that DXVK had ~600 commits at the time (right now it's sitting at 2300), was far from feature complete, had ways to go in terms of optimization, and Vulkan drivers (especially Nvidia's) have improved significantly in the past year as well.

Just to post some up-to-date numbers for Unigine Valley, since that was mentioned in that issue and was actually slower than wined3d at the time:
- DXVK: Score = 3764; AVG = 90.0; Min = 33.4
- WineD3D: Score = 3184; AVG = 76.1; Min = 32.3
- Linux OGL: Score = 3653; AVG = 87.8; Min = 43.8

On Mesa 19.0.5, RX 480, 1080p Ultra no AA. To be fair, if this was CPU-limited then the native Linux build would win, but RADV is faster than RadeonSI in the GPU-limited case. And for the record, the Minimums always happen during loading screens, not completely irrelevant but also not the most meaningful metric in this benchmark either.

[oiaohm]

February 2018. Yeah, let's just ignore the fact that DXVK had ~600 commits at the time (right now it's sitting at 2300), was far from feature complete, had ways to go in terms of optimization, and Vulkan drivers (especially Nvidia's) have improved significantly in the past year as well.

I pointed because back then there were benchmarks in different DX11 games turning up with problems. There are still cases of wined3d on different games beating DXVK.

Just to post some up-to-date numbers for Unigine Valley, since that was mentioned in that issue and was actually slower than wined3d at the time:
- DXVK: Score = 3764; AVG = 90.0; Min = 33.4
- WineD3D: Score = 3184; AVG = 76.1; Min = 32.3
- Linux OGL: Score = 3653; AVG = 87.8; Min = 43.8

The difference between the OGL AVG and the AVG of DXVK is inside error.

WineD3D on opengl is not insanely behind in performance.

To be fair, if this was CPU-limited then the native Linux build would win,

There is something else odd. CPU limited DXVK degrades faster than the WineD3D. You can see the odd where Linux native build it winning wined3d in second and DXVK in third. The fact you had to mention if this was CPU-limited were you aware of DXVK performance collapse in that case?

There are some very interesting performance differences between the two implementations. Enough that really both DXVK and Wined3d have to go forwards. One in the end will turn out to be the correct choice.

[cute2dgirl]

There is something else odd. CPU limited DXVK degrades faster than the WineD3D. You can see the odd where Linux native build it winning wined3d in second and DXVK in third. The fact you had to mention if this was CPU-limited were you aware of DXVK performance collapse in that case?

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

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?

I pointed because back then there were benchmarks in different DX11 games turning up with problems. There are still cases of wined3d on different games beating DXVK.

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.

[nuetzel]

Thanks!

That's great.

It's in master so I guess 19.1.
First point releases typically get out soon to fix some fallout.

19.2 (maybe 19.1.xx backport)

Was only commited 5 days ago.
19.1 was released 6 days ago.