clarify the role of Buffer Types

[Ichthyostega]

As Lumiera Architect,
I want the concept of a »Buffer Type« to be validated,
to ensure our design of the Render Engine is aligned with actual requirements.

design review work

Within the Render Engine, we use the BufferProvider interface, which is actually a framework and defines a Protocol for acquiring, using and releasing data buffers. This concept and design has a somewhat problematic history, since it emerged from several (at that time fruitless) efforts to get into building the internal structures of the Engine. It was based on requirements which I „made up from thin air“ at that time. A recent review and clean-up showed however that the basic design seems solid and worth building upon.

However, the typical implementation scheme for such a BufferProvider relies on a framework for handling buffer metadata. I could not find anything serious to criticise in my recent review, the code looks clean (albeit slightly confusing) and performs well. Yet this BufferMetadata framework is a piece of bold design — backed by intuition what we might encounter down the road. Notably, the whole design revolves around the notion of a »Buffer Type«, which is represented by a hierarchical structure of registration entries. In its simplest form, such a Buffer Type denotes a buffer with raw memory of fixed size. But it can be augmented, and thus specialised with a TypeHandler and with a LocalTag. Together, this allows us to create Buffer-Descriptors (BuffDescr) at the time when the Builder creates the Render Node Network. These can be used as prototypes to create the entry for each actual render buffer used during computation; that entry allows then to track the lifecycle of said buffer — in my current planning I expect to send that entry via asynchronous messaging, whenever a worker can foresee a lack of memory available in its thread-local pool of buffers.

In the current stage of development, it seems pointless to discuss this design further. It works, and seems capable to support the expected next steps. But we do not have any empirical knowledge how this design behaves when put to work under realistic conditions. And, what is most important for this topic: we did not yet achieve integration with any of the popular media-processing libraries. Because that is the point where we need to define the »kind of buffer« to be used within the engine.

This ticket shall remind us to review and scrutinise this part of the design, even if everything seems to work satisfactory.

[Ichthyostega]

Attach to parent #1413 (allow to refine a Buffer Type).