Opened at 2025-02-19T15:26:53Z
Last modified at 2026-05-31T22:29:38Z
#1396 accepted todo
preliminary BufferProvider for rendering
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | grave | Milestone: | 0integration |
| Component: | lumiera | Keywords: | render steam VerticalSlicePlayback |
| Sub Tickets: | #824, #836, #1367, #1395, #1410, #1425, #1426 | Parent Tickets: | #1373, #1387, #1411, #1427, #1429 |
Description
As a Lumiera developer,
I need »just some reasonably braindead« BufferProvider implementation,
so that I can use the Render Node network for actual media computations.
Acceptance Criteria
- Given
-
- a suitably defined and connected setup of Render Nodes
- a render-job to trigger invocation of this network's exit point
- When
-
the preliminary
BufferProvideris configured through theEngineCtx - Then
-
the job can perform real media data computations
- with arbitrary (but reasonable) buffer sizes
- at »base level« performance (enough to compute a simple animation for a small window in real time)
- without leaking memory.
Change history (12)
comment:1 by , at 2025-12-25T00:00:00Z
| blockedby: | 824, 1367, 1395 |
|---|---|
| blocking: | 1373, 1387 |
| Parent Tickets: | → 1373, 1387 |
| Sub Tickets: | → 824, 1367, 1395 |
comment:2 by , at 2026-02-09T22:04:46Z
| Sub Tickets: | 824, 1367, 1395 → 824, 1367, 1395, 1410 |
|---|
Add subticket #1410 (clean-up BufferProvider base implementation).
comment:3 by , at 2026-02-19T01:38:35Z
| Parent Tickets: | 1373, 1387 → 1373, 1387, 1411 |
|---|
Attach to parent #1411 (Aliasing of Buffer TypeHandler instances).
comment:4 by , at 2026-04-14T23:22:44Z
| Sub Tickets: | 824, 1367, 1395, 1410 → 824, 1367, 1395, 1410, 1425, 1426 |
|---|
comment:5 by , at 2026-04-16T19:21:24Z
| Parent Tickets: | 1373, 1387, 1411 → 1373, 1387, 1411, 1427 |
|---|
Identified and postponed a possible performance-penalty related to thread_local storage: see #1427 (performance-impact of thread_local).
Generally speaking, I prefer to build a clearly structured implementation of the engine first, placing more weight on separation of concerns (even at the cost of some additional indirection), than immediately engaging into a performance-centric solution; the rationale is that the latter is known to be a one-way route.
comment:6 by , at 2026-05-11T23:20:22Z
| Sub Tickets: | 824, 1367, 1395, 1410, 1425, 1426 → 824, 836, 1367, 1395, 1410, 1425, 1426 |
|---|
Add subticket #836 (frontend for plain simple allocations).
comment:7 by , at 2026-05-12T01:03:51Z
| Parent Tickets: | 1373, 1387, 1411, 1427 → 1373, 1387, 1411, 1427, 1429 |
|---|
Attach to parent #1429 (control effort for global buffer allocator).
comment:8 by , at 2026-05-29T15:38:04Z
| Owner: | set to |
|---|---|
| Status: | new → accepted |
During the last two weeks, I have effectively laid the groundworks for a production-grade buffer manager for the render engine. What is there now goes far beyond »preliminary« — yet I skipped any elaboration regarding the Buffer Allocator.
Both »pillars« of the BufferProvider implementation are now configured as LocalSlice, so that each worker thread will see its own thread-local copy of the relevant low-level service — which implies there is a distinct BufferMetadata instance and a LocalMemPool in each thread. Furthermore, an asynchronous communication scheme has been established to connect those local services to the central EngineMetadata and EngineBufferManager
The latter can receive and submit allocation requests — yet will pass-through any actual allocation or deallocation directly to the regular heap allocator. However, the plan is to build a set of buffer pools here — so in this respect the current implementation is »preliminary« (and presumably good enough for quite some time to come)
Conducting some load tests currently, but the new implementation seems to work correct thus far...

Migration MasterTickets ⟼ Subtickets-plugin