DXVK testing, auto-installer?

[emoose]

There's a lot of people that stick with the 2007 SourceNext port since it uses less resources, not really sure how much different it is (or whether the performance increase is due to less GPU or CPU usage), but AFAIK the performance difference is the main reason people have stuck with it.

It's been mentioned many times that DXVK can help with UHD performance quite a bit though, possibly letting more players run the UHD version at a more playable framerate (IIRC can give even better performance boost than #255 too)

Maybe some way of offering a DXVK download+install could be useful, could maybe just be exposed as a "Enable DXVK" checkbox in the UI, which could then download the latest DXVK release and unpack/copy it into place (and remove DLL if checkbox is unchecked) - I'd imagine the new updater code that was added recently could help with it too.

I'm not really sure how much DXVK has been tested with RE4 though, I know it definitely gives a performance boost, but not sure if there could be any side effects from using it at all, has anyone tried playing through the whole game with it yet, or have any experiences with it?

(kinda related to graphics APIs, recently came across https://github.com/encounter/aurora which implements the GX graphics API under WebGPU, so DX11/DX12/Vulkan/etc, redirecting the RE4 GX-emu api stuff to use that instead could maybe be interesting to explore, maybe could help with the inaccuracies around the filters, would likely take a lot of work though...)

[nipkownix]

Seems DXVK 2.0 now requires Vulkan 1.3, so I imagine any GPU that can run the latest version of DXVK would also not have any problems running vanilla RE4 without any performance issues?

DXVK devs don't really recommend using it on Windows. AFAIK, AMD drivers can be a bit broken with DXVK too. Perhaps linking/mentioning it in the readme would be better instead?

I'm not opposed to it, though. Maybe if we use v1.10.3 instead, which still supports older GPUs, we'd have fewer issues.

kinda related to graphics APIs, recently came across https://github.com/encounter/aurora

Oh, that is pretty neat! I wonder how much work it would take to use it. Hmm.

[nipkownix]

@emoose Could you test this dll and see if it loads correctly for you? ~dinput8-vk.zip~

I'm experimenting with integrating DXVK into re4_tweaks. Seems to be working surprisingly well here. ~(Although it is ignoring our EndScene hook for now, so no UI)~

Edit: Got the EndScene hook working: dinput8-vk.zip

Edit2: Interestingly, seems using the D3D9Ex path also works:

Not sure if there's any benefit to this, though.

[emoose]

Seems to work fine on RTX4080 (will be returning that soon and going back to GTX1080 for a little bit so will try it there too.)

What ver DXVK did you integrate btw? Also how did you decide to integrate it now anyway? Bit of a 180 from your last post :P

Meant to reply to that post sooner, you might be right that if they can run VK 1.3 they probably have no issue with DX9 neither, wonder if maybe GX->DX9->DXVK maybe ends up using less CPU time than GX->DX9 though, maybe could help with people that are running bad CPUs with good GPUs (lots of people only ever upgrade GPU, so it might be pretty common) Would think that the different layers of emulation would eat up more CPU though...

Interesting that 9Ex worked fine there, I guess DXVK's 9Ex doesn't mind using D3DPOOL_MANAGED pools.

[nipkownix]

RTX4080

~envy :p~

Good stuff. Thanks for testing!

What ver DXVK did you integrate btw?

1.10.3 with the async patch (in my dev tree, haven't uploaded/pushed that yet. will do soon in the wrapper_refactor PR)

The async patch (which the DXVK devs hate ~sorry doitsujin~), makes shader compilation asynchronous, removing shader compilation stutter that has been a problem in DXVK since forever. DXVK 2.0 added support for VK_EXT_graphics_pipeline_library, which aims to solve the same problem, but that only works with VK 1.3 (and not every driver supports VK_EXT_graphics_pipeline_library). Figured the async patch would be the best way to keep a wider range of compatibility for us.

My only concern with not using DXVK 2.0 is that we won't have the new texture unmapping feature, which lowers VRAM usage for d3d9 games. Not sure if the HD project will need that. Will have to test playing with the HD project quite a bit.

Also how did you decide to integrate it now anyway? Bit of a 180 from your last post :P

Ah, well, my main concern in my last post was the potential noise this could create for the DXVK guys. Integrating it into our codebase allows us to avoid that, and we can also hardcode DXVK settings if RE4 needs them :p

It also turns out that the whole "DXVK shouldn't be used on Windows" doesn't matter too much for d3d9. The bigger problem is with d3d11, from what I can tell.

Interesting that 9Ex worked fine there, I guess DXVK's 9Ex doesn't mind using D3DPOOL_MANAGED pools.

I did end up running into some weird issues when closing the game. Not sure if it is related to 9Ex, but I reverted to regular 9 and had no more issues. Could be worth another look though.

[RiasatSalminSami]

While async shader compilation seems to reduce stutters, if my experience with dolphin and rpcs3 is anything that represents async compilation, then the stutters are still there even if it's not that pronounced. As in, it's still noticeable.

In my opinion, dxvk should not replace it and be just optional feature for people that are having performance issues with d3d9. Cause on high end pcs, re4 on d3d9 seems to be almost stutterless locked 60 experience.

Also it's worth mentioning, to test the intensity of the stutters, we have to keep deleting the compiled shader files everytime. Otherwise on subsequent playthrough of the game, there won't be any stutters and some might think that the stutter issues are gone, while in reality, a fresh first time playthrough will have stutters everywhere.