3.4 KiB
3.4 KiB
RHIRenderPass
命名空间: XCEngine::RHI
类型: class (abstract)
头文件: XCEngine/RHI/RHIRenderPass.h
描述: 抽象 render pass 对象，负责描述颜色附件和深度模板附件的 load/store 行为与 clear 值。
角色概述
RHIRenderPass 是当前 RHI 抽象层里对“本次渲染通道要操作哪些附件、以什么方式进入和离开”的统一表达。
它由两个部分组成：
AttachmentDescRHIRenderPass
其中 AttachmentDesc 是最关键的输入描述。
AttachmentDesc 表达什么
AttachmentDesc 当前包含：
formatloadOpstoreOpstencilLoadOpstencilStoreOpclearValue
这说明当前 render pass 抽象主要关注的是附件格式、load/store 语义和 clear 参数，而不是更复杂的 subpass、dependency 或 transient attachment 模型。
对当前引擎阶段来说，这是一种合理且务实的收敛方式：
- 足够支撑基本颜色/深度通道
- 能和 command list 的
BeginRenderPass()对接 - 不需要立刻把 Vulkan / D3D12 的全部 render pass 复杂度暴露出来
当前创建与使用路径
虽然 RHIRenderPass 自己暴露了 Initialize，但在真实使用里，上层更常见的入口是：
现有测试和 command list 用例基本都遵循这个路径：
- 构造一个或多个
AttachmentDesc - 通过
RHIDevice创建RHIRenderPass - 创建配套
RHIFramebuffer - 在 RHICommandList 上
BeginRenderPass()/EndRenderPass()
当前能力边界
按头文件和测试来看，当前 RHIRenderPass 能稳定表达的是：
- 纯颜色附件 pass
- 颜色 + 深度模板 pass
- 多个颜色附件
- 可选深度模板附件
但它没有直接表达：
- subpass
- attachment dependency
- transient attachment / input attachment
- 更复杂的 render graph 级资源声明
这说明它更像当前阶段的“基础渲染通道描述”，而不是最终的现代 render graph 节点模型。
测试体现出的现实语义
tests/RHI/unit/test_render_pass.cpp 给出了几个重要信号：
GetColorAttachmentCount()会反映创建时的颜色附件数量GetColorAttachments()可以拿回附件描述- 深度模板附件可以为
nullptr Shutdown()可以安全调用两次GetNativeHandle()当前测试接受nullptr
最后一点很重要：不要假设 RHIRenderPass 一定会提供可直接操作的 native handle。至少在当前抽象层里，这个返回值并不是用户级主路径依赖点。
生命周期
RHIRenderPass 通常由 RHIDevice 创建，并和 RHIFramebuffer 配套使用。使用完成后应显式：
- Shutdown
delete
公共方法
- Initialize
- Shutdown
- GetColorAttachmentCount
- GetColorAttachments
- GetDepthStencilAttachment
- GetNativeHandle