Also sigh ;-)

Proton 6.3 Experimental has vkd3d-proton 2.2:
https://github.com/ValveSoftware/Proton/tree/experimental_6.3

It seems to fix a lot of things already (as the game now is generally working for me), and the black scenery bug isn't probably even exclusive to Nvidia, neither to Proton.

BTW: I didn't want to nag someone here. But I think it's important to have this as an anchor point for another (maybe game-specific) issue that remains, and maybe it helps other pinpointing the problem to some hardware/software/settings combination - or rule it out as a bug in vkd3d itself altogether. Since the problem also occurs on Intel Xe on Windows, it may just be another quirk of the RED Engine that either the devs could fix, or could maybe be worked around with some setting or vkd3d quirk handling. Also, this report is not meant to serve as an "fix this immediately now or I **** you" but rather as an offer in helping getting this fixed one or another way. vkd3d is impressive technology, given how well the game already ran at release on my aging PC. Kudos for that. And regarding all this hate against CDPR, I think the RED Engine itself is impressive technology given the scale of the game: I finally (as of CP77 1.21) had a chance to walk around in the game/city simulation, and I've seen no performance issues, most day-1 glitches are gone, and immersion is great (ambient sound, lighting, everything feels like walking in a real living city). Having this running on Proton/vkd3d in this state: Simply wow. Looking forward to future improvements by the vkd3d devs. Take your time, I'm patient.

Looking forward to future improvements by the vkd3d devs.

TBH, I get @doitsujin's point and I'm looking forward to future improvements from CDPR first. It has gotten better since patch 1.2, to an extent that the game is now actually playable IMHO, even on Nvidia, but most likely a lot of the bugs we are still currently seeing are only worked around by vkd3d-proton on AMD. It should get better when/if mutable_descriptor_type is implemented by Nvidia, but the game engine is still known to have problems - this is not something others can magically fix.

It has gotten better since patch 1.2, to an extent that the game is now actually playable IMHO, even on Nvidia

Yes, that's true, and from the history of bug reports and comments (also in the Proton tracker), I'm totally with you that the engine still has a lot of problems. But I fear that once it's fully stable on Windows via changes made by CDPR, it may still have a lot of bugs that become just apparent by using vkd3d, so you'll probably have to ship with silly work-arounds anyways - it's a pity but probably just the way it is being a different implementation with different stacks and memory layouts. But you are right: First things first, make it work properly with open source drivers as this is the only way to stay sane while inspecting problems, and then we'll look at NVIDIA again (they lately added a few more extensions again, so let's wait and hope).

I can support your argument because it needed both an vkd3d update to 2.2 and the game patch 1.21 to have this fixed for me. Patch 1.2 was still freezing for me while others reported it works for them. There's still a lot to do for CDPR. Until then, there are lots of other games that work and can be played (and finished) until then. ;-)

I just came here because it was suggested to report this upstream to vkd3d-proton, feel free to close if you think it makes your work easier. I wouldn't complain about a locked up game here because that is already covered, and given the latest changelogs, this is probably mostly a memory managing issue who everyone is already working on. But I was seeing this as a completely different issue, not a stability issue but a rendering issue. If this is already known and doesn't need any tracking, please also close.

There's another report (this time for Linux) in the CDPR forums which suggest the bug may not exist for older NVIDIA cards (GTX 1060): https://forums.cdprojektred.com/index.php?threads/some-quests-are-with-black-screen.11083618/

Another comment says that REDengine is using "different kinds of light" in some interiors.

Does this make any sense to the vkd3d devs? Maybe a temporary work-around could be to blacklist some extension because the linked thread implicitly suggests that the bug didn't occur on older GPUs.

Hi,

There is a working workaround you can use until the problem is being solved.
When you are using the scanner, a "greenish" filter is applied and you can see in those areas.

There is a way to toggle this filter without having to be in "scan mode"

For that, you need to use the lua console provided by the Cyber Engine Tweaks (https://wiki.cybermods.net/cyber-engine-tweaks)

• Follow the instruction to install it : https://wiki.cybermods.net/cyber-engine-tweaks/getting-started/installing
• During the game, you will have to use the following command :
  Game.GetPlayer():GetHudManager().visionModeSystem:EnterMode(Game.GetPlayer(),1)

This will force the game to display the "greenish" overlay, but without the scan UI, you will be able to play normally.

Note that if you jump or run, the mode will go back to 0. It means you will have to make a function that calls that command periodically. If I do it, I will share it here.

Now it would be interesting to understand why the "greenish filter" makes the issue disappear ...

Hope that it helps.

Here it is !

It is quite an ugly inelegant hack, but at least it makes the game playable ...
After installing Cyber Engine Tweaks, create a file called init.lua in the following folder :

Cyberpunk 2077/bin/x64/plugins/cyber_engine_tweaks/mods/black_screen_workaround/

Here is the content of the file :

local workaroundEnabled=false
local bs_wk_count = 0;
registerForEvent("onInit", function()
               
end)

registerForEvent("onUpdate", function(deltaTime)
    if (workaroundEnabled) then
        bs_wk_count=bs_wk_count + deltaTime
               
        if ( bs_wk_count > 0.2 ) then
            Game.GetPlayer():GetHudManager().visionModeSystem:EnterMode(Game.GetPlayer(),1)
            bs_wk_count = 0;
        end
    else
        if(bs_wk_count > 1000) then
            Game.GetPlayer():GetHudManager().visionModeSystem:EnterMode(Game.GetPlayer(),0)
            bs_wk_count=0;
        end      
    end
end)

registerHotkey("bs_workaround_enable", "Activate/Desactivate Black Screen Workaround", function()
    workaroundEnabled = not workaroundEnabled
end)

registerForEvent("onDraw", function()
    ImGui.SetNextWindowPos(300, 300, ImGuiCond.FirstUseEver)

    if (ImGui.Begin("Black Screen Workaround")) then              
            if(workaroundEnabled) then
                ImGui.Text("Status : enabled.")
                clicked = ImGui.Button("Disable Workaround ")
            else
                ImGui.Text("Status : disabled.")
                clicked = ImGui.Button("Enable Workaround")
            end
        if (clicked) then
            workaroundEnabled = not workaroundEnabled
            if (not workaroundEnabled) then
                bs_wk_count=5000
            end
        end
    end
    ImGui.End()
end)

@RenaudMuller Interesting find... I'll probably try that in the weekend.

Sounds like a game engine bug then? And most Windows drivers just ignore that HDR part anyways? FWIW, I didn't enable HDR in the game options, given that HDR is disabled for me anyways, I couldn't even enable it.

But great that you found at least some hint finally. Thanks for looking into it. :-)

BTW: The Windows Intel Xe drivers seem to show the same bug as I linked further above, so something may be missing in the driver implementation.

This makes you my hero of the day! :tada: