创建仓库
This commit is contained in:
115
设计补丁/ECN_关于UI渲染与CUDA计算之间的资源竞争.md
Normal file
115
设计补丁/ECN_关于UI渲染与CUDA计算之间的资源竞争.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 架构设计变更通知 (ECN)
|
||||
date created: 星期五, 十一月 21日 2025, 3:35:31 下午
|
||||
date modified: 星期五, 十一月 21日 2025, 3:36:41 下午
|
||||
---
|
||||
|
||||
# 架构设计变更通知 (ECN)
|
||||
|
||||
- 编号: ECN-2025-001
|
||||
- 主题: 显控架构扁平化调整与 GPU 资源仲裁策略简化
|
||||
- 适用范围: 2.3.5 章节及相关模块接口
|
||||
- 日期: 2025-11-21
|
||||
|
||||
## 1. 变更背景与动因 (Motivation)
|
||||
|
||||
- **原设计假设**: 显控终端采用 3D 实时渲染（如 OpenGL/Vulkan 绘制雷达波束体或复杂地形），会大量占用 GPU 渲染管线和显存带宽，需通过抢占式调度防止 TDR。
|
||||
- **修正后基线**: 显控终端确认为 **扁平化 2D 平面显示**（如 Qt/GDI 绘制 B-Scan/PPI 图像）。此类渲染对 GPU 资源消耗极低（< 1%），且主要由操作系统的桌面窗口管理器（DWM/X11）处理，**不与 CUDA 计算核心产生实质性竞争**。
|
||||
- **变更目标**: 移除为 UI 响应性服务的复杂抢占调度逻辑，释放被“任务切分”和“优先级切换”占用的系统开销，回归**计算吞吐量优先**的设计策略。
|
||||
|
||||
## 2. 核心变更点 (Core Changes)
|
||||
|
||||
|**变更项**|**原设计 (Deprecated)**|**新设计 (New Baseline)**|**收益**|
|
||||
|---|---|---|---|
|
||||
|**仲裁触发源**|显控终端发送 `RequestHighPriorityGpuAccess`。|**移除显控触发源**。保留“温度/功耗过载”作为唯一降级触发源。|消除 UI 交互对后台计算的非必要打断。|
|
||||
|**任务调度**|细粒度切分 (`ISegmentableTask`)，支持 <10ms 响应。|**粗粒度批处理**。移除强制切分要求，Kernel 允许长时运行。|减少 Kernel 启动开销，提升 GPU 流水线饱和度。|
|
||||
|**CUDA 流策略**|双优先级流（High/Low）动态切换。|**单一计算流池**。默认全速运行，仅在热保护时通过 `usleep` 或空闲插入进行节流。|简化流管理逻辑，降低上下文切换风险。|
|
||||
|
||||
---
|
||||
|
||||
## 3. 修订后的 2.3.5 章节规范
|
||||
|
||||
该章节标题由“资源仲裁与抢占式优先级控制”变更为 **“2.3.5 系统负载保护与热节流控制”**。
|
||||
|
||||
- 2.3.5 系统负载保护与热节流控制 (System Load Protection & Thermal Throttling)
|
||||
- **核心指向**：鉴于显控架构的扁平化，控制平面的资源管理重心从“UI 响应性保障”转移至 **“系统物理安全保障”**。接口仅用于在极端工况（如机箱温度过高、GPU 功耗触顶）下，强制降低计算负载以保护硬件。
|
||||
|
||||
## 3.1 交互协议变更
|
||||
|
||||
- **废弃事件**:
|
||||
- `RequestHighPriorityGpuAccessEvent` (已移除)
|
||||
- `HighPriorityGpuAccessFinishedEvent` (已移除)
|
||||
- **保留并重定义事件**:
|
||||
- `SystemOverloadEvent { Type: THERMAL | POWER, Level: WARNING | CRITICAL }`: 由 `MonitoringModule` 发布。
|
||||
- `SetComputeThrottleEvent { ThrottleLevel level }`: 由 `ResourceCoordinator` 决策后发布。
|
||||
- `Level 0`: 全速 (No Throttle)
|
||||
- `Level 1`: 降速 20% (Insert Idle)
|
||||
- `Level 2`: 降速 50% (Half Capacity)
|
||||
- `Level 3`: 暂停 (Suspend)
|
||||
|
||||
## 3.2 响应机制简化
|
||||
|
||||
- **调度器侧 (`ResourceCoordinator`)**:
|
||||
- 逻辑简化为**迟滞比较器 (Hysteresis Comparator)**。仅当温度传感器上报值持续超过阈值（如 85°C）时，下发节流指令；温度回落至安全线（如 75°C）以下时，解除节流。
|
||||
- 不再处理毫秒级的 UI 交互请求。
|
||||
- **模块侧 (`SignalProcessor`)**:
|
||||
- **移除** `PreemptiveStreamManager` 和双流切换逻辑。
|
||||
- **新增** `ThrottleController`：在 `ExecutionEngine` 的主循环（每帧处理结束处）插入动态休眠逻辑。
|
||||
- _实现逻辑_: `if (throttle_level > 0) std::this_thread::sleep_for(calc_delay(level));`
|
||||
- **收益**: 算法 Kernel 再次回归到“大块连续执行”的最佳性能模式，无需为了响应中断而被人为切碎。
|
||||
|
||||
## 3.3 修正后的时序图 (`sequenceDiagram`)
|
||||
|
||||
代码段
|
||||
|
||||
```bash
|
||||
sequenceDiagram
|
||||
participant Monitor as 监控模块
|
||||
participant EventBus as 事件总线
|
||||
participant Scheduler as 任务调度器
|
||||
participant SignalProc as 信号处理模块
|
||||
|
||||
Note over Monitor,SignalProc: 热保护节流流程 (不再涉及UI)
|
||||
|
||||
Monitor->>Monitor: 检测到 GPU 温度 > 90°C
|
||||
Monitor->>+EventBus: 1. 发布 SystemOverloadEvent(THERMAL, CRITICAL)
|
||||
|
||||
EventBus->>+Scheduler: 2. 路由告警
|
||||
|
||||
Scheduler->>Scheduler: 3. 决策: 必须降频保护
|
||||
Scheduler->>+EventBus: 4. 广播 SetComputeThrottleEvent(Level=2)
|
||||
|
||||
EventBus->>+SignalProc: 5. 路由指令
|
||||
SignalProc->>SignalProc: 6. 更新内部节流状态
|
||||
|
||||
loop 每一帧处理循环
|
||||
SignalProc->>SignalProc: 执行完整计算 (不切分)
|
||||
SignalProc->>SignalProc: <b>主动休眠 10ms</b> (响应节流)
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 对关联文档的连带影响 (Impact Analysis)
|
||||
|
||||
1. **对 `02_信号处理模块设计.md` 的影响**:
|
||||
|
||||
- **删除** 4.3 节“抢占式 GPU 资源协调”。
|
||||
- **删除** 4.3.3 节 `ISegmentableTask` 接口定义。算法策略不再需要实现 `segmentTask()` 方法，简化了 FFT/CFAR 等算法的封装难度。
|
||||
- **简化** `GpuResourceManager`，移除多优先级流池。
|
||||
|
||||
2. **对 `05_任务调度器设计.md` 的影响**:
|
||||
|
||||
- `ResourceCoordinator` 的职责缩减为仅负责系统健康相关的宏观调控，不再介入微观的任务调度。
|
||||
|
||||
3. **对 `99_模块集成策略.md` 的影响**:
|
||||
|
||||
- 在集成测试阶段，移除针对“UI 拖拽卡顿”的压力测试用例，改为关注“长时间满载运行下的散热稳定性”。
|
||||
|
||||
---
|
||||
|
||||
结论:
|
||||
|
||||
通过此补丁，我们移除了系统中最大的一个不确定性来源（异步抢占），使得信号处理流水线变得更加确定性和纯粹。这是对“奥卡姆剃刀原则”的一次成功实践——如无必要，勿增实体。
|
||||
Reference in New Issue
Block a user