功能:支持真实 2K 串流与重启持久化并优化渲染

变更详情:真2K串流与重启持久化,优化客户端渲染和帧率配置

三端统一2560x1440,盒子使用297MHz HDMI时序并保留1080p回退;Windows脚本动态定位VDD恢复2K。串流默认2K20/30Mbps,使用GLES2,设置页支持20/24FPS及自定义值。保持Windows正常光标,记录NVENC阶段性实测和GPU重启后Code43未恢复的限制。
This commit is contained in:
songyiming committed 2026-11-02 16:40:22 +08:00
1 parent 4f9565a768
commit e47b01beec
11 files changed
+198 -36

No files matched your search

+34 -8
View File
@@ -290,7 +290,7 @@ Desktop Duplication 的脏帧节奏,叠加 QEMU 显示栈),不是编码器
`GET /api/csrf-token`(Basic Auth)→
`POST /api/pin` body `{"pairing_id":"<GET /api/pin 里拿>","pin":"4321"}`,
头带 `X-CSRF-Token` + Basic Auth(无 /api/login;POST 必须 CSRF 头)。
- Web 凭据已重置为 `vdiadmin / VdiPass2026`(写在本页,勿提交正式环境)。
- Sunshine Web 管理凭据由环境管理员保管,不在仓库记录明文密码。
- **旧版缓存 uniqueid 会让 pair 卡 "Found unexpected PC" 死循环**:
盒子 `~/.config/Moonlight Game Streaming Project/` 整目录删除后重配即可。
- Sunshine 重启不再换 uniqueid(持久化已恢复);**若再出现"每次重启换 uniqueid",
@@ -298,14 +298,40 @@ Desktop Duplication 的脏帧节奏,叠加 QEMU 显示栈),不是编码器
- NVIDIA 设备半坏时 Sunshine 捕获初始化会崩循环(服务恢复 5-6 分钟拉起一次),
表象是"每几分钟换一次 UUID + 配对全部失败"。根因仍是驱动 D3D 问题。
## 当前现场(2026-10-30 14:50)
## 2026-11-02:GPU/NVENC与客户端渲染阶段性实测(最终状态见下节)
- GTX 965M 直通、582.78 驱动、DXGI/D3D 和 NVENC 已打通;Sunshine 实际使用
`h264_nvenc`,连续 60Hz 动画下服务端发送约 59 FPS、网络丢帧 0%、服务端处理约 4.5ms。
- Virtual Display Driver 已从 8.35.11.365 升级到官方签名的 11.30.4.434;
保持 1920x1080@60,并绑定 `NVIDIA GeForce GTX 965M`。
- 鼠标最终采用 Windows 远程光标方案:白色 Windows 光标在 NVENC/30FPS 稳定链路下已不卡顿;
已删除 kiosk 自动开启盒子本地黑色光标的逻辑,并移除 Windows 透明光标登录任务、恢复系统光标,
避免黑色光标带动白色光标的双光标现象。
- 客户端瓶颈实测定位在 RK3528 的 Xorg/MATE 合成和 SDL OpenGL 呈现:关闭 MATE
compositor 后,1080p60 连续动画渲染从 16.3 FPS 提到 28.8 FPS;强制
`SDL_RENDER_DRIVER=opengles2` 后提高到 37.4 FPS。
- 900p60 约 43.4 FPS、720p60 约 45.4 FPS,画质损失大但仍不到60;最终产品默认采用
**1920x1080@30**:实测输入30.04、解码30.04、渲染29.90 FPS,网络丢帧0%、
抖动丢帧0.46%、客户端渲染4.69ms,体感比“名义60实际持续丢帧”稳定。
- 新增 `vdi-kiosk-start`,开机固定盒子输出1920x1080@60后启动受管 kiosk;
`vdi-kiosk.desktop` 已改走该入口。保留 VSync/Frame Pacing(关闭无收益)。
## 当前现场(2026-11-02 15:45,优先于上面的历史实验结论)
- 真实2K三段已验证:Windows MttVDD 2560x1440@30、Moonlight 2560x1440@20(30000 Kbps)、盒子 HDMI 2560x1440@60。1920x1440不是本项目验收所说的2K。
- 显示器 EDID 首选时序为2560x1440、241.70MHz;当前RK3528 vendor内核拒绝此时钟。改用已支持的297MHz和加长垂直消隐后成功:
`297.00 2560 2608 2640 2720 1440 1443 1448 1820 +HSync -VSync`,实际约59.994Hz,link-status Good。
此模式不是显示器原厂时序,已在现场显示器测试;其他显示器必须重新验证,启动器失败回退1080p,不能把回退结果报成2K。
- `vdi-kiosk-start` 开机建立上述模式并启动单一kiosk链;盒子真实重启后仍为2560x1440,单链自启验收通过。保留GLES2和关闭MATE合成器。
- VDD配置路径经25.7.23源码核查为 `C:\VirtualDisplayDriver\vdd_settings.xml`,包含1080p60和1440p30/60;旧安装目录的XML不应再作为生效证据。
- Windows计划任务 `VDISet2KDisplay` 以已登录test用户的交互令牌运行,执行 `C:\ProgramData\VDI\set-2k-display.ps1`。脚本动态查找活动的Virtual Display Driver,不能写死DISPLAY编号,也不能在Guest Agent的Session 0里切换交互桌面。
对应源码归档为 `tools/set-2k-display.ps1`;重启VM后日志 `set-2k-result.txt` 返回result=0、mode=2560x1440@30。Windows 125% DPI下逻辑坐标2048x1152不代表物理像素不足2K。
- NVIDIA正常期间的连续动画测试:2K30输入29.92/渲染21.52 FPS、抖动丢帧27.75%;2K24渲染22.15、丢帧8.14%;2K20输入20.31/渲染19.67、网络丢帧0%、抖动丢帧0.94%。所以现场选择2K20,未达到2K30/60满帧。
- **重启验收发现GPU回归故障,当前NVENC未恢复**:驱动582.78、ROM `gtx965m-pci.rom`、Proxmox hostpci0配置仍保留;VM重启后Code43。设备重启可暂时令PnP显示OK,但NVML仍报Not Found,Sunshine实际使用 `libx264 [software]`。
客户机内重复重启设备、暂时停用VDD/Sunshine、VM完整关机再启动均未恢复;之前NVENC成功及2K20性能数据不能作为当前性能保证。
- 已删除无效的 `VDIRecoverNvidia` 自动恢复任务和脚本。宿主GPU只有bus reset,`vfio_pci.disable_idle_d3=Y`,VM关机后仍D0;这些证据不足以断言唯一根因,未修改运维的VFIO模块/ROM配置,也未重启宿主机或影响VM101/102。
- 当前盒子可正常进入2K20 Windows桌面,白色Windows光标保留、本地黑色光标自动切换已删除;GPU恢复需要与运维协同,验收必须检查nvidia-smi、DXGI和Sunshine实际编码器,不能只看设备管理器。
- VM 100:**GPU 未挂载**(另一并行会话用 `hv_vendor_id=NVidiaFIX` 方案接手了配置,
为避免两个会话互相覆盖,本会话已停止改 VM 配置);VM 内 566.36 驱动已装好待用。
- 盒子:kiosk 单链已恢复、配对已修复、串流实测 ~23 FPS(软编基线)可正常进出。
- 宿主机 /root 下留有 nv582.78.exe、DisplayDriver.zip、DD566.zip、gtx965m.rom;
8018 端口有临时 HTTP 服务(http8018svc)供 VM 拉文件,用完可
`systemctl stop http8018svc`。
---