Closed Bug 1500520 Opened Last year Closed Last year
Texture corruption with Web
Render and NVidia GPU/driver on Linux after resuming from sleep
STR: 1. Be on Linux, with this GPU: NVIDIA Corporation -- Quadro M1200/PCIe/SSE2 2. Use the latest Nightly. 3. Open a few windows (I tried 3). 4. Put the computer to sleep. 5. Resume. Actual results: See screenshot. Expected results: Normal rendering. mozregression indicated that bug 1498092 has caused this regression. jrmuizel has access to the webrender dump obtained from Ctrl+Shift+3, it's on a machine at the Toronto office.
I have a few points here: First, the issue is fairly known (outside of Gecko/WR), quick search reveals other people dealing with this: https://askubuntu.com/questions/974375/my-laptop-doesnt-wake-up-from-suspend-state-ubuntu-17-10 https://devtalk.nvidia.com/default/topic/990898/suspend-corrupts-window-manager-after-upgrade-to-378-09/ https://devtalk.nvidia.com/default/topic/994287/linux/corrupted-screen-after-resume-now-with-375-39-and-378-13-/1 Seconldy, Nicola was just mentioning in the daily that they used an Nvidia GL extension to detect the case where waking up from suspend is trashing the textures, and so we can refresh the texture cache accordingly. Finally, WR already provides an ability to refresh the texture cache: https://searchfox.org/mozilla-central/rev/9cb3e241502a2d47e2d5057ca771324a446b6695/gfx/webrender_api/src/api.rs#607 Gecko can call it when it detects the wake-up.
(In reply to Dzmitry Malyshau [:kvark] from comment #2) > I have a few points here: > > First, the issue is fairly known (outside of Gecko/WR), quick search reveals > other people dealing with this: > https://askubuntu.com/questions/974375/my-laptop-doesnt-wake-up-from-suspend- > state-ubuntu-17-10 > https://devtalk.nvidia.com/default/topic/990898/suspend-corrupts-window- > manager-after-upgrade-to-378-09/ > https://devtalk.nvidia.com/default/topic/994287/linux/corrupted-screen-after- > resume-now-with-375-39-and-378-13-/1 In case this helps, I've never experienced this issue in any other application on this machine in the past year and a half as far as I can recall. Also, another point in case it's helpful. I *think* the texture corruption happens after I log in. Immediately after the wakeup happens, the screen flashes with the content of the desktop as it was before sleep and then the gdm login window rolls down to cover it. I see no corruption on that screen. It is only after logging in on gdm where corruption can be observed. > Seconldy, Nicola was just mentioning in the daily that they used an Nvidia > GL extension to detect the case where waking up from suspend is trashing the > textures, and so we can refresh the texture cache accordingly. > > Finally, WR already provides an ability to refresh the texture cache: > https://searchfox.org/mozilla-central/rev/ > 9cb3e241502a2d47e2d5057ca771324a446b6695/gfx/webrender_api/src/api.rs#607 > Gecko can call it when it detects the wake-up. We have NS_WIDGET_WAKE_OBSERVER_TOPIC for this BTW. :-)
I could reproduce the problem with Ubuntu and with GeForce GTX 960/PCIe/SSE2.
Since bug 1498092, RendererOGL::UpdateAndRender() is not called during handling new frame, instead just RendererOGL::Update() is called. When the UpdateAndRender() was not called during resume from standby, DoNotifyWebRenderContextPurge() was not called since then. It seemed that glGetGraphicsResetStatus() was already cleared for the GLContext. https://dxr.mozilla.org/mozilla-central/source/gfx/webrender_bindings/RendererOGL.cpp#165
Attachment #9018943 - Attachment is obsolete: true
Attachment #9018959 - Flags: review?(nical.bugzilla)
Attachment #9018959 - Flags: review?(nical.bugzilla) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/a0fac96b947e Always check graphics reset status in RenderThread::UpdateAndRender() r=nical
You need to log in before you can comment on or make changes to this bug.