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

[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

[inactive123]

@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?

[ghost]

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

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

[inactive123]

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

[inactive123]

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

[inactive123]

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.

[inactive123]

@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.

[inactive123]

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

[inactive123]

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