3.0 KiB
3.0 KiB
OpenGLRenderPass
命名空间: XCEngine::RHI
类型: class
头文件: XCEngine/RHI/OpenGL/OpenGLRenderPass.h
描述: OpenGL 后端的 render pass 元数据对象，用来保存附件描述并驱动命令列表的清除行为。
概览
OpenGLRenderPass 的名字很容易让人联想到 Vulkan 或现代显式图形 API 中的“原生 render pass 对象”，但当前实现并不是这样。
在 XCEngine 的 OpenGL 后端里，这个类型更接近一份 CPU 侧描述数据:
- 记录颜色附件数量和对应的
AttachmentDesc - 可选地记录一个深度/模板附件描述
- 在命令列表开始渲染阶段时，为 clear/load 逻辑提供依据
它本身不创建 OpenGL driver object，也不负责保存 framebuffer。
为什么这样设计
这种做法是跨后端 RHI 很常见的折中方案:
- 在 Vulkan / D3D12 侧，render pass 往往有更强的显式契约意义。
- 在 OpenGL 侧，很多行为最终还是通过“绑定 framebuffer 然后执行 clear / draw”来完成。
- 因此引擎保留统一的
RHIRenderPass抽象，但允许 OpenGL 后端把它退化为元数据容器。
这样做的好处是:
- 上层渲染代码仍然能保持一致的
BeginRenderPass()调用序列。 - 文档和接口可以保留“附件装载/清除策略”的设计概念。
代价是:
OpenGLRenderPass不能像 D3D12/Vulkan 那样被理解为强语义的后端对象。GetNativeHandle()没有可返回的原生句柄。
生命周期
- 构造后对象为空，只保存默认状态。
- 调用 Initialize 后复制附件描述。
- 调用 Shutdown 或析构后，内部数组和标志被清空。
线程语义
- 当前实现没有任何锁。
- 应把它视为渲染设备初始化线程或渲染线程中的普通 RHI 对象，不应在多线程下并发初始化和销毁。
当前实现的真实行为
- 只保存
AttachmentDesc副本，不创建原生对象。 - GetNativeHandle 始终返回
nullptr。 - OpenGLCommandList::BeginRenderPass 会读取这些附件描述:
- 对颜色附件执行
glClearBufferfv(GL_COLOR, ...) - 对深度附件执行
glClearBufferfv(GL_DEPTH, ...) - 对模板附件执行
glClearBufferfv(GL_STENCIL, ...)
- 对颜色附件执行
tests/RHI/unit/test_render_pass.cpp验证了附件计数、深度附件访问、Shutdown()复位和空 native handle 等行为。
当前限制
- 不保存 store-op 的完整后端语义；当前实现重点在 clear/load。
- 不对应独立的 OpenGL 原生对象，因此无法像 Vulkan render pass 那样参与更细粒度的兼容性分析。