Retroarch: Vulkan video driver in fullscreen on GeForce Driver 387.92 causing black screen

[WhiteZeroX]

Description

With the new nVidia GeForce 387.92 video driver, the RetroArch Vulkan video driver only displays a black screen when starting any emulator. This only occurs in fullscreen mode. If you run in Windowed mode or alt-tab out of RetroArch and back in, then you'll get an image again (unless you change a resolution setting in the emulator causing the video driver to initialize).

nVidia's driver release notes say the following relating to the issue:

Implemented improved behavior for full-screen Vulkan swapchains using
VK_KHR_win32_surface.

This optimization will cause more events that trigger an out-of-date swapchain, such
as when entering or leaving full-screen mode (typically by pressing Alt+tab).
Applications that do not properly respond to the VK_ERROR_OUT_OF_DATE_KHR return
code may not function properly when these events occur. See the WSI Swapchain
section of the Vulkan specification.

Other users reporting the issue here: https://forums.libretro.com/t/vulkan-full-screen-broken-with-new-nvidia-drivers-387-92-win10/12691

Expected behavior

Video to be displayed normally.

Actual behavior

Screen goes black when starting any emulator

Steps to reproduce the bug

1. Install nVidia Geforce Driver 387.92
2. Start any emulator in-game
3. Experience the black screen
4. Exit Fullscreen or simply alt-tab out and back in to get the image back

Bisect Results

Only occurs with 387.92 and up nVidia driver. Rolling back to 385.69 works fine.

Version/Commit

• RetroArch: 1.6.3 - 1.6.7

Environment information

• OS: Windows 10 64-bit 1703 (Creators Update)
• HW: GeForce GTX 1070

[elcorsico]

yeah idem for me , vulkan test psx hardware and genesis
sound ok but black windows
thanks resolve this devs ;-)

[SL-Gundam]

I'm having the same issue with 3dmark's API overhead test so this is might be a driver bug

[daninthemix]

Yep, I've noticed this too. It's a double-problem because (at least for me), the GL driver now runs at a crawl on the Fall Creator's update, so I was hoping to use Vulkan but this issue makes that excessively irritating.

[elcorsico]

hi all,
for information , new driver nvidia 388.00 are problematic vulkan core
genesis and psx in vulkan mode , black screen too and music are play
why the bug are resistant , thanks devs for resolve this ;-)

[WhiteZeroX]

Someone added in the Forum thread the following console output:

[INFO] [Vulkan]: VSync => on [INFO] [Vulkan]: QueuePresent failed, invalidating swapchain.

So that would seem to jive with the nVidia Release Notes about swapchains.

[fxgopher]

Same issue here - Latest Nvidia - and latest updated nightly and upto date cores

[fxgopher]

Mines a Strix 1070 Same Windows and Drivers. If I switch to Open GL everythings fine, but Vulkan is a definite no no - Bloack screen for graphics - can hear audio though (PCI-E Soundblaster)

[WhiteZeroX]

@twinaphex is that with both the Vulkan driver and a vulkan enabled emulator? The issue will only occur when actually starting a vulkan enabled emu. Can/have you tested BeetlePSX specifically?

[fxgopher]

I use the following cores
parallel_n64 and mednafen_psx_hw With Vulkan as driver black screens for 40 Winks and Yoshi's Story.

I switch driver to GL and they both play fine

[twinaphex]

Yes I was able to reproduce the issue.

And it seems this is an error introduced by Microsoft. See this -

https://twitter.com/idSoftwareTiago/status/925770870978744320

If you are part of the Windows Insider program, you could download the latest beta versions and test if the issue is gone. If not, you'll have to wait for the next Windows update for these issues be resolved. Doesn't seem like there is much we can do about it ourselves - it's a regression Microsoft introduced into the latest stable update.

[WhiteZeroX]

@twinaphex Thanks again. It looks like this fix is part of the November Windows 10 Cumulative Update. I will update Windows and my driver tonight to test and report back.

[WhiteZeroX]

Hmmm, still seem to have the same issue after updating to the new Windows patch and nVidia driver (388.13). So for now I'm just switching back to OGL for Driver and emu output.

[saftle]

@WhiteZeroX Could you see if the problem is fixed with the new Nvidia 388.31 update along with the November Windows 10 Cumulative Update? I saw someone in the #libretro discord that said they fixed it by updating to the newest driver.

I can't test it myself, since i'm on Windows 10 LTSB "1607". However, if it works for you, I might temporarily switch back to regular Windows 10 Pro until the new version of Windows 10 LTSB comes out in 2019.

[Tomk3n]

Even with the newest updates it doesn't work.

[matsmith83]

I'm still having the issue with new Nvidia 388.43 drivers, and Windows 10 Pro 64-bit (Version 1709 OS Build 16299.64).

[ghost]

Yeah, I just came here to ask about this and found this bug thread. I have the November Windows 10 update and latest GeForce drivers but I'm still seeing this. Are we !00% sure this is actually related to the Windows 10 regression?

[WhiteZeroX]

Since most of us are still having issues after updating, I think we can say that the tweet from @twinaphex above didn't apply to our issue.

[SL-Gundam]

I think the post from @twinaphex might still apply.

The changelog entry being mentioned is not present in the november updates for 1709 (16299). As far as i can see the fix is only present in the 17025 insider build. Somebody willing to test that?

[WhiteZeroX]

@SL-Gundam The non-Insider changelog mentions:

Addressed issue that causes a black screen to appear when you switch between windowed and full-screen modes when playing some Microsoft DirectX games.

And the above tweet from @idSoftwareTiago for the (older) Insider update says:

"We fixed an issue where toggling some DX9/DX10/DX11 games between windowed and fullscreen (for example using Alt + Tab) could result in the game window become black on certain PCs.)" That also includes Vulkan btw.

The change is almost word-for-word and, assuming the id employee is correct, included Vulkan.

[saftle]

Those of you on the newest Windows update and nvidia driver version 388.43 (that just released today), do you mind switching to exclusive full-screen (video_windowed_fullscreen = "false") with Beetle PSX HW to see if that fixes the issue?

Just talked to someone on discord, saying that the problem is fixed when using exclusive full-screen. Thanks!

[ghost]

No such luck here. I'm also not entirely sure why specifically the beetle hw core, considering this seems to happen on _all emu cores as long as the general video driver is set to vulkan_.

Only "fix" so far is to either exit fullscreen or alt+tab out and back in as described in the first post.
Or alternately just use gl (video_driver = "gl") for the time being, which is what I'm doing.

[saftle]

@Hampster82 this is true, it affects all cores. I just wanted to isolate a few things in order to potentially reproduce them.

[matsmith83]

Those of you on the newest Windows update and nvidia driver version 388.43 (that just released today), do you mind switching to exclusive full-screen (video_windowed_fullscreen = "false") with Beetle PSX HW to see if that fixes the issue?

Made no difference for me, sadly.

[rayabusa]

This is happening to me too, and when i alt+tab the game, it suffers from slowndown while playing Tekken 2 on beetle PSX HW core, this wasnt happening before.

[twinaphex]

Unfortunately it doesnt seem like there is anything we can do about this. Microsoft broke this in their updates, id Software’s own devs complained about it too.

Either way, it still works fine on Linux, showing our code is not the issue.

[WhiteZeroX]

Forgive me here, but if it was solely a Windows issue, why is RetroArch the only Vulkan application I'm having this issue on? Loaded up PPSSPP standalone today with it's new Vulkan render and I can fullscreen and alt-tab without issue. Downloaded vkQuake (Quake source port with Vulkan renderer), works fine going between exclusive fullscreen or boarderless windowed and alt-tabbing.

If Microsoft "broke" something that no other application seems to have an issue with under the same circumstances, it sounds to me more like an issue with that single application not conforming to standards. Maybe I'm way off on this, just how it's seeming.

I did tweet to @idSoftwareTiago again to ask if they were still seeing any issues in their games.

[WhiteZeroX]

I also don't think we can rule out the tweet/Insider patch as a red herring here, either. Our issue is specifically with Vulkan, not D3D. While sounding similar, I think the issues may be just that, similar but unrelated. As the blog post/changelog details that the issue occurs when "switching between fullscreen and windowed or alt-tabbing," while our issue occurs without any switch at all and in fact alt-tabbing alleviates the problem temporarily. We have a specific "swapchains" trace in logs that relates back to the nVidia driver release notes regarding Vulkan.

Our issues started after a nVidia driver update, not a MS update, and the "related" MS fix that did get applied had no affect for us.

[WhiteZeroX]

Forgive me here, but if it was solely a Windows issue, why is RetroArch the only Vulkan application I'm having this issue on? Loaded up PPSSPP standalone today with it's new Vulkan render and I can fullscreen and alt-tab without issue. Downloaded vkQuake (Quake source port with Vulkan renderer), works fine going between exclusive fullscreen or boarderless windowed and alt-tabbing.

If Microsoft "broke" something that no other application seems to have an issue with under the same circumstances, it sounds to me more like an issue with that single application not conforming to standards. Maybe I'm way off on this, just how it's seeming.

I did tweet to @idSoftwareTiago again to ask if they were still seeing any issues in their games.

EDIT: Accidentally clicked Close issue...

[WhiteZeroX]

An id Engine Programmer just had this to say:
https://twitter.com/axelgneiting/status/937007261565837314

vkQuake has fixes for the swap chain issues on NVIDIA if that's what you are looking for. While minimized you are not able to create a chain & you can loose it on acquire/present.

vkQuake's commits are full of swapchain fixes.

[twinaphex]

This might indeed help us. Also, we added a $50 bounty for this on Bountysource.

https://www.bountysource.com/issues/50358623-vulkan-video-driver-in-fullscreen-on-geforce-driver-387-92-causing-black-screen

[WhiteZeroX]

@twinaphex Thanks. Putting my money where my mouth is with $25 to the bounty.

[saftle]

I can confirm that it is solely a Windows 10 issue. I just downgraded to Windows 8.1 and Vulkan works as it should.

[Fergdog]

The id engine programmer said this when he patched vkQuake to work with Nvidias newer drivers:

"Swapchain fails to recreate while a fullscreen app is minimized. Surface capabilities return 0 width/height. Also acquire/present fail with out of date when going out of fullscreen. All is valid according to spec."

https://twitter.com/axelgneiting/status/931356379121704960

Similar to what's said above but a lil more info.

It looks like this is not Microsoft's fault but a change in Nvidia's Vulkan swapchain that everything needs to adapt to.

[twinaphex]

From what I can ascertain, this is the commit that fixed it for vkQuake -

https://github.com/Novum/vkQuake/commit/c8906260d6061d31d4890c813ec720592586d329

Just ignore all the asserts which is just a debugging measure.

[twinaphex]

Tried replicating what was being done in that commit but the issue still persists -
https://hastebin.com/obasamayoj.php

[twinaphex]

More discussion here -

https://github.com/Novum/vkQuake/issues/114

[twinaphex]

Apparently the gist of it is that we need to handle extra error codes that vkAcquireNextImage can return -

VK_ERROR_OUT_OF_DATE_KHR
VK_SUBOPTIMAL_KHR

If it doesn't return VK_SUCCESS, then it seems vkCmdBeginRenderPass/vkCmdEndRenderPass shouldn't be ran, neither should vkQueuePresentKHR be called. Tried messing around with this but maybe I overlooked some parts.

[Novum]

Everything that uses the not acquired swap chain can't run, that's correct. You will also need to handle the case where you are minimized and cannot create a swap chain at all until maximized again.

[twinaphex]

Hi there @Novum, thanks for dropping by and shedding some more light on the issue. I believe @Themaister is working on a solution in his fork.

[hyarsan]

I just updated to driver 388.59 ( Windows 10 Fall Creator's Update like before ) and have this very exact problem. Control + Alt + Delete seems to fix it. So Microsoft isn't the one to blame here.

[WhiteZeroX]

Saw RetroArch 1.7.0 was out with this change:

VULKAN: Various stability fixes for WSI

But alas, I'm still having the same problem.

[twinaphex]

I reported the issue to Nvidia. It's the Nvidia Windows driver's fault. It does not happen with Intel GPUs and it doesn't happen with the same nvidia GPU on Linux (latest drivers).

[WhiteZeroX]

@twinaphex I thought we addressed that concern above? Specifically from @Novum (Axel Gneiting), an engine programmer at id and author of vkQuake...

His tweets on the matter:
https://twitter.com/axelgneiting/status/937007261565837314
https://twitter.com/axelgneiting/status/937026728010158080

[twinaphex]

@Themaister says he already backported any relevant fixes, and the issue still persists. There is no issue at all on Linux with the latest nvidia driver, there is no issue with an AMD GPU on windows, there is no issue with Intel IGP on Windows 10. So it might be a bug in nvidia's windows driver.

[Novum]

It's not a bug. Only NVIDIA on Windows exposes this behaviour. It's valid according to spec.

vkQuake is working fine now, you have to make sure you get all the corner cases right.

[twinaphex]

I think the conclusion then is that @Themaister does not know right now how to fix it then, or more specifically, which edge case needs to be attended to.

[Novum]

Does he have a NVIDIA card to test with? Otherwise it's going to be hard to explain.

[twinaphex]

I am not sure. In his latest commits, he told me he tested it on AMD (Windows/Linux) and that it worked without any issues.

These were the latest commits he pushed -

https://github.com/libretro/RetroArch/commits/master?author=Themaister

[WhiteZeroX]

Get me an Windows binary and I'll be glad to test potential fixes.

[twinaphex]

@WhiteZeroX Not sure really what you mean by that, our buildbot runs in real-time and spits out nightlies for each and every commit that gets pushed. So this request seems almost moot, just go to our buildbot nightlies site...

http://buildbot.libretro.com/nightly/

For the most full-featured Windows build, you'd use the 'windows' one which is built with mingw, not the MSVC ones.

[WhiteZeroX]

Wasn't sure if the commits you mentioned were on the main branch or not. I'll give the nightly a try later, unless it's already part of 1.7.0

[twinaphex]

@WhiteZeroX Again, I'm not sure what you're talking about. Maybe you should take a back seat in this conversation, no relevant commits have been pushed yet relating to this issue since 1.7.0. We indicated before we are stuck here. I am not sure to which degree @Themaister is monitoring this situation.

[ghost]

I'm guessing @WhiteZeroX meant that in case @Themaister doesn't have a Windows+Nvidia setup he can test his branch on, providing a test build for us here in the comments is a viable option.

[WhiteZeroX]

@twinaphex Don't get me wrong, I'm not supposing that a fix exists already and I'm not entitled to a speedy resolution either. I was simply trying to clarify if there was anything done on the nightlies that didn't make it into 1.7.0. But as you've now explained, there is not. No reason to be condescending here, I'm just offering to test potential fixes since I have the affected hardware and OS. I apologize for not being the most well versed in parsing commits on Git. But I can see now on @Themaister profile page that I can check when he makes new commits, then I can grab them from the buildbot and give them a try, assuming any are made in the future from him on this.

[Novum]

It's not a driver issue. I fixed this in idTech for Wolfenstein II and personally in vkQuake after conversations with NVIDIA. It's by design.

Is there an easy way to compile retroarch on Windows and test this? Without having to install dependencies for a day etc?

[bparker06]

Hi @Novum, we have a step-by-step guide here:

https://docs.libretro.com/compilation/windows/

[twinaphex]

Hi @Novum,

right now the MSVC solutions we have don't have HAVE_VULKAN defined, so I recommend you follow the Msys2/mingw guide instead. It should be quite trivial - you only need msys2/mingw installed and then follow the guide @bparker06 linked to.

There should be no real dependencies you need to manually install. The dependencies that are required for RetroArch are baked into the repository and get baked into the binary as well. We have gone to great lengths to avoid the sort of dependency hell you see elsewhere and make compiling and installing RetroArch as painless as possible.

Thanks BTW for wanting to help, it is something we certainly cannot take for granted so I want to thank you personally for this.

[tabnk]

GTX 960 with Nvidia 388.71 Drivers and Windows 10 Fall Creator.

Same issue on latest 1.7.0.

[Fergdog]

It's not gonna be fixed until someone with a good understanding of nvidias vulkan drivers helps out. I'm hoping Novum or someone like him finds the time to take a look at it.

[elcorsico]

GTX 1070 with Nvidia 390.65 Drivers and Windows 10 Fall Creator.
Same issue on latest 1.7.0.
please dev fix it , Thanks

[twinaphex]

Hi there @Novum,

I have made it possible now to compile RetroArch with Visual Studio 2017 (with Vulkan support), so you no longer need to setup MSYS2/Mingw.

Just use the current git master, go to pkg/msvc, and open RetroArch-msvc2017.sln. You can use any of the configuration targets - Debug, Release, Release Cg, it doesn't matter.

Hopefully with this I have made testing this issue as effortless and painless for you as possible. I did have to stub out glslang support but I believe in order to test this bug you don't really need that.

[Novum]

Okay let me try that.

[Novum]

Is there anything special I have to do to provoke the error?

video_windowed_fullscreen = "true"
video_driver = "vulkan"

With that set it runs in fullscreen and I can alt+tab just fine. But I'm also not getting any swap chain lost errors from Vulkan in vulkan_acquire_next_image, which tells me I'm somehow not in real fullscreen?

(Just to make sure, I also tried vkQuake and I'm still getting the surface lost errors there)

[WhiteZeroX]

@Novum Try toggling between windowed and fullscreen (F by default) or starting an game in an emulation core. This triggers the black screen for me reliably.

[Novum]

Can confirm. Thanks.

[Fergdog]

I'm not sure if it makes a difference, maybe fixing one fixes both but when going fullscreen:

video_windowed_fullscreen = "true" = windowed fullscreen
video_windowed_fullscreen = "false" = exclusive fullscreen

[twinaphex]

BTW @Novum,

just thought I should mention this just for curiosity's sake - we have a Tyrquake libretro core as well (Quake source port).

To try it, you could either compile it yourself (hard way), or easy way - go to RetroArch's menu, go to Online Updater -> Update Cores, and download 'Tyrquake' from there.

You can load Tyrquake by going to Load content and selecting either PAK0.PAK or PAK1.PAK. You can obtain the shareware Quake files easily by going to Online Updater -> Content Downloader and going to the Quake category. The downloaded file should then appear inside your Downloads directory. From there, you can go to Load Content -> Downloads and run the shareware version with the Tyrquake core easily.

It's not related to the subject at hand of course but just thought I should mention it in case you weren't aware of it.

[twinaphex]

@Themaister @Novum and all other participants in this thread -

Good news guys, I got a patch submitted and I am very grateful towards the guys that provided us with this.

https://github.com/libretro/RetroArch/commit/2178b6d10f7fb17075a9d1271ca9da08feb0f835

'Vulkan temporary workaround for swapchain recycling (nvidia) -

Both swapchain recreation methods are proper andwithin the Vulkan specs.

The difference is retroarch follows method (apparently proposed in
vulkan samples) that "hopes" the driver will reuse some of the old
swapchain resources, while the other method destroys everything and
recreates from scratch. At the moment on Nvidia drivers the second
method is stable while the first method is unreliable in all cases
today.'

Unfortunately @Themaister I have noticed another issue with another Vulkan core today. I was testing TestVulkan (the one in libretro-samples - https://github.com/libretro/libretro-samples/tree/master/video/vulkan/vk_rendering) and I tried changing the resolution on the fly through the core option. This causes RetroArch to hang/crash right now. Tested this on Windows 10 with the latest Nvidia drivers.

This issue is not related to the patch/commit I just submitted, and it happened before this commit, so it seems to be yet another Vulkan edge case issue.

[elcorsico]

cool thanks for resolve this bug ;-)
great news
and continue

[Fergdog]

Thanks for all the work on the vulkan backend. It works for me now.

One problem that still exists is it seems to force my monitor from 120hz to 60hz when in fullscreen. That isn't a major problem though, it's nice to have fullscreen working.

[Awakened0]

Sweet, with the 390.77 driver and the latest RetroArch nightly (after the work around was removed), I no longer get the black screen on launch with Vulkan and it doesn't change my refresh rate to 60hz either.

This should probably be closed now unless other people want to test to make sure first.

[hizzlekizzle]

I'll go ahead and close it out and we can reopen it if necessary.

[Awakened0]

Oh, I should note for @Fergdog , it will set my screen to 60hz if I use swap interval 1 (the default). At swap interval 2, which is what you want to use when running at 120hz for smooth scrolling anyways, it leaves it at 120. I would think black frame insertion would do that as well, but haven't tested that yet.

[Fergdog]

I already have it set to swap interval 2, I'm going to update nvidia drivers and the latest nightly to make sure it works for me to. I'll report back in a bit. We're definitely two of the people most interested in these 120hz nvidia vsync fixes :P

Do you have the swapchain set to 2 also?

[Awakened0]

I left swapchain at the default (3). I thought on Windows anything less than 3 didn't change anything. I tested it with 2 and it works fine too though.

[Fergdog]

I'm not sure if there's a difference between 2 and 3 on Windows, I just always left it at 2.

And after trying it out, yep the latest nightly doesn't change my monitor to 60hz. Everything vulkan related works now on Nvidia. Really good work.

[twinaphex]

What do we do with the claimed bounty money guys?

@Themaister put in $50 and @WhiteZeroX put in $25. Let me know what should happen with this. Once I know, I can claim the money and then move it to other bounties of your choosing, or a new bounty, whatever is your preference.

[WhiteZeroX]

I'm good with it going to another bounty. I'm personally interested in this one: https://www.bountysource.com/issues/51334773-pgxp-perspective-corrected-textures-untextured-polygons-with-solid-graded-colors-bug

[twinaphex]

OK, I will close the issue then and claim a solution. If maister wants his funds moved to another issue, he can let me know. If he wants it to go to the same cause as @WhiteZeroX , let me know as well.

[Awakened0]

There is the new black screen issue on the recent nightlies: https://github.com/libretro/RetroArch/issues/6870