Page MenuHome

Viewport Optix Denoiser is available when Cycles Render Device is set to None/CUDA, leading to a crash
Closed, ResolvedPublicBUG


Hi there !

System Information
Operating system: Linux-5.4.0-7642-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce GTX 1050 Ti with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-03 20:57, hash: rBa96283ba511d
Worked: (newest version of Blender that worked as expected)

Short description of error
The option to choose the Viewport Denoiser in the Render Properties shows Optix in the dropdown menu, even though the Cycles Render Device in the System Preferences in set to "None" or "CUDA". Choosing the Optix Viewport Denoiser and going to Rendered mode crashes Blender

Exact steps for others to reproduce the error

  • Start Blender with defaults (Cycles Render Device to None or CUDA).
  • In the Render Properties editor, change the Engine to Cycles.
  • In the Denoising Sampling panel, activate the Viewport Denoiser. Automatic will be chosen.
  • Change the Viewport Shading to Rendered to be welcomed by a crash

Note that the crash occurs also when the Device in the Render Properties panel is set to GPU Compute.
Note that a Cycles Render Device to Optix and the Device to GPU Compute does not crash for me when choosing the Optix Denoiser in the Rendered Viewport Shading (as it should be hopefully).

Event Timeline

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedFri, Sep 4, 9:42 PM

Optix Denoiser being available when Cycles Render Device is set to None/CUDA is correct behavior. However, I can confirm the crash following the above steps in a96283ba511d with CUDA/CPU and Optix denoiser. Linux, GTX 960 (450.66 driver)

Robert Guetzkow (rjg) changed the task status from Needs Triage to Confirmed.Sat, Sep 5, 12:01 PM
Robert Guetzkow (rjg) triaged this task as High priority.

I can confirm this issue. I'm not entirely sure which project and tag is correct for this ticket, since there's an overlap between viewport, optix and cycles.

Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".Sat, Sep 5, 12:17 PM

Can confirm that rBcf0ba59e311b is crashing for me as well (whereas rB429afe0c626a was still fine)

**System Information**
Operating system: Linux-5.7.10-201.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100
version: 2.91.0 Alpha, branch: master, commit date: 2020-09-04 21:32, hash: `rBcf0ba59e311b`

Cannot bisect this atm, due to , using builds from

CC @Patrick Mours (pmoursnv)

Just a clarification. Crash not only happens in viewport, it also happens in final render with Optix denoiser. Under some circumstances the crash even occurs with Optix selected in Device settings. Anyway I guess this will be easily reproducible by the developers.

Hi Patrick, assigning this to you since it is a high priority issue. If you won't have the time to look at that please unassign and we see how to handle it.

This is caused by rB009971ba7adc9603b90e9bf99b6b6d53eeae6c3a. Enabling OptiX denoising with CPU rendering creates an implicit multi-device in Cycles, which breaks Embree BVH building because the Embree device (BVHEmbree::rtc_device) is not initialized.
@Stefan Werner (swerner) I suppose the simplest solution would be to override Device::bvh_device() in MultiDevice as well and have it return the one from the first CPU device (as there should only be one anyway)? We also may want to streamline the Embree/OptiX BVH building at some point and make it more similar, but that's out of scope for this particular issue.

Removing the EEVEE Viewport tag, as it doesn't seem to be related to the OpenGL/drawing side.