Opened at 2026-02-19T17:32:38Z
#1413 new todo
allow to refine a Buffer Type
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | nice | Milestone: | 1alpha |
| Component: | lumiera | Keywords: | |
| Sub Tickets: | #1412 | Parent Tickets: | #1323, #1370 |
Description
As a Lumiera developer,
I want to refine a given Buffer Descriptor,
to easily place an object with special initialisation into that buffer.
nice-to-have and easy to implement
This feature is more like »syntactic sugar«, because the same effect can already be achieved by defining a separate new Buffer Descriptor, thereby specifying an object type and constructor arguments. The benefit of adding this feature is to have an expressive notation to indicate that an existing Buffer Type will be refined, adding an object more like a view layer. As additional benefit, a size check would be performed, raising an error if the object could not fit into the already predetermined storage.
Proposed syntax:
buffDescr.adapt<TY> (args...)
Note that, with the implementation in its current shape, both ways to specify such a setup will lead to exactly the same Buffer Types to be placed into the registry:
- a base record that only defines the size
- a refinement record which attaches a
TypeHandlerinstance
Furthermore, we do not exploit the hierarchical structure of Buffer Types in any way currently, and this whole concept should be revalidated at some point later (#1412). And in addition to that, there is an unresolved tricky problem (#1411) related to the identity of TypeHandler instances. Taken together, all these concerns made me refrain from implementing this feature right-away, even if it would be simple to achieve.
For the implementation
- the header "
buffhandle.hpp" would have to include "type-descriptor.hpp" - a templated function would be added to class
BuffDescr - this function would create a
TypeHandlerinstance in exactly the same way as the existing functionBufferProvider::getDescriptor<TY> (args...)does - however, a further function needs to be added to the
BufferProvider::BufferStageAPI - and the implementation would have to care for two additional tweaks
- perform a size-check, and use the buffer size of the »parent type«, instead of defining a new buffer type with
sizeof(TY) - in the
BufferMetadataimplementation, a check must be made if the current type already has aTypeHandler— if so, a sibling type must be created, otherwise a sub type
- perform a size-check, and use the buffer size of the »parent type«, instead of defining a new buffer type with
