Page MenuHome

Deferred deletion of depsgraph copied data
Open, Needs Triage by DeveloperPublic

Description

This idea is generated from the development of LANPR, but might also be useful for other render engines as well.

Current Problem:

In some cases, a render engine will need to process the copied scene data for a while before anything can be displayed. At the same time, we may not want the UI to be frozen (during viewport preview). So we can do this in a background thread. However, when the background thread is processing the data, the data is deleted by the Depsgrapgh, since the particular draw loop is already concluded by the time our background process ends.

Suggested Solution:

To give a function that tells the Depsgrapgh: "I'm done with your data, you can delete now".

For example, when you need deferred deletion, call something like DEG_evaluated_scene_set_deferred(s), and upon finish processing, call DEG_deferred_evaluation_finished(s).

There could be some more benefits for EEVEE and Cycles as well. For example, When toggling render preview in those render engines, you don't need to wait until the initial blocking loading process finishes, and it's quick to revert to workbench shading if you accidentally switched to render (You don't need to wait until the interface to unstuck).

Any thoughts on this one :) ?

Details

Type
Design

Event Timeline

I am not sure what is "deferred" here means exactly. But technically there are only two things which needs locked interface:

  • Dependency graph relations update.
  • Evaluation of copy-on-write operations.

The rest of evaluation can happen in parallel while main thread is doing other things.

For cancelling evaluation we might allow to have a "break()" callback similar to the job system. Don't have strong opinion about it.

Deferring deletion of the scene is not practical, the depsgraph references the original scene. Even if it didn't then having multiple copies of the scene would use too much memory.

If the scene changes and the depsgraph is about to be updated, any background threads used by LANPR should be stopped immediately. We don't have an existing mechanism for that though, it would need to be added.