Page MenuHome

Eevee crash (caused primarily by very shallow Depth of Field)
Open, Confirmed, MediumPublic

Description

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce RTX 2080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.64

Blender Version
Broken: version: 2.80 (sub 72), branch: blender2.7, commit date: 2019-05-27 19:48, hash: rB89207df7222a
Worked: (optional)

Short description of error
Any time I try to render an image sequence in any format in Eevee, it constantly crashes the whole program on the first frame. I was able to render before until I changed some camera location animations and adding a focusing animation. As well as changing the camera sensor size. I am rendering in 4K I have attached the log file.

Details

Type
Bug

Event Timeline

Brecht Van Lommel (brecht) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.May 28 2019, 11:03 AM

We require an example .blend file to reproduce bugs.

Andrew (GemstoneStudios) raised the priority of this task from Needs Information from User to Needs Triage by Developer.May 28 2019, 7:36 PM
Andrew (GemstoneStudios) updated the task description. (Show Details)

It crashed here as well and I got to restart. It may be the high resolution of the render. Writing this down before I eventually have to restart the computer again.

I have tried restarting it multiple times and it has still crashed. It rendered in 4K before I did the changes I described above. Could it be the camera sensor size or the focusing animation that could be causing issues?

Dalai Felinto (dfelinto) lowered the priority of this task from Needs Triage by Developer to Confirmed, High.

(one or two restarts later ...)

We have a double locking going on here.

DRW_render_to_image() > DRW_opengl_render_context_enable() > engine_type->draw_engine->render_to_image()
And before we get to calling DRW_opengl_render_context_disable() we get a lock in DRW_opengl_context_enable_ex().

My blind guess is that rendering in a new window is part of the issue.

(one of the restarts messed with my internet on Linux, I will be back to it later)

My blind guess is that rendering in a new window is part of the issue.

Not really the case. Anyways I will leave to Clément to figure out what is next here.

Not sure if related, but I took the file, changed render size (1024x1024):

Now if I try to render the file above I get the following depsgraph assert when adding the scene node itself:
BLI_assert failed: //source/blender/depsgraph/intern/depsgraph.cc:121, add_id_node(), at '(id->tag & LIB_TAG_COPIED_ON_WRITE) == 0'

Full backtrace: P987

The bug in depsgrapgh is now fixed.

File from Dalai seems to be rendering fine now. But the original file takes quite a bit to render. Not sure if it's something wrong in code or is just how the file is set up.

Crashes i couldn't reproduce so far after my fix, but would be cool if someone verifies this.

I tried rendering again with my 4K settings with the latest version of 2.8 today and it still crashes the whole program. 1080p and lower seen to work but I need to be rendering this particular project in 4K. If my last resort is to upscale it, I will, but that is something I would like to avoid.

@Andrew (GemstoneStudios), if you're using buildbot.b.o then it doesn't have the fix yet.

Could also be GPU limitation or a driver bug. Are there any error messages printed to the console?

I am able to render but I cannot have any render displays turned on. Anytime I try and use a view that shows the render, it crashes. It’s currently rendering the scene now. I noticed it gets hung up on the first frame to be rendered, but it starts speeding up after the first frame of the animation is completed.

It crashed during the middle of the render. Here are the bug logs.

Ok it crashes because the rendering is too heavy (takes too much time to render). What is taking the most time is the Depth of field. If you lower the max size it renders in a decent amount of time.

If you do it in post you can get away with lower rendertime even.

Brecht Van Lommel (brecht) lowered the priority of this task from Confirmed, High to Confirmed, Medium.EditedJun 6 2019, 12:44 PM

Not a high priority bug anymore as far as I can see, now that the system lockup is fixed and it's a driver timeout type of issue.