From BlenderWiki

Jump to: navigation, search

Compositor 2014 p1.1 Multiple buffer types technical design

IST (current situation)

In the current compositor all buffers are allocated with 4 floats per pixels. Even Vector and Value buffers allocates like it is a Color buffer. The reasoning behind this was memory alignment (aligned memory reads faster than unaligned) and the memory was easier to transfer to OpenCL devices.


When doing 4k images the memory usage is large in real composite a lot of buffers are created. This made rendering on the BI renderfarm a bit of confusing. Some 4k images were not rendered on the farm at all.

When P1.3 buffering intermediate results more memory is needed during editing. In order to be prepared for this new memory consumption we should reduce the memory.

SOLL (target situation)

The compositor was prepared for this change by introducing the MemoryBuffer class. This class is responsible for Allocating and free-ing memory. In the new situation this class will be implemented abstract and for every Buffer type:

  • MemoryBufferColor
  • MemoryBufferVector
  • MemoryBufferValue

By introducing these additional classes we will remove possible if-statements and complex unneeded code.

The MemoryBufferColor will be the only class that supports EWA filtering. Currently in Blender this filtering type is not used for Vector and Value.

The Linear/Bi-linear/Nearest filtering will also be supported by all other buffers classes. A complete takeover of the samplers/filtering will be done by the P2.1 PixelSamplers project. For now we will stick with the current implementation.

Additional benefits

During development we case across several speedups. They were small, but they eventually should make the compositor overall a bit faster. Also less memory is used during OpenCL that should speedup the load/unload of data and save some device memory.