Skip to content

Windows lookahead allocates two full-window VRAM pools (~2x the needed VRAM) #451

Description

@mohamedtahaguelzim

With lookahead enabled on a GPU-resident source, run_loop creates the lookahead VramPool sized n + n/2 + 4 slots (run_loop.rs), and on Windows ensure_d3d11_staging (stitch/executor.rs) allocates a second pool with the same formula x2 cameras - the sizing comment even says to keep them in sync. The D3D11VA staging pool must pin frames through the whole lookahead window (slots assigned by produce_index modulo n_slots, no occupancy tracking), so both pools hold the full window at once: at 3840x2160 with 1.5s lookahead that is ~1.77 GB (71 slots) + ~1.76 GB (142 slots) = ~3.5 GB before the encoder starts. On a 6 GB card this is most of free VRAM and matches field freeze reports (#446, mechanism b).

Open question needing a Windows runtime check: on the no-CUDA D3D11VA path rendering appears to work from the shared-handle-imported staging textures, so the VramPool may be entirely unused there - 1.8 GB of dead allocation on precisely the cards that can least afford it.

Direction: render from one canonical residency (staging as the storage, or import-and-release into the pool with a small transit ring), halving Windows lookahead VRAM.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    Projects

    Status
    Done (Released)

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions