Still seeing this with the latest driver 440.66.08 with vulkan 1.2.136 and Gnome 3.36.1
Vsync works perfectly, even games using intervals 1->4 limited down the FPS
However huge freezing when alt-tabing or switching workspaces still. Screen continually flashes for a while until the switching completed and the desktop environment starts responding again, there is a longer delay the high interval set as well.
It is being actively worked on. I donât have a date when it will be fixed by. I will update when I have more information.
Well⊠updating the xserver-xorg-* (xorg-server) to version newer than 1.20.6-1 version is possible to workaround it using the PRIME Render Offload configuration (PRIME - ArchWiki). Well⊠if you suffer screen tearing because you donât have a compositor, I would suggest using picom compositor (GitHub - yshui/picom: A lightweight compositor for X11) with ââexperimental-backends --vsyncâ option to start up on login.
I was on a Debian stable version and went to a unstable version to get a that xserver-xorg-* packages updated. On Ubuntu everything looks fine. =)
Read my comment above.
Hi all,
This issue has been fixed with the latest Vulkan Developer Beta Driver 440.66.11 available here.
It is part of these fixes:
I will let you know when the fix reaches stable drivers.
Yeah! Finally fixed! Is there a need to upgrade the xorg for a version newer than 1.20.6-1 for using these drivers? I want to go back to Debian stable and Debian stable uses xserver-xorg- * version 1.20.4. An observation is that the vkcube (Debian -- File list of package vulkan-tools/sid/i386) sudently and assiduously tries to spin faster even with the window stopped and that problem does not happen with PRIME Render Offload setup, Itâs like the FPS goes to 100 and then goes down to 60. I thing that it might be another bug that has been come with that new driver version.
P.S.: One day after⊠yeah! It works with the Debian 10 stable. So⊠yay, on Debian stable again! luls It needs the âoption nvidia-drm-nomodeset.confâ on the file â/etc/modprobe.d/nvidia-drm-nomodeset.confâ to work correcly.
Yeah! It seems that the problem above does not occure when I lauch a Vulkan application on a pure X (using ânvidia-xrun vkcubeâ, for example [nvidia-xrun - ArchWiki] ) without a windows manager like Xfwm4 and here the synchronization is perfect.
Just given the 440.66.11 release a test on Arch Linux through the nvidia-vulkan-dkms package, working a lot better now.
There is a slight period of freezing where Gnome seems to think the application has crashed giving the force quit/wait dialog, alt-tabbing again once this displays resumes the window. This is with 2 eve online clients running and switching between them and other applications.
Vast improvement on the 6-10 seconds of complete system lockups without even tty access. The delay now is relative to that of windows full screen games and alt-tabbing to desktop/other apps. Can confirm intervals / vsync is working perfectly too limiting to panel refresh and further limiting down on increased intervals correctly.
Thanks very much for getting this one fixed and updating us all!
@RenanWP right, as you observed, regular PRIME synchronization doesnât require a patched Xorg.
I wasnât able to observe the FPS spikes you mentioned.
even with the window stopped
Do you mean when the window is not being dragged around?
Are you observing that the framerate goes above the monitor refresh rate?
Also I donât suppose thereâs something else consuming significant CPU/GPU on the system that interferes with vkcube?
I also observe the cube spinning faster (FPS spike) but only when moving the window.
Otherwise, no more freeze! đ
Just waiting for the fix to be included in the stable driver and I can mark the issue as solved.
Do you mean when the window is not being dragged around?
Yeah, exacly! And thank you for the fast reply!
Also I donât suppose thereâs something else consuming significant CPU/GPU on the system that interferes with vkcube?
Certainly not, because my CPU and GPU are being used about 3% and Iâm suffering it since the fresh Debian install.
I have partially understood what was happening. Xfce4 Window Manager probably does the âsameâ thing as dragging around the vkcube Window to update some other parts of the screen to change its state, for example, decreasing and increasing the volume makes the cube spin faster despite the vkcube window is just right in the same old place, because the volume icon changes its state (it updates). Another example is that when I drag around other window over vkcube window the cube spins faster (it does not look FPS spikes now, despite being probably the same mechanism). Iâm not sure if I can call this a bug rather than just a expected behavior. Iâm using xfce4 4.12 and Debian stable repositories.
Yeah! I âsufferâ the same problem as you as well.
The increased framerate is a byproduct of some client-server updates our driver has to go through. This byproduct occurs both when dragging the window around and other screen updates. The increased framerate is expected behavior.
Again, thanks for quickly resolving my doubts.
Having just updated from 440.66.17 to 450.56.02, the issue appears to have come back with the r450 rebase.
I can also confirm that bug comes back happening on Debian 10.5 stable, even using the pkg-config and libglvnd-dev that the driver asked to install. One good thing would be the driver 440.66.17 (or 440.66.11) that solves that problem be archived on âlinkâ for easy acess. I have that driver avaible on my hard drive, but I bet that not everyone can have that as easy as I have.
That bug unfortunately remains unsolved since the driver version 440.66.xx is is not officially available for the users anymore. So, I will comment here two workarounds for those that really want to run games or X applications on Optimus systems.
The first one is using the PRIME Render Offload setup with updated X Server packages as described here:
The second way, as I have noticied, on following comment
, is running the X application/game on terminal without an window manager using the Offloading Graphics Display with RandR 1.4, since there is a good chance that this bug resides on way that the driver or the Window Manager manages/updates multiple windows. That configuration does not require the updated X Server packages as on the first solution. So, that second one is good for stable distros that does not update that packages frequently. So, how to perform that second solution? Running a game/application using nvidia-xrun (or using your prefered way of starting an application on separeted X) for running Lutris that way. How can I run a game that way? First, you need to configure your game on Lutris . The way you do it is avaible here How to Install Games on Lutris Manually. Then, assuming you will use nvidia-xrun, you need to install the nvidia-xrun, the guide avaible on link. Then, on a separeted TTY, you will run the lutris game by the command nvidia-xrun lutris lutris:rungameid/X, where X is the game id, the way you find it is explained on this link. For wine applications, do not let the Window Manager to control your windows on winecfg while gaming, because that will result on non-draggable windows. How to configure that is on this link, but make sure to configure that on Lutris, if running there. For games that need some applications on background that authenticates it, like Steam, try using the own terminal version of that application, for example, on Steam, nvidia-xrun steam steam://rungameid/{YourGameID}. Thatâs all folks!
Just tested out 460.32.03 and the issue appears to be resolved. Hereâs hoping we donât get another regression.
A fix for this issue has been included starting with the 460 driver series. The current version is 460.32.03 and is available here.