83 lines
4.1 KiB
Markdown
83 lines
4.1 KiB
Markdown
|
# RDP 与 Moonlight 实测对比（2026-10-28）
|
|||
|
|
|
|||
|
|
## 测试环境
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
终端：RK3528 PRO DDR4，Armbian 25.05，aarch64，LightDM + Xorg
|
|||
|
|
显示器：1920×1440 @ 75Hz
|
|||
|
|
云桌面：VM 100（win10-test），Proxmox VE 9.2.21，节点 starhe
|
|||
|
|
终端到云桌面：192.168.1.188 -> 192.168.1.70，同一局域网 WiFi
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
服务端显示环境改造（本次关键前提）：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
改造前：Microsoft Basic Display Adapter，1920×1080 @ 1Hz
|
|||
|
|
改造后：Virtual Display Driver 8.35.11.365，1920×1080 @ 60Hz
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
改造前 Sunshine 抓不到稳定帧（1Hz），改造后可正常编码。
|
|||
|
|
|
|||
|
|
## 对比数据
|
|||
|
|
|
|||
|
|
| 指标 | RDP（当前 kiosk-shell） | Moonlight 1080p30 | Moonlight 1080p60 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| 协议/编码 | RDP GFX，CPU 软解 | H.264 / libx264 软编 | H.264 / libx264 软编 |
|
|||
|
|
| 分辨率 | 1920×1440 | 1920×1080 | 1920×1080 |
|
|||
|
|
| 终端 CPU | 约 111%（单核近满载） | 约 26% | 约 26% |
|
|||
|
|
| 终端内存 | 约 232 MB | 约 192 MB | 约 165 MB |
|
|||
|
|
| 终端温度 | 约 58～65℃ | 约 56℃ | 约 53℃ |
|
|||
|
|
| 实际帧率 | 无可靠统计（观感为低帧+卷帘） | 12.83 FPS | 22.79 FPS |
|
|||
|
|
| 网络丢包 | 未测 | 0.00% | 0.00% |
|
|||
|
|
| 网络抖动丢帧 | 未测 | 0.08% | 15.28% |
|
|||
|
|
| 网络延迟 | 未测 | 2 ms | 6 ms |
|
|||
|
|
| 主机处理延迟 | 未测 | 14.4 / 27.6 / 平均 18.1 ms | 18.8 / 78.3 / 平均 38.2 ms |
|
|||
|
|
| 平均渲染耗时 | 未测 | 3.34 ms | 46.26 ms |
|
|||
|
|
| 画面观感 | 卷帘、翻页 | 完整清晰，无撕裂 | 完整清晰，无撕裂 |
|
|||
|
|
|
|||
|
|
## 结论
|
|||
|
|
|
|||
|
|
1. **卷帘问题不是 RDP 协议的限制，是当前 RDP 客户端实现路径的问题。**
|
|||
|
|
Moonlight 在同一台盒子、同一台云桌面、同一网络下画面完整清晰，无卷帘无撕裂，
|
|||
|
|
抓屏确认 1080p 画面文字锐利、任务栏时间正确。
|
|||
|
|
|
|||
|
|
2. **Moonlight 的瓶颈在服务端，不在终端，也不<E4B99F><E4B88D><EFBFBD>网络。**
|
|||
|
|
1080p30 时网络丢包 0.00%、延迟 2 ms、渲染 3.34 ms、终端 CPU 26%，
|
|||
|
|
但实际帧率仅 12.83 FPS；1080p60 时主机处理延迟升到平均 38.2 ms、渲染 46.26 ms。
|
|||
|
|
服务端当前使用 libx264 软件编码（VM 内无 NVIDIA 直通，`nvidia-smi` 不存在），
|
|||
|
|
4 核 CPU 同时承担 1080p 编码与桌面捕获，是帧率上限的真正原因。
|
|||
|
|
|
|||
|
|
3. **RDP 路径的 CPU 代价约为 Moonlight 的 4 倍**（111% vs 26%），
|
|||
|
|
因为 RDP 走 `FreeRDP GDI -> CPU 内存复制 -> QImage/QPixmap -> QLabel -> Xorg`，
|
|||
|
|
而 Moonlight 只做一次解码和一次窗口呈现。
|
|||
|
|
|
|||
|
|
4. **RK3528 VPU 硬解在当前 moonlight-qt 6.2.0 下不可用。**
|
|||
|
|
`h264_v4l2m2m` / `hevc_v4l2m2m` / `hevc_v4l2request` 均报
|
|||
|
|
`Could not find a valid device`，即使盒子存在 /dev/mpp_service、/dev/rga 和
|
|||
|
|
/dev/dri/renderD128。需 Rockchip MPP FFmpeg 补丁或 V4L2 request 驱动。
|
|||
|
|
|
|||
|
|
## 后续建议
|
|||
|
|
|
|||
|
|
优先级从高到低：
|
|||
|
|
|
|||
|
|
1. **服务端 GPU 直通**：将宿主机 GTX 965M（PCI 01:00.0，IOMMU Group 2 独占）
|
|||
|
|
直通给 VM 100，使 Sunshine 可用 NVENC 硬编码。预期把 1080p 帧率从 13 FPS
|
|||
|
|
提升到 60 FPS，同时释放服务端 CPU。需先确认内核 `intel_iommu=on`、
|
|||
|
|
`vfio-pci` 已绑定，以及该笔记本 GPU 的 vBIOS ROM 提取。
|
|||
|
|
2. **消除帧率随请求升高而抖动**（60 FPS 时抖动丢帧 15.28%）：服务端稳定后复测。
|
|||
|
|
3. **RK3528 硬解适配**：解决 V4L2 request/m2m 设备缺失，这是达成 4K 的前提。
|
|||
|
|
4. **协议选型建议**：
|
|||
|
|
- 若 GPU 直通可行，Moonlight 在 CAD/3D/视频场景优于 RDP，建议按产品方案采用双协议：
|
|||
|
|
普通办公用 RDP，GPU/CAD/3D 用 Moonlight；
|
|||
|
|
- 同时保留并优化 RDP 路径的 Weston + MPP/VPU + DMABUF/DRM 零拷贝改造，
|
|||
|
|
使 RDP 在办公场景达到可接受体验。
|
|||
|
|
5. 当前 Moonlight 未接 VPU，1080p 软件解码仅 26% CPU 但 4K 会超出能力，
|
|||
|
|
需在 4K 目标确定后优先解决硬解。
|
|||
|
|
|
|||
|
|
## 附：本次变更
|
|||
|
|
|
|||
|
|
- VM 100：安装 Virtual Display Driver（MttVDD），提供 1920×1080@60Hz 虚拟显示器。
|
|||
|
|
- VM 100：安装 Sunshine v2026.914.233613，Web UI 账号 admin / vdi12345。
|
|||
|
|
- 终端：安装 moonlight-qt 6.2.0，已与 Sunshine 完成配对。
|
|||
|
|
- 终端：kiosk-shell 自启动已恢复（~/.config/autostart/vdi-kiosk.desktop）。
|