112 lines
5.9 KiB
Markdown
112 lines
5.9 KiB
Markdown
# 频谱监测 WebGL2 原型性能结果
|
||
|
||
_第一轮可运行基线 · 2026-08-04_
|
||
|
||
---
|
||
|
||
## 📋 测试环境
|
||
|
||
本轮测试用于验证实现正确性、指标链路和不同负载之间的相对变化，不代表真实显卡最终性能。
|
||
|
||
| 项目 | 环境 |
|
||
| --- | --- |
|
||
| 操作系统 | macOS |
|
||
| 浏览器 | Playwright Chromium Headless |
|
||
| WebGL 后端 | ANGLE SwiftShader 软件渲染 |
|
||
| 桌面视口 | 1440 × 900 |
|
||
| 移动视口 | 390 × 844 |
|
||
| 数据源 | Dedicated Worker 模拟 Uint8 强度帧 |
|
||
| 渲染器 | 单 WebGL2 Context + R8 texture2DArray |
|
||
|
||
> ⚠️ **环境限制：** Playwright 默认无头 Chromium 未提供 WebGL2。测试通过 `--use-angle=swiftshader` 启用软件 WebGL2，因此 GPU 时间和 FPS 只能作为保守基线。真实硬件 GPU 需要在本地 Chrome、Edge 或 Safari 中重新记录。
|
||
|
||
## 🔬 模拟负载模型
|
||
|
||
模拟器定位为“接收端已经解码、校准后的频谱强度帧”，而不是原始 IQ 采样或浏览器内 FFT。这样能独立测量数据传递、纹理上传、曲线和瀑布渲染能力，不会把 DSP 计算混入前端展示指标。
|
||
|
||
### 已模拟内容
|
||
|
||
| 特征 | 实现 |
|
||
| --- | --- |
|
||
| 噪声统计 | 近似 FFT 单频点功率分布，不使用均匀随机抖动 |
|
||
| 接收通带 | 边缘衰减、固定纹波、频段校准偏差 |
|
||
| 时间特征 | 噪声逐帧变化、噪声底慢漂移、信号慢衰落 |
|
||
| 窄带信号 | 固定载波和近似高斯频谱裙边 |
|
||
| 宽带信号 | 平顶占用带宽、滚降边沿和带内功率纹理 |
|
||
| 动态信号 | 突发、跳频和线性扫频 |
|
||
| 可重复性 | 固定随机种子，时间由帧序号和刷新率确定 |
|
||
| 场景配置 | 安静频段、混合业务、密集信号、突发/跳频 |
|
||
|
||
信号数量按总频宽（GHz）和场景密度计算，信号占用带宽、跳频步进与扫频范围先以 MHz 定义，再映射到 FFT bin。因而把同一总频宽切成 1、32 或 64 个显示窗口不会改变物理信号集合；窗口数与每窗口 FFT 点数只改变总数据点数和渲染负载。
|
||
|
||
噪声底参数表示完成 RBW、窗函数、接收机噪声系数和校准后的“每 FFT bin dBm”，不是 `-174 dBm/Hz` 热噪声密度。正式接入时应直接采用设备上报值。
|
||
|
||
### 未模拟内容
|
||
|
||
- 原始 IQ 采样率、ADC 量化和 IQ 不平衡
|
||
- FFT 窗函数旁瓣的精确数学响应
|
||
- RBW/VBW、检波器模式和平均算法
|
||
- AGC、前端压缩、互调、镜像和杂散
|
||
- WebSocket/TCP 协议开销及服务端排队
|
||
|
||
因此，当前“强度流”指标是 `窗口数 × FFT 点数 × 更新频率 × 8 bit`，代表 Worker 输出到渲染器的数据量。若真实协议使用 `Int16` 或 `Float32`，网络带宽分别约为该值的 2 倍或 4 倍，但在 Worker 归一化为 `Uint8` 后，GPU 上传负载仍与当前测试一致。
|
||
|
||
## 📊 测试结果
|
||
|
||
| 场景 | FPS | 接收 | 吞吐 | CPU 上传 | CPU 提交 | GPU | 延迟 | 纹理 |
|
||
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
|
||
| 移动轻载：4 × 1024 × 30 Hz，96 行 | 60 | 29.5 Hz | 0.97 Mb/s | 0.00 ms | 0.10 ms | 1.80 ms | 2 ms | 0.4 MiB |
|
||
| 桌面基准：32 × 1024 × 30 Hz，96 行 | 25 | 31.0 Hz | 8.12 Mb/s | 0.10 ms | 0.10 ms | 13.77 ms | 17 ms | 3.0 MiB |
|
||
| 桌面高载：64 × 4096 × 20 Hz，128 行 | 5 | 20.3 Hz | 42.62 Mb/s | 0.30 ms | 0.30 ms | 59.82 ms | 19 ms | 32.3 MiB |
|
||
|
||
改进信号模型后补充复测：
|
||
|
||
| 场景 | FPS | 接收 | 强度流 | CPU 上传 | CPU 提交 | GPU | 延迟 | 纹理 |
|
||
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
|
||
| 混合业务：32 × 1024 × 30 Hz，96 行 | 24 | 31.0 Hz | 8.13 Mb/s | 0.00 ms | 0.20 ms | 7.78 ms | 11 ms | 3.0 MiB |
|
||
| 密集信号：64 × 4096 × 20 Hz，128 行 | 10 | 19.4 Hz | 40.59 Mb/s | 0.20 ms | 0.20 ms | 39.53 ms | 49 ms | 32.3 MiB |
|
||
|
||
丢弃帧统计为应用负载以来的累计值，包含页面启动和配置切换阶段，不能直接比较不同测试时长。它的主要用途是判断最新帧策略是否正在主动控制延迟。
|
||
|
||
## 💡 结果分析
|
||
|
||
### 数据通路达到目标频率
|
||
|
||
三个场景的数据接收率均接近配置值。64 路场景约 42.6 Mb/s，与 `64 × 4096 × 20 × 8 bit` 的理论强度数据量一致，说明 Worker、可转移 ArrayBuffer 和主线程接收链路可以承载该测试规模。
|
||
|
||
### GPU 填充成为高负载瓶颈
|
||
|
||
CPU 上传和绘制命令提交均低于 0.5 ms，但软件 GPU 时间从轻载的 1.8 ms 增长到高载的约 59.8 ms。瓶颈主要来自 64 个窗口、2936 像素画布高度和瀑布区域填充，而不是 JavaScript 绘制循环。
|
||
|
||
### 最新帧策略保持低延迟
|
||
|
||
高载时 FPS 低于数据频率，原型会覆盖待处理旧帧而不是形成队列。端到端延迟仍保持约 19 ms，证明主动丢弃中间帧可以避免延迟持续增长。
|
||
|
||
### 响应式布局通过基础验证
|
||
|
||
390 像素移动视口下页面水平溢出为 0，控制项自动换行，四个窗口使用单列布局。桌面 32 路使用四列布局，曲线、阈值、瀑布、标签和框选区域未出现重叠。
|
||
|
||
## ✅ 已验证功能
|
||
|
||
- Worker 按窗口数、FFT 点数和刷新率生成数据
|
||
- ArrayBuffer 回收池与最新帧覆盖策略
|
||
- 运行时重建 R8 `texture2DArray`
|
||
- 单 Canvas 绘制 1 至 64 个频率窗口
|
||
- 当前曲线、GPU 环形瀑布和阈值超限着色
|
||
- 矩形框选与频率/dBm 结果换算
|
||
- FPS、接收率、吞吐、CPU、GPU、延迟、内存和丢帧指标
|
||
- 配置切换版本隔离，旧尺寸帧不会进入新纹理
|
||
- WebGL2 不可用时显示明确错误状态
|
||
|
||
## 🔍 下一轮建议
|
||
|
||
1. 在目标部署设备的硬件 Chrome/Edge 上记录同一测试矩阵
|
||
2. 增加固定画布高度模式，区分“同时绘制所有窗口”和“只绘制可见窗口”
|
||
3. 为 4096/8192 点曲线增加屏幕空间 `min/max` LOD 对照测试
|
||
4. 连续运行 30 分钟记录 JS Heap、GPU 纹理和丢帧变化
|
||
5. 若硬件 GPU 在 32 路基准下仍无法稳定 60 FPS，再评估按脏帧绘制、降低 DPR 或可见区域裁剪
|
||
|
||
---
|
||
|
||
_最后更新：2026-08-04_
|