The idea is to only allocate pixel storage only when there is an actual
data to be written to them.
This moves the code forward a better support of high-res rendering when
pixel storage is not allocated until render engine is ready to provide
pixel data.
Is expected to be no functional changes for neither users no external
engines. The only difference is that the motion and depth passes will
be displayed as transparent for until render engine provides any tile
result (at which point the pixels will be allocated and initialized to
infinite depth).
Differential Revision: https://developer.blender.org/D12195
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
