6.0 KiB
Ubuntu 点击与悬停延迟新方案（2026-11-06）
结论
当前延迟的关键不是鼠标速度，也不是盒子渲染。VM102 仍由 Sunshine 的 libx264 软件编码输出，盒子端解码、队列和渲染约为 12ms、0.2ms 和 2ms；已测得 Ubuntu KMS 45FPS 的 hover 回显 P50/P95 约 196/220ms，按钮点击约 304/378ms。要接近 Windows，必须优先改变 Ubuntu 端的“真实硬件编码或捕获到编码的零拷贝路径”。
Sunshine 官方文档明确指出：Linux 的 X11 捕获 CPU 开销最高，应尽量使用 KMS；硬件编码可使用 VA-API、QuickSync 或 NVENC，KMS 与 VA-API 兼容。当前已保留 KMS + 原生光标组合，但编码仍是软件路径。Sunshine 配置文档
新计划
1. 先做只读硬件可行性检查
检查 PVE 宿主的 Intel 00:02.0 是否支持稳定的 VFIO 直通、是否有可用的 i915/mdev 能力，以及宿主是否依赖这块核显提供 PVE 或其他虚拟机图形服务。检查 Ubuntu 内核、/dev/dri 权限、vainfo 和 H.264 编码入口。检查只读完成前不改 VM、不重启宿主。
当前 PCI 盘点显示：Intel 4 代核显在 00:02.0，NVIDIA GTX 965M 在 01:00.0 且已分配给 Windows VM100，因此不能挪用 NVIDIA；Ubuntu 的 virtio-gl 只提供 VirGL 图形翻译，不等于真实硬件编码。QEMU VirtIO GPU 文档
已完成的只读预检显示 Ubuntu 当前只暴露 virtio_gpu_dri.so，没有 i965/iHD 编码驱动；i965-va-driver、vainfo 等包在 Ubuntu 软件源中可用，但安装软件包本身不能让 VirGL 变成真实 Intel 编码设备。预检快照见 pve-readonly-preflight.json。
2. 首选路径：给 Ubuntu 使用真实 Intel 编码设备
如果只读检查确认宿主可以安全释放 Intel 核显，则建立 VM102 的备份，安排宿主维护窗口，把 Intel 核显以 VFIO 直通方式交给 Ubuntu，客体安装 Haswell 对应的 VA-API 驱动，先用独立 vainfo 和 FFmpeg 编码测试，再让 Sunshine 只使用 encoder=vaapi、capture=kms。Haswell 属于 intel-vaapi-driver 支持的 H.264 编码平台，但必须看到真实 i915 设备和 VAEntrypointEncSlice；VirGL 暴露的伪 VAAPI 已经在现场触发过 Mesa/virgl 崩溃，不能继续沿用。Intel VA-API 驱动支持表
验收条件是 Sunshine 日志稳定出现 Creating encoder [h264_vaapi]，持续 10 分钟无崩溃、无回退到 libx264，并且 2560×1440 的 hover/click/drag 测试延迟显著下降。失败时只恢复 VM 配置和 Ubuntu 驱动，不碰 Windows VM100、麒麟 VM101 或盒子客户端。
如果宿主不能释放核显，第二选择是增加一块可被 Ubuntu 独占的低功耗硬件编码 GPU。仅升级 VirGL、增加虚拟显存或安装 Mesa 软件包不能替代这一步。
3. 无法获得真实 GPU 时的保底方案
保留当前 capture=kms、host CPU、virtio-gl、H.264 和原生光标，只做有基准的两项实验：
- 评估 QEMU
virtio-gpu的 host memory/blob 配置，目标是减少桌面渲染读回；这只可能改善捕获前的渲染，不能把软件编码变成硬件编码。 - 在宿主只有 4 个物理核的前提下，禁止盲目增加 VM vCPU 或继续堆 x264 线程；每次实验必须用同一套 2K 动态窗口和真实 GNOME 点击/拖拽数据验证，P95 变差就回退。
如果没有真实硬件编码，2K 下无法承诺达到 Windows 的约 90ms。此时应提供两个明确 profile：2K 画质优先，以及 1080p/更高帧率低延迟；由使用场景选择，而不是继续隐藏软件编码瓶颈。
验收与回退
- 同一盒子、同一网络、同一 60Hz 输入注入，分别记录 hover、button click、masked input、长按框选的 P50/P95。
- 同时记录 Sunshine 实际编码器、收流 FPS、主机处理延迟、网络 RTT、盒子解码/渲染耗时。
- 只有出现真实
h264_vaapi/h264_qsv且延迟和尾部都改善，才保留新路径；出现崩溃、软件回退、画面损坏或 P95 变差立即恢复备份。 - 全部测试结束后恢复 Ubuntu 正常 Sunshine 服务、关闭原生光标守护租约，盒子回到桌面列表。
该方案的核心变化是先验证“真实硬件编码是否可用”，而不是再调鼠标主题、速度、虚拟显存或客户端队列。
2026-11-06 直通验证结果
本轮按计划对 VM102 做了可回退试验：临时使用 hostpci0=0000:00:02.0,pcie=1,rombar=0 和 vga=std，Ubuntu 成功识别 Intel HD 4600 的 i915，vainfo 显示 VAProfileH264High 与 VAEntrypointEncSlice。Sunshine 也能在启动探测中识别 h264_vaapi。
但这台 VM 的桌面显示仍由虚拟 Bochs/Virtual-1 提供。启用 KMS 后 Sunshine 在查找 DRM monitor 时长时间阻塞，Moonlight 的 launch 请求超时；重启 Sunshine 时 Xorg/xrandr 又出现长时间卡住，Sunshine 需要强制终止。切换 X11 捕获尚未能形成稳定串流，试验因此判定失败。
已完成回退并重启宿主恢复 i915：VM102 当前为 vga=virtio-gl、无 hostpci0，Ubuntu Sunshine 恢复 capture=x11、encoder=software；VM100、VM101、VM102 均为运行状态，Windows 的 NVIDIA 直通和麒麟配置未修改。完整过程证据见 intel-vaapi-trial-final.json。
结论：当前这台宿主上，单纯把 Intel 核显直通给 Ubuntu 不能稳定打通“虚拟显示捕获 -> VAAPI 编码”链路，不能保留为生产优化。要继续把 Ubuntu 的交互回显压到 Windows 水平，需要给 Ubuntu 独占一块能同时提供显示/编码的 GPU，或改用支持零拷贝显示输出的虚拟 GPU 方案；继续调鼠标速度、虚拟显存和客户端队列不会消除这条编码瓶颈。