I was able to play this game with Vulkan renderer at 440 series drivers just fine. But with 450.66 driver and newer releases (i’m on 455.45.01 now and problem still exists) it has visual corruptions all over the place. Game doesn’t have any of those mentioned/shown issues with OpenGL renderer and id Software’s embedded performance metrics shows with OpenGL renderer driver reports VRAM as 4096 mb like it should be , but with Vulkan renderer it reports 4342 mb’s of VRAM.
I’m running the game via SteamPlay/Proton 5.0 on an Optimus laptop with these variables:
So at further investigation , i captured some faulty frames with Renderdoc. I will attach them here.
“directional occlusion” pass setting from the advanced settings menu of the game is the culprit. When it is on ( set to low , medium or high ) and any of the anti aliasing modes that involves usage of compute shaders ( like TAA , TSSA) are set , nearly everything is black , menu also flickers.
When “directional occlusion” pass is set to on but AA modes that doesn’t involve compute shader usage like FXAA , SMAA everything looks ok.
This one says custom but it is just high preset+ Anisotropic is set to 8X. On high settings preset , it is set to 4x by default.Setting it to 8X makes it “custom”
Enabling/disabling usage of compute shaders ( it has an option for it at advanced options menu ) sometimes affects flickering issue that happens in main menu but that flickering is not always reproducible unlike the main issue i reported.
1-) My setup:
I didn’t mess,configure any Xorg.conf. Retrieved these from usr/share/x11
As a last note , ( not sure if it makes any difference or sense ) but a screenshot from NV x-server settings. I wonder why it says X Screens:Screen 256 and Display Devices:None
the render is broken on my system too 1050 4GB only in offload mode
i you swtich to nvidia only the game will become playable so it’s an issue with nvidia offload(and maybe the 1050 4GB) and not whole render
With another Nvidia user ( Pascal GTX 1060 desktop) we are able to reproduce the issue.
To put it simply ; on Optimus setups app profiles doesn’t seem to be applying.On a desktop system (or any other unaffected system) modifying binary driver as to look for randombinary.exe instead of DOOMx64vk.exe will reproduce the issue. This behaviour also explains why issue below happens too. Same issue.
While i didn’t try this yet ( not at home currently) i would expect result to be same ( problematic) because in this state i would have to point nvidia icd to game in order to utilize NV gpu with it. Doom 2016 doesn’t offer any gpu selection and uses first available adapter. Which on many up to date multi gpu systems that means either using igpu or lavapipe. Which pointing out NV icd should have similar result to what NV only optimus layer does.
@aplattner So, does NV QA people were able to repro and spot the root cause for this issue?
It seems like this issue is kinda widespread and on affected systems ( it does affect desktop systems too ) it causes any app specific driver workaround to not apply.
So more than a Doom 2016 specific problem, it is a general issue.
I can confirm issue got fixed on my end with 470.42.01 driver.
Running the game with Vulkan backend and _NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only
on on-demand mode ( Prime render offload,hybrid ) doesn’t have visual issues posted above.
It is weird why a GL var caused it tho. Is there any explanation about why this bizarre issue happened? And it would also be weird if this is also only limited to most Prime render offload systems and some desktop systems too. On a desktop, NV only system __GLX_VENDOR_LIBRARY_NAME=nvidia also should be passed by driver itself.
It’s an app profile thing, fixed by this entry in the changelog:
Fixed a bug that could prevent the driver from applying application profiles when running applications through Proton or Wine on a PRIME Render Offload configuration.
I know, with another user we already reached to that conclusion and also possible solution idea came from that.
I just wanted to know why this issue was somehow specific to some systems ( for example Amrits here was not able to reproduce any of those issues with similar setups ) and how this same issue affected this person who claims he is on a desktop system.
The changelog description calls out PRIME Render Offload because that is the primary use-case where users would be expected to specify __GLX_VENDOR_LIBRARY_NAME=nvidia. The solution will take care of the issue for all affected configurations, even those without PRIME Render Offload.
