Aliasing of Buffer TypeHandler instances

[Ichthyostega]

As Lumiera Product Owner,
I want handling of render buffers to work correct even in corner cases,
to ensure the Render Engine meets professional quality standards.

resolve possible mismatch in design

The symptoms of this problem are insidious and were encountered several times,
in arcane corner cases — yet it is not really clear what the underlying problem is, which is corroborated by the fact that related technical issues were solved several times by refactoring, only leading to similar issues to show up in the same area.

It seems reasonable to assume that the root for all these problems lies in some mismatch, or internal tension in the design, related to the handling of render buffers. Notably a scheme of metadata handling was gradually developed and evolved, to back the implementation of the »Buffer Provider«. Many aspects of this design are explorative in nature, because a complete implementation of the Render Engine is not yet available — so many assumptions are based on intended behaviour.

The design of this buffer metadata was based on the notion of a »buffer type«, which leads to hierarchical relations between entries in the metadata registry; some entries define generic types, which, in the simplest and most common case, are just based on the size of the required memory block. However, as the design evolved, gradually it became clear that we should not try to define an universal scheme for media processing — we want to rely on an open collection of media handling libraries rather. This leads to the requirement that the adapter code for some library wants to attach construction- and clean-up hooks, yet not to the individual buffer, but to some »kind« of buffer. Maybe this decision itself need to be scrutinised (see #1369).

Unfortunately this implies that we have to distinguish such specialised flavours of buffer types, without a clear generic scheme to base that distinction on. So we ended up with the task to get the hash of a function object (which is not solvable in reliable way); now, in the second iteration we are facing the problem that we have to distinguish different λ-bindings (which is not possible either).

Very likely we will need some help from the client code instructing this buffer usage.
And this does not bode so well with the framework of buffer usage defined thus far.

manifestation of the problem 2026

Regular usage of render buffers is not affected, since that is based on the allocation size alone. But we are aware of some corner cases, where a media handling library needs to emplace a custom type into the buffer memory. Especially in the case when this is defined as a class type, and this class takes constructor arguments, then several bindings of the same constructor with different arguments happen to be aliased.
Demo code:

BuffHandle buffer_1 = bufferProvider.lockBufferFor<Buffer> (-55);
BuffHandle buffer_2 = bufferProvider.lockBufferFor<Buffer> (13);

• this creates and locks two buffers
• in each of these buffers, an object of class Buffer is emplaced.
• but the second instance, in buffer_2 will be initialised with -55

It is quite obvious where the problem happens (type-handler.cpp, line 75):

    template<typename CTOR, typename DTOR>
    inline HashVal
    deriveCombinedTypeIdenity()
    {
      HashVal hash{0};
      lib::hash_combine (hash, typeid(CTOR).hash_code());
      lib::hash_combine (hash, typeid(DTOR).hash_code());
      return hash;
    }

Here, a workaround was added to fix the original problem (how to take the hash of a functor), but this workaround is clearly not correct, since a functor instantiated with different bindings might sometimes end up being the same language type.

It seems compelling to fix this problem with yet another refinement at the API to somehow capture a "fingerprint" of the initialisation values. But since our design just stores two generic functors, such a workaround would again not be able to close the gap.

At this point, we should stop and rethink the issue.

[Ichthyostega]

As part of the prototypical implementation of a buffer handling scheme for the Render Engine (#1396), I will explore the solution to link the TypeHandler identity to a distinct instance — which is defined as a C++ language type (as used in the solution showed above) combined with the identity of a runtime instance of said functor.

This solution is by now means trivial, and may be considered a hack rather, yet it seems plausible that, through this trick, we might be able to resolve this fundamental problem within the confines of the BufferMetadata manager. The key point for this solution is to link that identity to a stable memory location, and to pay attention to copying and moving as part of the metadata initialisation. In fact this might require to attach a hash tag to the implementation record to mark it with such an identity, once established.