FBO-using applications unresponsive for a long time after modeswitch

[Chris Halse Rogers]

Applications using FBOs in a certain way (most notably, Unity) hang for a long time (typically, >30 seconds) after the first modeswitch. There's a similar problem with VT switching.

Attached is the source for a test app. This may be built with ‘g++ -std=c++0x -o fbo-madness fbo-madness.cpp $(pkg-config --libs nux-2.0) $(pkg-config --cflags nux-2.0)’. This requires libnux-2.0-dev, libxinerama-dev, and libutouch-geis-dev installed.

Running the attached test app and attempting a modeswitch demonstrates the unresponsive rendering.

It looks like this might be a regression of the fix in:
http://www.nvidia.com/object/linux-display-ia32-260.19.29-driver.html - I've tested this driver and it does not exhibit the long unresponsive period on the test app.

[Alberto Milone (albertomilone)]

Subscribing Nvidia to the issue.

@Daniel, any ideas?

[Ingo Gerth (igerth)]

I am coming from Bug #828761, which was a very active file. There were 85 comments of people affected, so I hope this one will get the priority it deserves. We have to do better on such fundamental things. Thanks.

[Daniel Dadap (ddadap)]

What driver version is this reported on?

There is a known bug in the driver that resulted in momentary hangs during modeswitch for some FBO applications. It was fixed in the 295 timeframe. The first public driver with the fix was the 295.17 beta.

[Tamer Fahmy (tamer-fahmy)]

Indeed, I can confirm that with the recently released stable 295.20
driver version the problem went away and no more hangs are experienced
after resume and the desktop is immediately responsive.

Switching to the console and back also works fine, although there seems
to be one buglet left:

Switching forth and back to the console and the X server requires the
triggering of a full redraw (e.g. by switching to another virtual
desktop) in order to restore the full desktop properly from an initially
black image.

Upon resume and after logging in, there are some graphics artifacts
(graphics memory corruption?) at the area where the unhidden dock would
reside. Once an action overdraws that screen area (the dock is unhidden
or a full refresh is triggered) everything is back to normal.

Not sure, if this is something that is supposed to be taken care of by
the driver or by the compositing manager.

Thx a lot for the fix of the modeswitch hang, though, which works
beautifully again.

[Alexey Brodkin (alexey-brodkin)]

Confirm 295.20 drivers seems like fixed delay on resume.

[che--- (hcguersoy)]

Hi Folks,

can confirm resume delay fix with 295.20, too.

I've installed it via the ppa ubuntu-x-swat/x-updates. For those not knowing how to do it:

sudo apt-add-repository ppa:ubuntu-x-swat/x-updates
sudo apt-get update
sudo apt-get install nvidia-current

[Alberto Milone (albertomilone)]

Driver 295.20 is now in Precise. Please confirm that the new driver solves the issue.

[che--- (hcguersoy)]

I just forgot to mention that I'm runnung 11.10 64b (3.0.0-16).

[nerdy_kid (nerdy-kid)]

Running 11.10 64bit and the latest NVIDIA driver fixes it here.

[Jason Smith (jassmith)]

Fixed :)