Inbox/设计补丁/ECN_关于UI渲染与CUDA计算之间的资源竞争.md

tags, aliases, date created, date modified

tags	aliases	date created	date modified
	架构设计变更通知 (ECN)	星期五, 十一月 21日 2025, 3:35:31 下午	星期五, 十一月 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)

代码段

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 拖拽卡顿”的压力测试用例，改为关注“长时间满载运行下的散热稳定性”。

---

结论:

通过此补丁，我们移除了系统中最大的一个不确定性来源（异步抢占），使得信号处理流水线变得更加确定性和纯粹。这是对“奥卡姆剃刀原则”的一次成功实践——如无必要，勿增实体。