[PR #439] [CLOSED] fix(nvidia): zero-copy via dmabuftocuda #468

New issue

Closed

opened 2026-10-15 13:00:48 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:48 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/439
Author: @JBailes
Created: 6/21/2026
Status: ❌ Closed

Base: stable ← Head: fix/nvidia-zero-copy

📝 Commits (1)

10db502 fix(nvidia): zero-copy via dmabuftocuda

📊 Changes

2 files changed (+13 additions, -2 deletions)

View changed files

📝 src/moonlight-server/state/configTOML.cpp (+6 -1)
📝 src/moonlight-server/state/default/config.v7.toml (+7 -1)

📄 Description

Nvidia zero-copy was broken. The producer pushed memory:CUDAMemory over the interpipe; CUDAMemory can't cross it (bound to a CUDA context the per-client consumer do't share), and cudaupload has no memory:DMABuf sink caps, so it can't import the dmabuf either.

VAAPI works because it carries a DMABuf over the interpipe. This makes Nvidia do the same.

Fix (2 files):

producer caps: memory:CUDAMemory → memory:DMABuf, drm-format=NV12
nvcodec video_params_zero_copy: cudaupload → queue ! dmabuftocuda

dmabuftocuda imports the dmabuf into CUDA in the consumer (EGLImage, no sysmem copy), where the encoder's CUDA context lives.

Needs: gst-wayland-display built with the cuda feature (provides dmabuftocuda). The Dockerfile pin predates it bump the pin.

Tested on an RTX 5080: the chain waylanddisplaysrc → DMABuf(NV12) → interpipe → queue → dmabuftocuda → cudaconvertscale → CUDAMemory → nvh265enc encodes H.265. Daemon boots logging Using zero copy pipeline on Nvidia. Not run: a live Moonlight session.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/439 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 6/21/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `fix/nvidia-zero-copy` --- ### 📝 Commits (1) - [`10db502`](https://github.com/games-on-whales/wolf/commit/10db502d0e11c9aac8e2342f2ec67277fc0fec05) fix(nvidia): zero-copy via dmabuftocuda ### 📊 Changes **2 files changed** (+13 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-server/state/configTOML.cpp` (+6 -1) 📝 `src/moonlight-server/state/default/config.v7.toml` (+7 -1) </details> ### 📄 Description Nvidia zero-copy was broken. The producer pushed `memory:CUDAMemory` over the interpipe; CUDAMemory can't cross it (bound to a CUDA context the per-client consumer do't share), and `cudaupload` has no `memory:DMABuf` sink caps, so it can't import the dmabuf either. VAAPI works because it carries a DMABuf over the interpipe. This makes Nvidia do the same. **Fix (2 files):** - producer caps: `memory:CUDAMemory` → `memory:DMABuf, drm-format=NV12` - nvcodec `video_params_zero_copy`: `cudaupload` → `queue ! dmabuftocuda` `dmabuftocuda` imports the dmabuf into CUDA in the consumer (EGLImage, no sysmem copy), where the encoder's CUDA context lives. **Needs:** gst-wayland-display built with the cuda feature (provides `dmabuftocuda`). The Dockerfile pin predates it bump the pin. **Tested** on an RTX 5080: the chain `waylanddisplaysrc → DMABuf(NV12) → interpipe → queue → dmabuftocuda → cudaconvertscale → CUDAMemory → nvh265enc` encodes H.265. Daemon boots logging `Using zero copy pipeline on Nvidia`. Not run: a live Moonlight session. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:48 +00:00