How does it scale at 1440p and 4K?
Can’t say. The closest test i can do is use a higher resolution scale, but i’m not sure if that’s really a valid test.
Normally, the higher the resolution, the lower the CPU bottleneck, no?
It is interesting because it may mean that only a subset of DX12 extensions are responsible for the loss through VKD3D translation. This reminds me what I saw with Rebellion’s Strange Brigade and Sniper Elite 5, which have both VK and DX12 renderers. But only SE5, which is graphically more recent, shows a gap between VK and DX12. Assuming SE5 is an more evolved version of SB, it could suggest that more recently added extensions are the cause.
Are there any ways to test DX12 extensions one by one (or in small batches) in test software to dissect the problem?
Yeah but if you look at my previous AC Valhalla benchmark with Nvidia there’s quite a difference. Same system just different GPUs.
There’s also a vkd3d-proton benchmark from Windows there.
It’s in the old thread which didn’t get much attention.
Heck, it’s a year old now.
Sorry for being too late into the party. I guess i know why AMDGPU drivers are better on linux. Firstly AMD has a more simple driver which makes it much easier on cpu and gives edge in cpu bound scenarios. You all know how complex nvidia drivers i know im sure. Second one AMD was and now i mean always better in ASYNC computing than nvidia. Thats why vulkan and dx12 makes AMD shine. Right now i dont think nvidia will ever accept this, also we will never get a fix for this because its totally arch related. Im 4080 Mobile owner whos having like -%15 to +%15 performance difference in windows vs linux.
USE __GL_13ebad=0x1 env var.
RADV is open source and the devs have made amazing stuff., they’re also backed by Valve and even have people from AMD helping. So those devs can collaborate with other devs contracted by Valve, like vkded-proton.
RADV also have the ACO shader compiler which is very efficient.
What’s somewhat bad in RADV is RT performance but work is being done there, for now AMD owners can use AMDVLK which’s a bit better regarding RT.
There are too many things going on in a driver but i think one of the bottlenecks is that Nvidia perform bad with the shaders that DX12 usses.
VK_NV_raw_access_chains was specifically created to close the gap between Windows and Linux by making the DXBC shader code more efficient. However there is also DXIL shaders and I think that’s somewhat where the problem lies.
Though Nvidias Vulkan drivr is pretty amazing on Linux when running Vulkan games like RDR2, The Great Circle, Wolfenstein II etc
Omg, thank you for this. The BG3 Vulkan renderer ran really slowly ever since Patch 2 and I never figured out why. Never thought it would be the same issue as Indiana Jones and Doom Eternal. How come Nvidia hasn’t rolled out an application profile for BG3 like they did for those games?
I guess people didnt mention it enough as there is already a dx11 option that works as well, idk.
True, and initially this was introduced as a workaround only for idTech games. Seems that DX11/DXVK works better anyway, the native VK version being not optimal on BG3, even on Windows.
Yeah, the Vulkan renderer, despite now having the same performance with __GL_13ebad=0x1, seems to have weird frame pacing issues that are especially prominent when panning and rotating the camera. It is much smoother with DXVK. Not sure if that’s an Nvidia-only issue though.
You should try wine-wayland driver everything is 2 times more fluid on it.
According to Wine 9.22 Enables Wayland Driver By Default - Phoronix it was enabled by default from Wine 9.22. Is it not enabled in Proton Experimental then? If not, how do you enable it, via an envvar?
it is enabled but it’s not being used by default, it still uses xwayland by default.
I think you have to wait for proton 10 for an easier way to enable the wayland driver in proton, although you can still enable it in proton 9
it’s been great but i moved to a 9070XT and never been happier and my 4070 has been made a encoding/decoding card
Thanks. I did a search and saw there is an open issue on Proton Github: Plans to enable a native wayland driver · Issue #4638 · ValveSoftware/Proton Will keep an eye on it.
Use DISPLAY= env var to unset it. Then it will get forced to use wayland driver.
Thank you, I will try this. Hopefully they implement an explicit envvar for this (as described in the Github issue ticket).
not really sure BUT PROTON__WAYLAND=1 should enable it , correct me if im wrong