picom icon indicating copy to clipboard operation
picom copied to clipboard

picom infinite loop on GL error after wake from suspend

Open kociap opened this issue 11 months ago • 6 comments

When waking the computer from suspend (systemctl suspend), picom fails to display any graphics due to an error.

gl_last_render_time ERROR ] GL error at line 1168: 1287

1287 corresponds to 0x507 which is GL_CONTEXT_LOST. This causes picom to enter an infinite loop occupying 100% of a single thread. The log picom.txt

Environment

Arch Linux 6.12.7-arch1-1, X11, i3

picom

**Version:** v12.5 (/startdir/picom revision a456d43)

### Extensions:

* Shape: Yes
* RandR: Yes
* Present: Present

### Misc:

* Use Overlay: No

* Config file specified: None
* Config file used: /home/peter/.config/picom/picom.conf

### Drivers (inaccurate):

NVIDIA

### Backend: glx

* Driver vendors:
 * GLX: NVIDIA Corporation
 * GL: NVIDIA Corporation
* GL renderer: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2
[ 12/31/2024 10:47:39.068 egl_init WARN ] The egl backend is still experimental, use with care.

### Backend: egl

* Driver vendors:
 * EGL: NVIDIA
 * GL: NVIDIA Corporation
* GL renderer: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2

picom config

shadow = false;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
fading = false;
fade-in-step = 0.03;
fade-out-step = 0.03;
frame-opacity = 1.0;
corner-radius = 0
blur-kern = "3x3box";
backend = "glx"
dithered-present = false;
vsync = true;
detect-rounded-corners = true;
detect-client-opacity = true;
detect-transient = true;
use-damage = true;
rules: ({
  match = "window_type = 'tooltip'";
  fade = false;
  shadow = true;
  opacity = 0.75;
  full-shadow = false;
}, {
  match = "window_type = 'dock'    || "
          "window_type = 'desktop' || "
          "_GTK_FRAME_EXTENTS@";
  blur-background = false;
}, {
  match = "window_type != 'dock'";
  # shader = "my_shader.frag";
}, {
  match = "window_type = 'dock' || "
          "window_type = 'desktop'";
  corner-radius = 0;
}, {
  match = "name = 'Notification'   || "
          "class_g = 'Conky'       || "
          "class_g ?= 'Notify-osd' || "
          "class_g = 'Cairo-clock' || "
          "_GTK_FRAME_EXTENTS@";
  shadow = false;
})

GPU, drivers, and screen setup

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 11264 MB
    Total available memory: 11264 MB
    Currently available dedicated video memory: 10520 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 565.77
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6.0 NVIDIA 565.77
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 565.77
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

kociap avatar Dec 31 '24 11:12 kociap

I've managed to make picom recover from the error (patch reinit.txt). The recovery takes only a few ms, yet any graphics show up a few seconds after the cursor first appears. Until then the screen remains black. picom.log

kociap avatar Jan 01 '25 11:01 kociap

Having the exact same issue here after upgrading my nvidia driver from 550 to 570.

mietschie avatar Feb 07 '25 07:02 mietschie

after upgrading my nvidia driver from 550 to 570.

yeah... can you also report this to nvidia?

also picom should detect device resets like this. (we do call glGetGraphicsResetStatusARB for that). did you see any "reset" related log messages?

yshui avatar Feb 07 '25 18:02 yshui

Seeing the same issue after upgrading from 555 to 570. Agree that this is probably an nvidia driver bug (again). I ended up adding a script that kills Picom before suspending, and then restart it after wake up.

It would be nice to have the solution proposed by @kociap as a fallback to re-initialize the context. Are there any plans to integrate it into Picom?

WimK avatar Mar 05 '25 19:03 WimK

I looked into this a little bit more and, like @kociap mentioned, the main issue appears to be the loop in gl_check_err_ becoming an infinite loop due to glGetError returning errors indefinitely :

while (GL_NO_ERROR != (err = glGetError())) {

If I add throttling to gl_check_err_ (i.e. print at most 5 errors) - the Picom device reset code works just fine.

[ 03/09/2025 15:22:48.268 gl_last_render_time ERROR ] GL error at line 1168: 1287
[ 03/09/2025 15:22:48.268 gl_last_render_time ERROR ] GL error at line 1168: 1287
[ 03/09/2025 15:22:48.268 gl_last_render_time ERROR ] GL error at line 1168: 1287
[ 03/09/2025 15:22:48.268 gl_last_render_time ERROR ] GL error at line 1168: 1287
[ 03/09/2025 15:22:48.268 gl_last_render_time ERROR ] GL error at line 1168: 1287
[ 03/09/2025 15:22:48.268 draw_callback_impl ERROR ] Device reset detected
[ 03/09/2025 15:22:48.268 draw_callback_impl INFO ] Resetting picom after device reset
[ 03/09/2025 15:22:48.268 reset_enable INFO ] picom is resetting...
[ 03/09/2025 15:22:48.467 gl_init INFO ] GL vendor is NVIDIA, enable xrender sync fence.

WimK avatar Mar 09 '25 14:03 WimK

i think we can just consider GL_CONTEXT_LOST a reason for a device reset

absolutelynothelix avatar Mar 09 '25 14:03 absolutelynothelix