Opened at 2026-04-14T23:22:44Z
Closed at 2026-06-01T21:26:54Z
#1426 closed todo (done)
Worker-local BufferProvider implementation
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | grave | Milestone: | 0integration |
| Component: | lumieraVault | Keywords: | render design VerticalSlicePlayback |
| Sub Tickets: | #1425 | Parent Tickets: | #1396, #1428, #1429 |
Description
As a Lumiera developer,
I need a thread-local flavour of both BufferProvider back-ends,
so that I can configure a BufferProvider instance capable to operate in a massive parallel environment.
envisaged solution
- with #1425 an adapter was developed to operate the base implementation in a thread-local setup
- for the
BufferStoreimplementation, it seems fairly straight forward to create a simple implementation that uses a small local allocation pool, while resolving any memory discrepancy directly with heap allocations / deallocations - the
BufferStageinterface is a bit more challenging, since it embeds a hierarchicalBufferMetadatatable. For a preliminary implementation however, it seems sufficient to add a function for exchange of medatata chains. This could then be used with simple Mutex-based locking in those (exceptional) cases where a thread-local slice is confronted with a buffer allocation request that refers to a buffer type not known locally.
Change history (3)
comment:1 by , at 2026-05-11T15:45:02Z
| Parent Tickets: | 1396 → 1396, 1428 |
|---|
comment:2 by , at 2026-05-12T01:03:50Z
| Parent Tickets: | 1396, 1428 → 1396, 1428, 1429 |
|---|
Attach to parent #1429 (control effort for global buffer allocator).
comment:3 by , at 2026-06-01T21:26:54Z
| Resolution: | → done |
|---|---|
| Status: | new → closed |
During the last weeks, a production grade implementation for the Render Engine buffer management was prototyped. This setup works correct under concurrent pressure, as demonstrated with BufferProviderLoad_test
For the Buffer Stage back-end (metadata handling), a system of replicated storage was established:
- the
LocalBufferStageimplementation embeds aLocalSlice<BufferMetadata> - there are two distinct situations in the metadata handling, where an up-sync or down-sync of buffer type information becomes necessary
- these situations are considered a rare exceptional case, since, on average, all relevant buffer type information should have been accrued already within each render worker
- data synchronisation can thus be protected by a simple mutex lock
- the global service
EngineBufferMetadataalso embeds aBufferMetadatatable, yet exposes a slightly simplified API, but with the addition of data synchronisation functionality
For the Buffer Store back-end, a system of thread-local memory pools was established. The implementation class LocalMemPool supports the primitive operations to announce, claim and release a memory block. Furthermore, a heuristic scheme for clean-up was devised, based on tracking a usage score for each memory allocation in the local pool. A connection to the global EngineBufferManager is established through lock-free queues (using boost::lockfree), with a fall-back on a synchronised direct call whenever buffer capacity is required immediately. The expectation is however that each Render Job will send an announcement of expected capacity beforehand, so that the memory demand can be accommodated with the help of the local pool, and possibly additional allocation requests sent asynchronously.

Attach to parent #1428 (Engine Buffer Manager).