ALVR Roadmap 解读：Compositor 重写、Vulkan 视频编码与 Monado 驱动的演进路线-平芜编程栈

音视频
图形学

【免费下载链接】ALVR

Stream VR games from your PC to your headset via Wi-Fi

项目地址：https://gitcode.com/gh_mirrors/al/ALVR

ALVR（Air Light VR）通过 Wi-Fi 将 PC 端的 VR 游戏画面无线串流到头显，其官方路线图 wiki/Roadmap.md 明确了项目的长期目标——「在 XR 设备之间建立一座通用桥梁」，并列出三大核心演进方向：Compositor（合成器）重写、Encoder（编码器）重写和 Monado 驱动支持。本文以该路线图为主线，结合当前仓库源码逐一拆解每项计划的动机、落地状态与技术原理，帮助读者理解 ALVR 架构走向以及 Linux 平台特性（FFR、色彩校正、Vulkan 视频编码）在其中的位置。

长期目标：成为 XR 设备之间的通用桥梁

路线图开篇即点明项目的北极星：Create a universal bridge between XR devices（在 XR 设备之间建立通用桥梁）。

这句话包含两层含义：

设备侧解耦：ALVR 的客户端不再是只针对某一厂商头显的专用实现，而是基于 OpenXR 这一跨厂商运行时标准。仓库中的alvr/client_openxr即是以 OpenXR 为核心构建的客户端（其 lib.rs 通过openxrcrate 加载libopenxr_loader.so并创建 XR 实例），配合 extra_extensions 目录下的各厂商可选扩展（如 Meta 的 passthrough、HTC 的面部追踪、肢体追踪等），实现对不同头显与不同运行时能力的适配。
运行时侧解耦：服务端（streamer）目前主要对接 SteamVR（通过alvr/server_openvr的 OpenVR 驱动实现），而路线图规划的 Monado 驱动则试图让服务端也能对接其他 XR 运行时，进一步扩大「通用桥梁」的覆盖面。

理解这一长期目标，就能理解后续三项短期计划为何优先：它们都是为了让「通用桥梁」在不同操作系统、不同 GPU 硬件、不同运行时上都能成立。

路线一：Compositor 重写——为 Linux 补齐 FFR 与色彩校正

目的：补齐 Linux 渲染能力，为分片编码铺路

路线图指出 Compositor 重写的目的是：为 Linux 增加 FFR（Fixed Foveated Rendering，固定注视点渲染）与色彩校正支持，并为分片编码（sliced encoding）做准备。

现状：FFR 与色彩校正已在全平台完成

路线图给出的状态是：FFE（应为 FFR 的笔误，原文如此）与色彩校正已在所有平台完成。从仓库源码可以印证这一点：

Linux（Vulkan）侧：alvr/server_openvr/cpp/platform/linux/FrameRender.h中定义了ColorCorrection与FoveationVars两套着色器常量结构（分别包含 brightness/contrast/saturation/gamma/sharpening 与 eyeWidthRatio/centerSizeX/edgeRatioX 等参数），并提供setupColorCorrection()、setupFoveatedRendering()接口；对应的 compute shader 源码位于 shader/color.comp 与 shader/ffr.comp。
Windows（D3D11）侧：对应实现为 win32/FFR.cpp、win32/FFR.h 以及 HLSL 版本的色彩校正着色器 ColorCorrectionPixelShader.hlsl。
统一嵌入：alvr/server_openvr/src/graphics.rs通过include_bytes!把 Linux 侧预编译好的 SPIR-V（quad.comp.spv、color.comp.spv、ffr.comp.spv、rgbtoyuv420.comp.spv）与 Windows 侧的ColorCorrectionPixelShader.cso一并嵌入 Rust 二进制，再由 C++ 渲染管线加载。

源码级原理：FFR 与色彩校正的实现细节

FFR（固定注视点渲染）：其核心思想是降低画面边缘的采样分辨率，把宝贵的编码带宽集中到视野中心。Linux 端的 ffr.comp 以 8×8 工作组对合成纹理做 compute pass：

通过constant_id传入eyeSizeRatioX/Y、centerSizeX/Y、edgeRatioX/Y等配置（对应设置项中的中心区域大小与边缘压缩比）；
左右眼各按自己的中心偏移（centerShiftLeft/Right，通过 push constant 传入）执行CompressAxis()轴向压缩，压缩曲线保证中心区域保持原始分辨率、边缘区域渐进降采样；
右眼方向在TextureToEyeUV()中做水平翻转（(1 - x) * 2），以正确对应镜像后的右眼图像。

色彩校正：Windows 侧 HLSL 版 ColorCorrectionPixelShader.hlsl 展示了完整处理链：先做 8 邻域锐化（sharpenNeighbourWeight = -sharpening / 8.），再依次叠加亮度（pixel += brightness）、对比度（(pixel - 0.5) * contrast + 0.5）、饱和度（与 luma 的lerp后取 lighten 混合），最后做 gamma 校正（pow(pixel, 1. / gamma)）。这些参数与 dashboard 中「视频/图像调整」类设置一一对应。

为什么与分片编码相关

分片编码（sliced encoding）将单帧画面切成多个独立条带并行编码，能显著降低编码延迟。而 FFR 的「中心高分辨率、边缘低分辨率」输出恰好需要精细的条带划分才能充分发挥并行编码优势；Compositor 重写正是在渲染与合成侧为这一能力做结构性准备。

路线二：Encoder 重写——以 Vulkan 视频扩展统一跨平台编码

目的：单 API 覆盖所有系统与硬件

路线图指出 Encoder 重写的目的是：使用Vulkan 视频扩展（Vulkan Video Extensions），以单一 API支持任意操作系统与任意硬件。

这是 ALVR 面临的最大跨平台痛点：当前仓库中编码后端按平台与厂商分散实现：

alvr/server_openvr/cpp/platform/win32/下有VideoEncoderNVENC.cpp、VideoEncoderAMF.cpp（AMD）、VideoEncoderVPL.cpp（Intel）三套 Windows 专属实现；
alvr/server_openvr/cpp/platform/linux/下则有EncodePipelineVAAPI.cpp（VAAPI 硬件编码）与EncodePipelineSW.cpp（软件编码），以及 NVIDIA 专属的EncodePipelineNvEnc.cpp，它们统一通过 EncodePipeline.h 暴露的PushFrame()/GetEncoded()抽象接口工作。

这种「每平台一套编码器」的模式维护成本极高。Vulkan 视频扩展（VK_KHR_video_encode_*）的设想是：让编码能力成为 Vulkan 核心 API 的一部分，届时 ALVR 只需编写一个基于 Vulkan 的编码管线，就能在 Windows、Linux 上同时覆盖 NVIDIA/AMD/Intel 甚至未来其他厂商的硬件。

现状：受制于厂商支持进度

路线图给出的状态是：该计划被厂商采用进度阻塞——等待 AMD 与 Intel 采纳该规范、以及该特性稳定落地到 NVIDIA 正式版驱动。仓库中的实际编码链路也印证了这一点：Linux 端目前仍走 FFmpeg 的AV_HWDEVICE_TYPE_VULKAN硬件设备路径（见 ffmpeg_helper.cpp 中的av_hwdevice_ctx_alloc(AV_HWDEVICE_TYPE_VULKAN)，编码后的帧以AV_PIX_FMT_VULKAN布局交给 FFmpeg 处理），说明 Vulkan 视频编码尚未成为可依赖的通用通道，FFmpeg 依然是中间层。这正是「被厂商采用进度阻塞」的直接体现。

此外，仓库alvr/xtask/patches/下的多份 FFmpeg 补丁（如 VAAPI 编码器全局头强制开启、动态码率调整、filler data 支持等）也说明：在 Vulkan 视频扩展成熟之前，ALVR 需要借助 FFmpeg 补丁来弥补各硬件编码器的能力缺口。

路线三：Monado Driver——让服务端支持更多运行时

目的：以 streamer 服务其他运行时

路线图指出 Monado Driver 的目的是：让 streamer 能够支持 SteamVR 之外的其他 XR 运行时。Monado 是开源的 OpenXR 运行时实现，若 ALVR 服务端能作为 Monado 的驱动存在，则任何使用 Monado（或兼容 OpenXR 的 Linux 运行时环境）的设备/应用都能直接接入 ALVR 的串流能力，而不必依赖 SteamVR。

这与长期目标「XR 设备之间的通用桥梁」一脉相承：客户端侧已有alvr/client_openxr支撑 OpenXR 头显，服务端侧若能经 Monado 覆盖开源运行时，ALVR 就能同时打通「头显端」与「运行时端」两条生态。

现状：阻塞于重构

路线图给出的状态是：该计划阻塞在重构工作上。从源码结构看，服务端目前与 SteamVR 的绑定较深：alvr/server_openvr/cpp/alvr_server/内含完整的 OpenVR 驱动实现（HMD.cpp、Controller.cpp、TrackedDevice.cpp、PoseHistory.cpp、Settings.cpp等），驱动逻辑与 SteamVR 的接口、追踪语义耦合紧密。要让服务端适配 Monado 的驱动接口，需要先把这些逻辑从 OpenVR 特有概念中剥离出来，形成运行时无关的通用层——这正是路线图所说「blocked on refactors」的含义。

开发节奏的现实约束

路线图最后坦率说明：由于开发力量有限，无法给出任何时间表（ETA）；新版本发布没有固定节奏，也不承诺固定特性集。

这一点与仓库现状相符：ALVR 是高度依赖 GPU 厂商驱动能力与行业标准（Vulkan 视频、OpenXR 生态）成熟度的开源项目，三条主要路线均处于「受外部条件制约」的状态。对使用者而言，这意味着：

关注官方 CHANGELOG（CHANGELOG.md）与 wiki/How-ALVR-works.md、wiki/Roadmap.md 即可了解功能演进；
新特性不会按固定排期发布，重大能力（如分片编码、Vulkan 原生编码）会以「依赖项就绪 + 重构完成」为前提逐步落地；
当前可直接验证的进展是：FFR 与色彩校正已覆盖全平台（Windows 与 Linux），这是 Composititor 重写中已交付的部分。

小结

ALVR 的路线图可以概括为一句话：以「XR 设备间的通用桥梁」为终点，通过三条相互关联的工程路线推进——Compositor 重写（已在 Linux 落地 FFR 与色彩校正，为分片编码做准备）、Encoder 重写（等待 Vulkan 视频扩展被 AMD/Intel 采用并稳定到 NVIDIA 正式驱动）、Monado 驱动（等待服务端运行时无关重构完成）。三条路线均无固定时间表，但前者的阶段性成果（全平台 FFR 与色彩校正）已在当前仓库源码中完整可查、可运行，是理解 ALVR 架构演进的最佳入口。