[GH-ISSUE #449] [FR] Support multi-GPU load balancing #278

New issue

Open

opened 2026-10-15 12:59:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:59:16 +00:00

Owner

Originally created by @ABeltramo on GitHub (Jun 26, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/449

We've got multi-user already, including multiple independent games and co-op lobbies for multiple users. Now, the natural extension is supporting multi-GPU setups where one instance of Wolf can start games and encoding pipelines on multiple GPUs when available.

The high level idea is that in Wolf-UI, before launching an app, users can freely pick a GPU to use for that app/game. This makes the implementation easier because we don't have to came up with some complex heuristic to automatically determine the "best available GPU node" (spoiler: any heuristic will be more or less broken).

Wolf-UI itself needs to already run on a GPU though, we can start simple with defaulting to the currently available WOLF_RENDER_NODE but, in future, we might want to try running the Wayland rendering + encoding pipeline on a GPU and then, if it fails, automatically switch over the next available GPU. This will be particularly important in order to get around the limit of how many concurrent encoding sessions are possible on a given GPU (ex Nvidia)

Implementation details

Thinking about this, we need at the very least:

On Wolf startup, probe for all GPUs available to detect available encoders and settings
At the API level, expose something like /api/v1/gpus which returns not only a list of render nodes but also the capabilities available (ex: H264,HEVC, HEVC 4:4:4, HEVC HDR, etc.)
- This is because Wolf UI will need to pick a "valid GPU", AKA something that can encode what the current Moonlight client required
- The current /api/v1/lobbies/create already supports wayland_render_node and runner_render_node so we should be fine there.
Support switching the encoding pipeline to a new GPU. This might be as brutal as destroying the pipeline and re-start on the new GPU (causing frame drops in Moonlight) or dynamically switching just the encoder when changing the interpipe producer
- We really want to keep rendering and encoding on the same GPU to keep achieving a zero-copy pipeline. Gaming is very much latency sensitive and copying the framebuffer between GPUs is really bad.

Originally created by @ABeltramo on GitHub (Jun 26, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/449 We've got multi-user already, including multiple independent games and co-op lobbies for multiple users. Now, the natural extension is supporting multi-GPU setups where one instance of Wolf can start games and encoding pipelines on multiple GPUs when available. The high level idea is that in Wolf-UI, before launching an app, **users can freely pick a GPU to use for that app/game**. This makes the implementation easier because we don't have to came up with some complex heuristic to automatically determine the "best available GPU node" (spoiler: any heuristic will be more or less broken). Wolf-UI itself needs to already run on a GPU though, we can start simple with defaulting to the currently available `WOLF_RENDER_NODE` but, in future, we might want to try running the Wayland rendering + encoding pipeline on a GPU and then, if it fails, **automatically switch over the next available GPU**. This will be particularly important in order to get around the limit of how many concurrent encoding sessions are possible on a given GPU (ex [Nvidia](https://developer.nvidia.com/video-encode-decode-support-matrix#Encoder)) ## Implementation details Thinking about this, we need at the very least: - On Wolf startup, **probe for all GPUs available** to detect available encoders and settings - At the API level, expose something like `/api/v1/gpus` which returns not only a list of render nodes but also the capabilities available (ex: `H264`,`HEVC`, `HEVC 4:4:4`, `HEVC HDR`, etc.) - This is because Wolf UI will need to pick a "valid GPU", AKA something that can encode what the current Moonlight client required - The current `/api/v1/lobbies/create` **already supports** `wayland_render_node` and `runner_render_node` so we should be fine there. - Support switching the encoding pipeline to a new GPU. This might be as brutal as destroying the pipeline and re-start on the new GPU (causing frame drops in Moonlight) or dynamically switching just the encoder when changing the interpipe producer - We really want to **keep rendering and encoding on the same GPU** to keep achieving a zero-copy pipeline. Gaming is very much latency sensitive and copying the framebuffer between GPUs is really bad.