-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux/NVIDIA/vulkan: fullscreen window stops updating #2593
Comments
I have tested dolphin emulator and it appears to be working fine with fullscreen when using vulkan renderer, suggesting that the problem is with bgfx and not with nvidia drivers. |
Graphics will start updating again if vsync is disabled after going to full screen with F7. Strangely enough, re-enabling vsync in fullscreen does not cause the graphics to stop updating again. It is only after switching to windowed mode and then to fullscreen back again the problem appears again. ETA: similarly, clicking on Restart makes the graphics update again until the next window/fullscreen switch. |
Here is the console output, there is nothing obviously wrong:
|
I currently don't have access to a Linux machine, and I can't reproduce this on Windows. So I'll have to rely on you for some detective work if you don't mind 👀
Thanks! |
I do not mind detective work at all :)
|
My first intuition here is that the swapchain gets invalidated and no resize event is received. Some reset parameters force a swapchain recreation, among others v-sync and sRGB, but not MSAA (since that just changes the intermediate buffer to resolve from). When the swapchain gets invalidated (usually the window is resized), Vulkan gives us a hint to stop rendering into the swapchain, but we can't recreate it right away, because we don't have the new window size. We can get it from Vulkan, but we won't get the reset event until it bubbled all the way down to the render thread a few frames later. I suspect that some combination of I'm going to set up a VM and see if this is reproducible, otherwise this is very tricky to fix. |
Now that I know how to switch to full screen, I have tested this on my AMD laptop. In a wayland session, attempt to go to fullscreen with vulkan renderer results in a crash:
GL (--gl) renderer works fine. With X.org session both renderers works fine, i.e. no crash and no freeze. This might mean that reproducing this in a VM might be tricky. If you have access to an nvidia machine, maybe a Fedora Live USB could be an option? Here is the information regarding the set-up: |
That crash is probably an unrelated bug 🙊 Can you add Line 7322 in ee0fbea
SUBOPTIMAL and OUT_OF_DATE set m_needToRefreshSwapchain = true ). That should at least fix that.
Thanks for the pointer on the live USB, might work better than a VM. |
The plot thickens: I have changed renderer_vk.cpp as you suggested: index c857916c2..c49ffc2ae 100644
--- a/src/renderer_vk.cpp
+++ b/src/renderer_vk.cpp
@@ -7320,6 +7320,7 @@ VK_DESTROY
BX_FALLTHROUGH;
case VK_ERROR_OUT_OF_DATE_KHR:
+ case VK_SUBOPTIMAL_KHR:
m_needToRefreshSwapchain = true;
return false; I can now switch to fullscreen with vulkan renderer on my wayland session, and the video will stop updating immediately - not like with nvidia/X.org, which happens after a few moments. I can unfreeze it by clicking reset, but not by disabling VSync with F7 as the latter causes a crash (works with --gl):
So we have the following:
ETA: however strange it might be, it might actually be a good thing that a similar problem occurs with standard radeon drivers. If the cause is the same, this would make reproducing it much simpler as standard Live USB would be sufficient, without the need to slipstream the nvidia drivers into it. |
Without this change, running examples under XWayland, SDL and vulkan renderer results in a crash. Credit goes to @pezcode: bkaradzic#2593 (comment)
I was not able to reproduce this on Ubuntu 20.04 running inside QEMU/KVM. |
I was able to reproduce using Pop!_OS 21.04 Live USB with nvidia driver preinstalled: https://pop.system76.com/ |
Without this change, running examples under XWayland, SDL and vulkan renderer results in a crash. Credit goes to @pezcode: #2593 (comment)
Without this change, running examples under XWayland, SDL and vulkan renderer results in a crash. Credit goes to @pezcode: bkaradzic/bgfx#2593 (comment)
Sorry for the delay... I tried the Live USB a while back and the experience was questionable, but I got a new SSD the other day so I can properly dual boot into Pop OS now. Good news is I can reproduce a crash when going fullscreen. |
If it works with |
I tried dolphin emulator with Vulkan renderer and it does not freeze after going fullscreen. Do you know another software which uses SDL and Vulkan which I could try? |
Without this change, running examples under XWayland, SDL and vulkan renderer results in a crash. Credit goes to @pezcode: bkaradzic#2593 (comment)
I got a new monitor which is capable of freesync and experimented a bit. With opengl backend, after going to fullscreen the indicators initially show blit/normal before switching to flip/gsync. With vulkan they never switch, and the delay until screen stops updating is suspiciously similar to the one needed to flip/gsync activation. |
This seems fixed as of 510.47.03 nvidia driver. From 510.39.01 changelog [1]:
[1] https://forums.developer.nvidia.com/t/linux-solaris-and-freebsd-driver-510-39-01-beta/200220 |
Without this change, running examples under XWayland, SDL and vulkan renderer results in a crash. Credit goes to @pezcode: bkaradzic#2593 (comment)
Describe the bug
This was originally reported against mame (mamedev/mame#7820) but I have finally managed to reproduce it with bgfx examples. In brief, with examples built with --enable-sdl, fullscreen window will stop updating a few moments after hitting ctrl-f.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Screen keeps updating as it does when --gl is passed
Screenshots
N/A
Additional context
This appears to only happen with nvidia binary drivers, my amd laptop is not affected.
The text was updated successfully, but these errors were encountered: