#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 BufferStore implementation, 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 BufferStage interface is a bit more challenging, since it embeds a hierarchical BufferMetadata table. 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 Ichthyostega, at 2026-05-11T15:45:02Z

Parent Tickets: 13961396, 1428

Attach to parent #1428 (Engine Buffer Manager).

comment:2 by Ichthyostega, at 2026-05-12T01:03:50Z

Parent Tickets: 1396, 14281396, 1428, 1429

Attach to parent #1429 (control effort for global buffer allocator).

comment:3 by Ichthyostega, at 2026-06-01T21:26:54Z

Resolution: done
Status: newclosed

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 LocalBufferStage implementation embeds a LocalSlice<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 EngineBufferMetadata also embeds a BufferMetadata table, 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.

Note: See TracTickets for help on using tickets.