Page MenuHome

Blender Does Not Account for Suspend
Closed, ArchivedPublic

Description

System Information
64bit Manjaro Linux, kernel 3.14.29
CPU: AMD Phenom II 970 Deneb quad-core
GPU: nVidia GTX 650 Ti, driver 343.36

Blender Version
Broken: Buildbot Build 2.73 4cbf2ebd
Worked: Not sure this ever worked

Short description of error
Each night when I go to bed, I put my computer into suspend mode, rather than just leaving it on or shutting down. Most applications I leave running during the night don't have any problems. Blender, however, does. Two main problems I have observed:

  1. Textures on models will often be garbled.
  2. Rendering in cycles with CUDA will fail until you close blender and reopen it.

Exact steps for others to reproduce the error

  1. Start blender from the command line, and open or create a scene with textured surfaces, set Cycles to GPU mode. Go to the Render->Performance tab, and make sure that Persistent Images is turned on.
  2. Render the scene. It should render normally.
  3. Exit rendered view, go back to 3D view.
  4. Put your computer into suspend for at least 30 seconds.
  5. Exit suspend mode. Textures on the model will be garbled.
  6. Attempt to render. The render will fail, and if you click or touch anything you will get error messages about illegal instructions on the command line.
  7. Reload the file. The model textures will be corrected.
  8. Attempt to render. It will still fail to render, with the same illegal instruction errors.
  9. Close and reopen blender, then go to the Render->Performance tab and turn the Persistent Images option off.
  10. Repeat steps 1-8 with Persistent Images disabled. The texture corruption still occurs, but the CUDA errors do not.

Fixing the issue should be simple (in theory). It could be done by detecting when the computer suspends or hibernates (most OS's should provide an interface to detect this, but I could be wrong) and then clear/reload the data stored on the GPU.

Error output I got:

Related Objects

Event Timeline

Not quite sure we can do anything here… Afaik, suspending an OpenGL (or DirectX, for what matters) application is always problematic, it uses specific low-level access to the GPU driver, unlike regular applications which only use OS APIs. Antony or Sergey should know better here, though.

@Bastien Montagne (mont29) - Yeah, that's why I said it would be simple "in theory". And because I know that nothing is truly simple with programming, lol.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Feb 9 2015, 12:41 PM
Sergey Sharybin (sergey) claimed this task.

You can think of hibernation as something totally transparent for application -- it just should not notice anything happened. You can't fix it from userspace (aka blender in this case). Some workarounds are probably possible, but it'll be really nasty code which would still fail in loads of cases (for example on my laptop probability of ogl stuck at 100% CPU usage after hibernation is quite high, this you can't fix from blender without restarting it).

So thanks for the report, but we can't really do much about this. Ideally nvidia should look into their driver, but from quick google seems they're not really interested in solving this =/

There is such a thing as a robust context in newer OpenGL, check https://www.opengl.org/registry/specs/ARB/robustness.txt. We could try using it but I'm not certain it will fix resets in CUDA contexts...Any CUDA guru here who might know? I'd suggest to use command-line only rendering for such tasks for now.

@Antonis Ryakiotakis (psy-fi), i'm not sure why exactly the robust contexts will help? From the problem description it just seems driver is flacky enough to not ensure row refresh signals are keeping to happen on video card's SDRAM, which eventually leads to textures corruption. At least that's what likely happening based on the timing and symptoms. Not totally clear why other contents of VRAM are fine tho.

In any case, opengl+hibernation issue is not something blender-specific, it's kernel+driver specific. My main desktop seems to survive it all just fine i.e.

CUDA+hibernation is major problems, being discussed in loads of places. Driver is just to be fixed..