Opened at 2024-12-23T22:12:23Z
Last modified at 2026-05-12T17:05:09Z
#1387 new todo
Memory handling scheme for render buffers
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | render steam roadmap VerticalSlicePlayback |
| Sub Tickets: | #824, #834, #1363, #1367, #1396, #1428, #1429, #1430 | Parent Tickets: | #905, #1369, #1370, #1392, #1412 |
Description
As a Lumiera developer,
I need a consolidated scheme for dealing with temporary and output buffers,
to be able to pass invocation from a Render Job into the Render Nodes.
consolidation of framework drafts
Several years ago, as part of the initial (stalled) efforts to build a Render Node invocation, and later the (still valid) foundation of the Player subsystem, two similar and partially overlapping handling protocols were defined:
- Buffer Provider Protocol
- Output Slot Protocol
The latter even re-uses a concept introduced for the former: the BuffHandle front-end to be used by client code.
The integration efforts for the »Playback Vertical Slice« however uncovered some discrepancies in the intended usage of these protocols: notably the OutputSlot provides a DataSink and expects that the client invokes DataSink::emit(FrameID, BuffHandle) when data is ready for output. Yet the Buffer Provider Protocol defines another function BuffHandle::emit() — and obviously the code in the Render Nodes will invoke the latter, since it can not even know when a given BuffHandle represents an output.
Another shortcoming unveiled by the integration effort is the very much prototype-y nature of the default implementation, which unfortunately was tied-in much too tightly with the interfaces. Notably, the BufferProvider relies directly on a BufferMetadata table attached as an implementation component to track the buffer's state transitions — which makes usage in a highly concurrent environment quite challenging.
The Concepts and protocols as such seem valid and should be retained; the task is rather to loosen the overly tight coupling to the default implementation and to change the interface design in a way to make both protocols better composable.
Change history (6)
comment:1 by , at 2025-02-03T20:58:46Z
| blocking: | 905, 1369, 1370 → 905, 1369, 1370, 1392 |
|---|
comment:2 by , at 2025-02-19T15:26:53Z
| blockedby: | 824, 834, 1363, 1367 → 824, 834, 1363, 1367, 1396 |
|---|
comment:3 by , at 2025-12-25T00:00:00Z
| blockedby: | 824, 834, 1363, 1367, 1396 |
|---|---|
| blocking: | 905, 1369, 1370, 1392 |
| Parent Tickets: | → 905, 1369, 1370, 1392 |
| Sub Tickets: | → 824, 834, 1363, 1367, 1396 |
comment:4 by , at 2026-02-19T16:51:47Z
| Parent Tickets: | 905, 1369, 1370, 1392 → 905, 1369, 1370, 1392, 1412 |
|---|
comment:5 by , at 2026-05-12T01:03:50Z
| Sub Tickets: | 824, 834, 1363, 1367, 1396 → 824, 834, 1363, 1367, 1396, 1429 |
|---|
Add subticket #1429 (control effort for global buffer allocator).
comment:6 by , at 2026-05-12T16:58:07Z
| Sub Tickets: | 824, 834, 1363, 1367, 1396, 1429 → 824, 834, 1363, 1367, 1396, 1428, 1429, 1430 |
|---|

Attach to parent #1412 (clarify the role of Buffer Types).