protonscr

Update README?

dxvkclosed
doitsujin/dxvk#241 · opened 2018-04-04 by SveSop · updated 2018-04-15 · 22 comments · github
SSveSop 2018-04-04 github

Just wondering if there are some new options to use that don't require reading the commit messages and figuring out how to do stuff?

The package-release.sh script was nice... when i found it.

There is also some regression with (i think) the "DISABLE_DO_NOT_WAIT" flag from https://github.com/doitsujin/dxvk/commit/4e84a778965235b7d9f6489f0e89ef3947395096 but i cant figure out how to turn it on with some option from the command line or something... Or is it not supposed to be like that? :)

Sorry for asking stupid questions, but tend not to read every commit unless something is not working as i expect.

Did some benchies with Unigine Heaven, and found wine-staging-3.5 > DXVK.

Wine - 85.4 fps (2150) 20.1/159.8
DXVK - 78.1 fps (1968) 28.7/156.7

Pulled https://github.com/doitsujin/dxvk/commit/53d557c2db9e51c98696840e19aced94687be0ea and got:
DXVK - 82.1 fps (2068) 17.1/158.3
Not sure if it is that or not tho, but if there is any "hidden knob's" i could try, it would be nice to know :)

Ddoitsujin maintainer 2018-04-04 github

There's currently no way to enable that other than hacking the code. I plan to support that through either configuration files or environment variables in the future.

Also it's not unusual for wined3d to be faster in Unigine benchmarks since they tend to be GPU-bound even at low resolutions. That does not reflect actual game performance however.

SSveSop 2018-04-04 github

Ah oki.. Just wondered since it kinda was described as "knob to turn"... Does adding:
{ "Heaven.exe", D3D11OptionSet(D3D11Option::AllowMapFlagNoWait) },
to options.cpp and recompile enable this then?

The "PBA" patchset is still a lot faster than DXVK even in gaming, but it might not always be true, especially if you end up in a situation where you get CPU bound as DXVK tend to use less cpu than wined3d.

Zzefkerr 2018-04-04 github

The "PBA" patchset is still a lot faster than DXVK even in gaming, but it might not always be true, especially if you end up in a situation where you get CPU bound as DXVK tend to use less cpu than wined3d.

The "PBA" patchset is still a lot SLOWER than DXVK in gaming.
But with DXVK does not run some games that simultaneously use a mixture of different APIs, such as d3d9, d3d10 and d3d11, for example, World of Warcraft. If DXVK could launch such games, then the PBA would not be completely needed.

Ppingubot 2018-04-04 github

depens on the game...pba outoperforms dxvk heavily in d3 the last time i tried, in crysis 2 dxvk is twiche as fast , partly 3 times as fast as pba..

SSveSop 2018-04-04 github

Did not produce any changes by tweaking/adding that line in d3d11_options.cpp.. so i guess i need more than that perhaps? :)

Zzefkerr 2018-04-04 github

depens on the game...pba outoperforms dxvk heavily in d3 the last time i tried, in crysis 2 dxvk is twiche as fast , partly 3 times as fast as pba..

Diablo3 uses d3d9 as far as I know, not d3d11. Therefore, the PBA, of course, will be faster for D3 than DXVK.

Ddoitsujin maintainer 2018-04-04 github

@SveSop Yes, that will work.

Originally I intended to make this particular knob opt-out rather than opt-in, but it broke more games than expected (e.g. Path of Exile).

especially if you end up in a situation where you get CPU bound as DXVK tend to use less cpu than wined3d.

Well, that's the whole point of DXVK.

Sshmerl 2018-04-04 github

The "PBA" patchset is still a lot faster than DXVK even in gaming

Not for the Witcher 3. I didn't manage to get acceptable performance in TW3 with PBA, while dxvk gives 60+ fps for me.

SSveSop 2018-04-04 github

Yeah, i guess benchmarking synthetics is not everything :)
Benched some Talos Principle.

Vulkan (Linux)   - 107.5 fps
Vulkan (Windows) - 87.5 fps
DXVK             - 84.4 fps
PBA              - 58.8 fps (Bugged)
Wined3d          - 47.2 fps (Bugged)

Regular wined3d and pba-wined3d was not able to render Talos, as it was just bugged/missing textures and whatnot...
Close between vulkan and dxvk under wine tho :)

SSveSop 2018-04-04 github

@doitsujin I tried that, and even setting AllowMapFlagNoWait = 1, in d3d11_options.h, but no change.. Must be something else that lost me 4 fps in Heaven :)

Gonna see if i can try some more builds to pinpoint what commit changed something.

Ppingubot 2018-04-04 github

@SveSop : Not sure if your step works, i hope it helps what i did, patch file attached (i am in no way a programmer, so i can no guarantee that this completely enable the MAp Flag no wait).
If you have an nvidia card, it is worth to try to revert 5eedbc0, the option has a noticeable perf impact on my gtx 970, especially in gpu bound scenarios.

flagnowait.patch.txt

SSveSop 2018-04-05 github

@pingubot Was planning on looking into that patch.. :)
Did so, and reverted it with previous..
Valley w/32Bit Depth buffer (Git)
DXVK - 84.6 fps (3540) 35.4/157.8
Valley w/24Bit Depth buffer (Revert: https://github.com/doitsujin/dxvk/commit/5eedbc0546fa2797379f4da40e586e535738785b )
DXVK - 88.1 fps (3686) 36.5/161.7

Tested heaven too.

DXVK - 82.3 fps (2072) 29.0/157.6 (24b DBuf)
DXVK - 78.1 fps (1968) 28.7/156.7 (32b DBuf)

And with "Extreme tesselation"

DXVK - 65.9 fps (1659) 8.9/150.7 (24b DBuf)
DXVK - 63.8 fps (1607) 22.7/146.3 (32b DBuf)

Was no change in Talos Principle benchmark with or without this patch.

Dunno... is it worth a "if nVidia" quirk, or is it just visible for "synthetic benchmarks" you think? If anyone else want to test for nVidia, attaching patch that will revert https://github.com/doitsujin/dxvk/commit/5eedbc0546fa2797379f4da40e586e535738785b to what it was before.
0001-Revert_24_bit.patch.gz

Ppchome 2018-04-07 github

@doitsujin

I plan to support that through either configuration files or environment variables in the future.

https://github.com/brofield/simpleini

Ppingubot 2018-04-08 github

@SveSop : for me the perf diff is noticable in crysis2/3 and fear 3 (~ 10-15%)

SSveSop 2018-04-15 github

Since stuff changed a couple of patches back, i hacked together a patch that sets 24bit Depthbuffer in the dxgi_format.cpp file.

Same performance differences between 24 and 32 bit for me in Heaven/Valley. Are there absolutely no performance difference if you run a AMD card with 32bit depthbuffer? And only nVidia that gets somewhat slowed down by this?
0001-Allow_24_bit_Depthbuffer.patch.gz

Ddoitsujin maintainer 2018-04-15 github

@SveSop 24-bit depth buffers are deprecated on AMD hardware and neither RADV nor AMDVLK expose support for them, which is why they aren't used.

There were a couple of issues with them on Nvidia as well but with the (somewhat) recent work on how images are created, it might be possible to bring them back without messing things up - I'll have to check that though.

SSveSop 2018-04-15 github

@doitsujin If 24-bit depth buffers is "not available" on AMD hardware, how come the driver does not choose another format?
Am i to understand this "format list" in dxgi_format.cpp "translates" DXGI_FORMAT -> VK_FORMAT? And if so, is DXGI_FORMAT_D24_UNORM_S8_UINT supposed to be VK_FORMAT_D24_UNORM_S8_UINT, but this is not working for AMD drivers.. so you "force" this to work by saying DXGI_FORMAT_D24_UNORM_S8_UINT -> VK_FORMAT_D32_SFLOAT_S8_UINT?

Why would AMD driver request to use DXGI_FORMAT_D24_UNORM_S8_UINT or any of the other R24/X24 type of formats?

Ddoitsujin maintainer 2018-04-15 github

@SveSop what do you mean by this:

Why would AMD driver request to use DXGI_FORMAT_D24_UNORM_S8_UINT

If an application creates a depth texture with DXGI_FORMAT_D24_UNORM_S8_UINT, the underlying Vulkan image will use VK_FORMAT_D32_SFLOAT_S8_UINT because the 24-bit one is not available. The Vulkan driver obviously has nothing to do with the D3D11 texture formats.

SSveSop 2018-04-15 github

@doitsujin Is it cos there is no such thing as D32_SFLOAT_S8_UINT when it comes to DXGI_FORMAT then?
Closest perhaps DXGI_FORMAT_D32_FLOAT_S8X24_UINT? I dont know.. What determines what DXGI_FORMAT the application uses? The way the application is programmed? And in windows AMD drivers support DXGI_FORMAT_D24, while in Vulkan does not support VK_FORMAT_D24?

Ddoitsujin maintainer 2018-04-15 github

What determines what DXGI_FORMAT the application uses?

The application.

And in windows AMD drivers support DXGI_FORMAT_D24

Yes, because D3D11 requires it. Vulkan doesn't.

SSveSop 2018-04-15 github

Well.. not claiming to know how those formats gets moved around in memory, but 24 bit < 32 bit when it comes to bandwidth used no? So in theory the reason nVidia gets more performance from using24 bit is cos it requires less bandwidth of some sort, and if AMD had supported the same, possibly more performance there too? :)

And.. it is somewhat a byproduct of using wine with d3d11 -> vulkan translation, cos there are no "real" vulkan apps that actually uses 24 bit formats (even tho it IS a format), since AMD in their ultimate wisdom has chosen not to support it.. correct so far? :)

Ddoitsujin maintainer 2018-04-15 github

As for the first part, having 24-bit depth buffer precision doesn't mean that it only requires 24 bits in memory. Second part: Yes.

Anyway, I'll close this now due to off-topic discussions.

Nothing extracted yet.