Page MenuHome

Crash during Cycles GPU rendering when using world shader with position as input for volume scatter
Closed, InvalidPublic

Description

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 960/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash: rBf1aa4d18d49d
Worked: (optional)

Short description of error
when using the position node in the world shader to control the volume scatter density, this crashes cycles when rendering on the gpu.

Exact steps for others to reproduce the error
minimal blend file to reproduce the crash:

  • open
  • switch to gpu renderer (gtx960, cuda)
  • switch viewport to rendered
  • after some time and a first image, blender will freeze and close some seconds later. (during the first sample)

notes:

  • this does not occur with the cpu renderer
  • a simple max node seems to prevent the crash in some cases, but not all

  • crash confirmed with newer driver version 441.66
  • inside an object shader (instead of world shader), this does not crash

Event Timeline

I can't reproduce this on Windows 10 with Nvidia Geforce GTX 1080Ti in 2.81a and latest master. Please open Blender's installation directory and double click on blender_debug_gpu.cmd. Once Blender opens, perform the same steps as you did before to make it crash. Afterwards the Windows Explorer will open and show two files. Please upload them on here, by using the upload button as shown in the screenshot below.

Robert Guetzkow (rjg) lowered the priority of this task from 90 to 30.Dec 15 2019, 6:20 PM
Robert Guetzkow (rjg) renamed this task from volume shader that contains position node crashes cycles when rendering on gpu to Crash during Cycles GPU rendering when using world shader with position as input for volume scatter.Dec 15 2019, 6:22 PM

here are the log files.

side note: sometimes blender does not crash completely, but instead shows this image: everything still works, except the render buffer/image is frozen.

also, i was able to avoid the crashes by adding clamp nodes to avoid divide by zero and negative values in the volume shader density.
these seem to have been the cause.
as these are bad practices anyway, i would not consider this a high priority

The debug logs show that cuCtxSynchronize() failed. This may be caused by a Timeout Detection and Recovery (TDR) delay that is too low and the OS reinitializes the driver and resets the GPU.

Please try to increase the TDR delay and check if that resolves the issue. Instruction on how to modify this value can be found here. Be aware that incorrect modifications of the registry can lead to serious issues and you're doing so at your own risk.

"Please try to increase the TDR delay"

will this help you in any way? p.e. in fixing or finding a bug, or is this a problem purely related to my system / graphics card?

i would rather not make changes to my registry, but i can do it if it helps find a general bug

It would help to rule out the TDR as cause of your issue. If increasing it solves the problem, then it's not a bug in Blender.


i added the delays, but unfortunately, the example file still crashes blender when rendering

so one driver update and another restart later, blender does not crash anymore on this file.

it does, however, freeze the interface for several seconds per sample, which does not occur if the density input is clamped to positive.

just as a confirmation:

  • clamped density above .001 renders in 5:20min 100%
  • unclamped (negative) density renders at 20:00mins+ for 50%

so there seems to be a substantial difference in computation time, i do not know if this is reproducable on other systems or worth looking into.
but the clamped density also results in a black image image, so i do not know if it is even comparable.

but at least it does not crash anymore. nice!

Dalai Felinto (dfelinto) claimed this task.

I'm glad the driver fixed the crash for you. Since the original report was about the crash (and we stick to one issue per report ;) I'm closing this now. If you think the other issue is worth looking at please submit as a separate issue. Once again, thanks for the report.