Crash during Cycles GPU rendering when using world shader with position as input for volume scatter #72464

New Issue

thomas pahler · 2019-12-15T16:40:27+01:00

thomas pahler commented

2019-12-15 16:40:27 +01:00

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: f1aa4d18d4
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:bugReport.blend

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

**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: `f1aa4d18d4` 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:[bugReport.blend](https://archive.blender.org/developer/F8223323/bugReport.blend) - 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 ![max.JPG](https://archive.blender.org/developer/F8223362/max.JPG) - crash confirmed with newer driver version 441.66 - inside an object shader (instead of world shader), this does not crash

thomas pahler commented

2019-12-15 16:40:27 +01:00

Added subscriber: @thomason1005

Robert Guetzkow commented

2019-12-15 18:14:51 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2019-12-15 18:14:51 +01:00

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.

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. ![2019_12_04_upload_icon_developer_blender_org.png](https://archive.blender.org/developer/F8190038/2019_12_04_upload_icon_developer_blender_org.png)

Robert Guetzkow changed title 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

2019-12-15 18:22:22 +01:00

thomas pahler commented

2019-12-16 20:03:01 +01:00

blender_system_info.txt

blender_debug_output.txt

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

[blender_system_info.txt](https://archive.blender.org/developer/F8226789/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F8226790/blender_debug_output.txt) 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. ![Screenshot (2881).jpg](https://archive.blender.org/developer/F8226800/Screenshot__2881_.jpg) 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

Robert Guetzkow commented

2019-12-17 11:00:00 +01:00

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.

The debug logs show that `cuCtxSynchronize()` failed. This may be caused by a [Timeout Detection and Recovery (TDR) delay ](https://docs.microsoft.com/de-de/windows-hardware/drivers/display/timeout-detection-and-recovery?redirectedfrom=MSDN) 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 ](https://docs.substance3d.com/spdoc/gpu-drivers-crash-with-long-computations-128745489.html). Be aware that incorrect modifications of the registry can lead to serious issues and you're doing so at your own risk.

thomas pahler commented

2019-12-30 15:37:24 +01:00

"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

"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

Robert Guetzkow commented

2019-12-30 16:47:44 +01:00

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.

Dalai Felinto commented

2020-01-13 18:42:47 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2020-01-13 18:42:47 +01:00

@thomason1005 is this something you could try please?

thomas pahler commented

2020-01-14 19:55:58 +01:00

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

![bugResistry.JPG](https://archive.blender.org/developer/F8278229/bugResistry.JPG) i added the delays, but unfortunately, the example file still crashes blender when rendering

thomas pahler commented

2020-01-14 21:56:46 +01:00

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.

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.

thomas pahler commented

2020-01-14 22:38:37 +01:00

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!

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 commented

2020-01-16 12:34:14 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Dalai Felinto closed this issue

2020-01-16 12:34:14 +01:00

Dalai Felinto self-assigned this 2020-01-16 12:34:14 +01:00

Dalai Felinto commented

2020-01-16 12:34:14 +01:00

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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash during Cycles GPU rendering when using world shader with position as input for volume scatter #72464