Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

VRAM leak: orphaned DMA-BUFs sized to physical monitor accumulate while streaming a virtual headless output (wlr capture, NVENC)

Aperta
  • Qualcosa non va?
#5,810 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp, linux
Ambito
computer-graphics, performance

Direzione di ricerca

Start by tracing Sunshine's wlr capture entry point and its zwlr_screencopy_manager_v1 DMA-BUF lifecycle while reproducing the headless-output case with the measurements described. Compare allocation and release behavior during streaming, disconnect, and Sunshine restart; done means unattributed VRAM and orphaned DMA-BUF counts remain flat and return to baseline after disconnect.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the Bug

Streaming from a virtual headless output leaks VRAM as orphaned DMA-BUFs that
are visible in neither nvidia-smi's process list nor any process's fd table.
The leak accumulates continuously (~1.3 GB/h) while a stream is active, and
survives client disconnect — only restarting Sunshine frees it.

Measured on an RTX 5090 32GB over two sessions:

  • ~30 GB VRAM unaccounted for after ~2 days of intermittent streaming
  • 24.9 GB leaked after one overnight session; freed instantly by
    systemctl --user restart sunshine (24893 → 2723 MiB)
  • 1-hour instrumented run: unattributed VRAM grows 1819 → 2570 MiB while
    streaming, stays flat after client disconnect, grows again on reconnect

Key observation: leaked buffers match the physical monitor, not the streamed one

/sys/kernel/debug/dma_buf/bufinfo (as root) shows thousands of leaked
buffers with refcount 2 and no attached devices:

size       flags      mode       count    exp_name  ino       name
39321600   00000002   02080007   00000002 drm       00974892  <none>
  Attached Devices:
  Total 0 devices attached
... (repeated ~800x, plus a second size class)
20971520   00000002   02080007   00000002 drm       00974746  <none>
  • 39321600 bytes = exactly 3840×2560×4 → the physical monitor (BenQ RD280U)
  • 20971520 bytes = 2048×2560×4 (aligned variant)
  • The streamed output is a virtual headless monitor "SUNSHINE" at 1512×982
    (output_name = SUNSHINE), i.e. the leaked buffers are the wrong size for
    the capture target — they appear to be allocated per capture cycle against
    the physical display and never released.

Config

capture = wlr
output_name = SUNSHINE

Hyprland (Wayland). Sunshine uses the zwlr_screencopy_manager_v1 path
("Screencasting with Wayland's protocol" in the log), NVENC encoder.

Environment

  • Sunshine 2026.914.233613, commit 63d35f702ee9e362e43263742981836ec0710384
    (includes #4757, #4588, #5023 — behavior persists)
  • Arch Linux, Hyprland (wlroots screencopy), NVIDIA RTX 5090
  • Driver: nvidia-open-dkms 610.57.04
  • Note: nvidia-open 610.x exposes no /sys/kernel/debug/nvidia client list, so
    the leak is only visible via dma_buf/bufinfo and by diffing
    nvidia-smi --query-gpu=memory.used against the attributed process sum.

Reproduction

  1. Hyprland with one physical 4K monitor + one headless output (e.g.
    hyprctl output create headless SUNSHINE), Sunshine output_name = the
    headless output, capture = wlr
  2. Stream for ~1 hour; periodically measure unattributed VRAM =
    nvidia-smi --query-gpu=memory.used minus the process sum
  3. Disconnect the client — leak does not drop
  4. systemctl --user restart sunshine — leak drops to baseline instantly

Expected behavior

DMA-BUFs used for capture should be released when the frame is consumed; VRAM
usage should stay flat (minus normal encoder buffers) for the session
lifetime and drop on client disconnect.

Lingua principale
C++
Stelle
41.4k
Fork
2.1k
Merge medio
20h 19m
PR unite (30g)
125

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LizardByte/Sunshine

Tutte le issue di LizardByte/Sunshine

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.