[Linux X11 Nvidia] 1.14.0 -> 1.15.0 regression: Black screen with vulkan max swapchain images "1"

[AlexFolland]

Description

With RetroArch 1.14.0 using the Vulkan video renderer and "Max swapchain images" set to 1 (video_max_swapchain_images = "1" in the config file), RetroArch loads correctly and uses the swapchain mode I expect (single buffering). This allows correct Vsync in my desktop environment with my display driver, with no tearing and no dropped frames. This can no longer be set in the GUI as of several versions ago, even though it is the only way to get correct synchronization on my system and similar Nvidia Xorg systems with "Force Full Composition Pipeline" enabled. It must now be set in the config file directly.

With RetroArch 1.15.0 using the Vulkan video renderer and "Max swapchain images" set to 1 (video_max_swapchain_images = "1" in the config file), RetroArch starts but displays a black screen, with no other video output. It is running correctly otherwise, but can't be seen. Pressing the quit keybind twice exits as expected.

This was tested in the same session with both RetroArch 1.14.0 and RetroArch 1.15.0 and back to RetroArch 1.14.0 using the downgrade tool on Manjaro.

Expected behavior

The renderer is expected to use single buffering and display images the same way 1.14.0 does.

Observed behavior

The renderer displays no images except a fully black image.

Steps to reproduce the bug

1. Set video driver to Vulkan
2. Set video_max_swapchain_images = "1" in the config file
3. Start RetroArch 1.14.0
   • At this point, video output is correct and synchronized perfectly, assuming the Nvidia driver is set to "Force Full Composition Pipeline" or just "Force Composition Pipeline" for the display in use.
4. Exit RetroArch 1.14.0 and start RetroArch 1.15.0
   • At this point, there is only a black screen as video output. To exit, press the usual exit keybind twice.

Version/Commit

• Issue reproducible in: RetroArch 1.15.0 6616b80 built 2023-05-25
• Issue not reproducible in: RetroArch 1.14.0 ad89b0c built 2023-02-28
• Config file (rename to remove .txt): retroarch.cfg

Environment information

• OS: Manjaro unstable branch with latest updates, running XFCE
• GPU: Nvidia GTX 1080 Ti, using proprietary Nvidia driver 535.54.03 with "Force Full Composition Pipeline" enabled in the driver settings

[sonninnos]

1 won't work and will actually use 2, and 2 is the minimum in the menu because of that. The log used to output all supported modes, but it will show:

[INFO] [Vulkan]: Got 2 swapchain images.

I remember some time ago the minimum limit was removed in some cases, so that some system can use lower values than wrongly reported. Check the older version for that row, I'm pretty sure it will say 2 instead of 1 even if the option is set to 1. And now it tries to use 1, but fails, like it should.

Edit: There it is: 6e27b6f

[AlexFolland]

OK, that explains it. Thanks. I was switching between "Max swapchain images" settings of 1 and 3 to compare synchronization and noticing that 3 causes frame drops but 1 doesn't. I was never purposely setting 2.

I hadn't considered using 2 since 2 is double buffering which I've understood to introduce additional latency due to waiting for a free buffer to write to before swapping, whereas triple buffering and single buffering never wait. It's weird to me that 3 swapchain images causes frame drops, but that's what I've observed in testing. 2 swapchain images works well with 1.15.0 without dropping frames or tearing, somehow. I guess that's what I'd been using in previous versions.

This all being said, the text in the following screenshot is still in RetroArch 1.15.0 and should probably be changed, as it looks like single buffering is still supported.

Also, I think something should prevent a setting of "1" from breaking the whole system, since it used to be possible to set in the GUI and now breaks the program if it was ever set that way.

Thank you for your response. Feel free to close this once this comment has been interpreted.

[sonninnos]

Theoretically yes, but the vulkan driver isn't picking the optimal mode currently, since vsync disabled goes in "mailbox" mode and not "immediate", meaning that it will stutter instead of tear. 2 is using "fifo", which is doing very fine concerning input lag. Unfortunately not every platform has all modes available.

Yep indeed, the info text needs to change, since it wasn't actually ever really supported as far as I can decipher the code. Vulkan can't write to the buffer that is being shown, hence two is needed. And yes, there needs to be a check in the config read and not just the menu item. I can handle both of them soonish.

[sonninnos]

I tried to tackle that mode thing pretty recently in this, but it got reverted due to some reason I couldn't replicate, but I'll try again: #14788

[sonninnos]

And if I set 1 in Windows, it does pick 2 by itself, which is kinda weird since that cap is removed, so no wonder that went unnoticed..

[AlexFolland]

I just noticed this issue also manifests on the Steam Deck (since I had "Max swapchain images" set to "1" there too) in gaming mode (so, using gamescope), but instead of showing a black screen, it shows the first frame and no frames after that.

However, the crazy part is that on the Steam Deck in desktop mode (so, running KDE Plasma with X11), "Max swapchain images" set to "1" works just fine, even with 1.15.0. Something's crazy about that. I guess whatever AMD Vulkan driver for Xorg that's used on the Steam Deck somehow allows that.