# Foundation Sunshine: a Windows-focused Sunshine fork with HDR10+ and HDR Vivid > Foundation Sunshine is a GPL-3.0 fork of LizardByte/Sunshine aimed at Windows game streaming to Moonlight. It adds dual-format HDR encoding, a virtual display driver, 12-channel audio and a Tauri control panel, at the cost of a Windows 10 22H2 floor. **AlkaidLab/foundation-sunshine** — Sunshine fork: an enhanced sunshine, a self-hosted game streaming host for Moonlight with HDR10/HDR Vivid, virtual displays, advanced audio, optimized encoders, and a modern control panel. - Repository: https://github.com/AlkaidLab/foundation-sunshine - Website: https://www.alkaidlab.com - Stars: 6,888 · Forks: 185 - Language: C++ - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/alkaidlab-foundation-sunshine ## What Foundation Sunshine changes about the Sunshine baseline Sunshine already does the core job: it runs on a host machine, captures the desktop or a game, encodes it with the GPU, and serves it to a Moonlight client over the network. Foundation Sunshine keeps that model and concentrates on the Windows host side of it. The README describes the project as an enhanced branch of LizardByte/Sunshine focused on the Windows game streaming experience, and the feature list backs that up: HDR handling, a virtual display driver, audio channel expansion, encoder tuning, folder sharing and a rebuilt control panel. The audience is narrow and specific. If you stream from a Windows PC to a TV or handheld and you care about HDR output, this fork is aimed at you. If you stream from a Linux box, the README's system requirements table lists Windows 10 22H2 or newer as the only operating system, so the documented path does not cover you. The repository does carry Linux, Windows and macOS CodeQL prebuild scripts at the top level and a docker/ directory, which suggests the upstream build scaffolding survives, but the README does not document a Linux or macOS deployment. Treat the extra platform files as inherited structure, not as a supported target. ## Dual-format HDR: PQ and HLG on the same encoder pipeline The most substantive design decision is that HDR is handled as two parallel formats rather than one. The README explains the reasoning: PQ (the HDR10 absolute luminance mapping) loses shadow detail and clips highlights when the display cannot match the reference brightness, so the fork adds HLG (Hybrid Log-Gamma, ITU-R BT.2100) alongside it. HLG is scene-referred, so the display performs its own tone mapping against its peak brightness, and the README notes that an HLG signal can also be decoded as standard BT.709 on an SDR display without a separate tone-mapping step. On top of that sits per-frame luminance analysis. A compute shader computes MaxFALL and MaxCLL for each frame, injects them into HEVC or AV1 SEI or OBU metadata, filters outliers with a percentile cutoff so a single specular highlight does not drag the whole frame darker, and smooths the statistics across frames with an exponential moving average to avoid brightness flicker at scene cuts. The NVENC path then generates HDR10+ (ST 2094-40) and HDR Vivid (CUVA T/UWA 005.3, carried in ITU-T T.35) dynamic metadata SEI from those per-frame results. That is a heavier pipeline than plain HDR10 passthrough, and the README is honest that the static metadata path (Mastering Display Info plus Content Light Level) is a passthrough, while the dynamic metadata is generated. The practical consequence: your client has to understand what you send. A Moonlight build that only handles HDR10 static metadata will not benefit from the HDR10+ or HDR Vivid SEI, and the README's recommended client list is a set of forks rather than the stock clients. ## Virtual displays, Zako Direct and the Windows 10 22H2 requirement The virtual display integration is built on ZakoVDD, a separate virtual display driver. The README states it requires Windows 10 22H2 or newer, supports custom resolutions and refresh rates with 10-bit HDR color depth, and offers five screen modes: virtual only, physical only, mixed, mirrored and extended. The host creates and destroys the virtual display automatically at stream start and stop, communicates over IOCTL, and binds each client to its own VDD session via a GUID so multiple clients can switch without a reboot. The interesting part is Zako Direct, described as a zero-copy frame borrow: the encoder borrows the VDD shared frame texture directly and returns it after conversion, which removes one GPU copy from the capture chain. Whether that matters depends on your resolution and refresh rate. At 1080p60 the copy is unlikely to be your bottleneck; at 4K with HDR it is a real cost. The 22H2 floor is the constraint to weigh. It rules out older Windows 10 builds and, combined with the system requirements table, makes this a Windows-only proposition in practice. The README does not describe a fallback path for hosts that cannot run ZakoVDD, so if the driver does not install, the virtual display features are simply unavailable rather than degraded. ## Installing Foundation Sunshine and pairing a first client The README points to a separate usage document hosted on docs.qq.com for setup, plus the upstream LizardByte documentation for the baseline concepts, and a QQ group for support. It does not inline install commands, so the build path below comes from the repository's own docs/building.md reference and package.json rather than from the README. The WebUI is a Vue 3 application built with Vite, and package.json pins the toolchain tightly: Node 26.7.0 or newer but below 27, and npm 11.19.0 or newer but below 12. The prebuild step extracts welcome locales before the Vite build runs. ```bash npm install npm run prebuild npm run build ``` For iterating on the control panel alone, the dev-server script serves the WebUI against a development Vite config, which is faster than rebuilding the whole host: ```bash npm run dev-server ``` There is also a validation script for translations, which matters because the repository ships English, Simplified Chinese, French, German and Japanese READMEs and a crowdin.yml at the top level: ```bash npm run i18n:validate ``` The C++ host itself is a CMake project (CMakeLists.txt and CMakePresets.json at the top level), and the README links docs/building.md for build instructions. Once the host is running, the control panel is where you pair: the README lists QR pairing, dark mode and live monitoring as panel features. After pairing, point your client at the host and start a stream. If HDR is your reason for being here, check the client's own HDR settings before concluding the host side is wrong, since the metadata only helps a client that reads it. ## Audio, encoder caching and the numbers the README does not give The audio section is where the fork diverges most from a typical Sunshine setup. It supports 7.1.4 surround at 12 channels for immersive layouts, Opus DRED for packet loss recovery over a 100 ms redundancy window, a continuous audio stream that fills silence with padding instead of tearing down and reinitializing the device, and automatic bit-depth matching for 16-bit and 24-bit virtual audio devices. The continuous-stream choice is a trade-off: you keep the device alive and avoid reinitialization latency, at the cost of a stream that never fully stops. On the encoder side, the README lists NVENC SDK 13.0 with look-ahead, AMF QVBR, HQVBR and HQCBR with quality levels exposed in the WebUI, AMF multi-hardware-instance encoding, adaptive downsampling in three quality tiers (fast, balanced, high_quality), an experimental Vulkan encoder, and a lock-free certificate chain that replaces a mutex with a shared_mutex. One claim deserves scrutiny. The README states encoder result caching takes subsequent connections from 26 seconds to under 100 ms, a 260x figure. That is a probe-result cache, so the comparison is against a cold probe, not against steady-state connection time. It is a plausible mechanism, but the README gives no test conditions, and you should treat the multiplier as a description of what is cached rather than as a benchmark you can expect on your hardware. ## Where Foundation Sunshine is the wrong choice The clearest limitation is the platform. Every documented feature that makes this fork distinct, the ZakoVDD virtual display, the Windows folder sharing with Explorer right-click integration, the vmouse virtual mouse driver, assumes a Windows host. A Linux user gets a fork whose headline features do not apply, plus the maintenance burden of tracking a downstream branch. The second limitation is release discipline. The three most recent tags are v2026.909.175136.杂鱼, v2026.909.80804.杂鱼 and v2026.903.160345.杂鱼. The version strings embed a non-ASCII suffix and a timestamp, which is fine for a project that ships continuously but awkward for anything that parses versions, and it signals that this is a fast-moving downstream rather than a versioned product. If you need a pinned, predictable upgrade path, upstream Sunshine is the safer base. The third is that the Windows 10 22H2 requirement plus the GPU requirements table (AMD VCE 1.0+, Intel VAAPI or NVIDIA NVENC at minimum) excludes older hardware outright. There is no documented software-encoding fallback for the HDR and virtual display paths, and the README does not describe what happens when ZakoVDD is unavailable. ## How it compares with upstream LizardByte/Sunshine Upstream Sunshine is the reference implementation and the sane default. It is cross-platform, it has its own documentation site, and its release cadence is not tied to one contributor's Windows experiments. If you stream from Linux, or you want the version you install today to be the version you upgrade from in a year with minimal surprises, upstream is the right answer and Foundation Sunshine is not. The difference in approach is where the effort goes. Upstream spreads feature work across platforms and keeps the host generic. Foundation Sunshine spends its complexity budget on the Windows capture-to-encode path: HLG as a second HDR format next to PQ, per-frame luminance analysis feeding generated dynamic metadata, a zero-copy borrow from the virtual display's shared texture, 12-channel audio, and encoder-specific tuning for NVENC and AMF. Those are not features you can replicate with a config flag on upstream. The trade is maintenance direction. A fork inherits upstream's architecture but not upstream's testing surface, and every divergence is a future merge conflict. Foundation Sunshine's last push was on 2026-09-10, and the three releases listed above all landed in the first ten days of September 2026, so the branch is moving. That also means the documentation lags: the README links out to a QQ-hosted usage document and to upstream's docs rather than describing its own configuration keys in the repository. ## Licence, upgrade cost and what to check before you commit Foundation Sunshine is GPL-3.0, the same licence family as the upstream project it forks, and the repository carries both a LICENSE and a NOTICE file. If you only run it on your own hardware to stream your own games, the licence is not something you need to think about. If you intend to redistribute a build, bundle it into a product, or ship a modified client alongside it, the copyleft obligations apply to the combined work, and the NOTICE file is where attribution for inherited components lives. That is a question for a lawyer, not for this article. Upgrade cost is the real ongoing expense. The version scheme is timestamp-based with a non-ASCII suffix, so automated upgrade tooling that expects semantic versions will need adjusting. The WebUI toolchain is pinned to a narrow Node range (26.7.0 up to but not including 27) and npm 11.19.0 up to but not including 12, which means a Node upgrade on your build machine can break the panel build independently of any change in the project. The C++ side is CMake with presets, so it follows the usual pattern, but the ZakoVDD dependency is a separate driver with its own installation and its own Windows version requirement. Before you migrate a working Sunshine setup, verify that your GPU is listed in the NVENC, AMD VCE or Intel VAAPI compatibility matrices the README links, that ZakoVDD installs cleanly on your Windows build, and that your chosen Moonlight client is one of the forks the README recommends, since the HDR metadata and 12-channel audio paths assume a client that reads them. ## Conclusion Adopt Foundation Sunshine if your host is Windows 10 22H2 or newer, your GPU supports NVENC, AMF or QSV, and you specifically want HDR10+ or HDR Vivid metadata plus a virtual display that is created and destroyed per stream. Do not adopt it if you stream from Linux or macOS, or if you need a stable upstream-style release cadence, since the README targets Windows and the release tags carry a non-standard suffix. Before committing, verify three things: that your GPU appears in the NVENC, AMD VCE or Intel VAAPI support matrices linked from the README, that the ZakoVDD driver installs on your Windows build, and that your Moonlight client is one of the forks the README recommends, because the HDR and audio paths assume a matching client. ## FAQ ### Is Foundation Sunshine the same thing as the Sunshine Foundation charity? No. Foundation Sunshine is a GPL-3.0 fork of LizardByte/Sunshine for self-hosted game streaming to Moonlight, hosted at AlkaidLab/foundation-sunshine. It has no connection to any charity of a similar name. ### How does Foundation Sunshine work? It runs on a Windows host, captures the desktop or a game, encodes it with the GPU through NVENC, AMF or QSV, and streams it to a Moonlight client. The fork adds per-frame luminance analysis that generates HDR10+ and HDR Vivid dynamic metadata, plus a ZakoVDD virtual display that is created and destroyed per stream. ### When was Foundation Sunshine first released? The README does not give a first release date. The three most recent releases listed are v2026.909.175136.杂鱼, v2026.909.80804.杂鱼 and v2026.903.160345.杂鱼, all dated in early September 2026, and the last push to the repository was on 2026-09-10. ### Can I run Foundation Sunshine on Linux? The README's system requirements list Windows 10 22H2 or newer as the operating system, and the virtual display, folder sharing and virtual mouse features all assume Windows. The repository does contain Linux and macOS CodeQL prebuild scripts and a docker directory, but the README does not document a Linux or macOS deployment. ### Which Moonlight clients does Foundation Sunshine recommend? The README lists Moonlight-PC for Windows, macOS and Linux, Moonlight V+ and the WACrown build for Android, VoidLink for iOS, and Moonlight V+ from the Huawei AppGallery for HarmonyOS. It states that pairing with these optimized clients gives the best experience, which implies the HDR and audio paths expect a client that reads the extra metadata. ### What GPU do I need for Foundation Sunshine? The README lists AMD VCE 1.0 or newer, Intel VAAPI, or NVIDIA NVENC as the minimum, and AMD VCE 3.1 or newer, Intel HD 510 or newer, or a GTX 1080 or newer for 4K. It links out to NVENC, AMD VCE and Intel VAAPI compatibility matrices for the detail. ## Sources - [AlkaidLab/foundation-sunshine on GitHub](https://github.com/AlkaidLab/foundation-sunshine) - [License: GPL-3.0](https://github.com/AlkaidLab/foundation-sunshine/blob/master/LICENSE) - [Project website](https://www.alkaidlab.com) - [README](https://github.com/AlkaidLab/foundation-sunshine/blob/master/README.md) - [Releases](https://github.com/AlkaidLab/foundation-sunshine/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alkaidlab-foundation-sunshine