Files
XCEngine/docs/api/XCEngine/RHI/RHIPipelineState/RHIPipelineState.md

4.9 KiB
Raw Blame History

RHIPipelineState

命名空间: XCEngine::RHI

类型: class (abstract)

头文件: XCEngine/RHI/RHIPipelineState.h

描述: 抽象图形/计算管线状态对象负责聚合输入布局、光栅化、混合、深度模板、render target 格式以及可选计算 shader。

角色概述

RHIPipelineState 对应的是当前抽象层里的“可绑定管线状态包”。它的接口明显带有“统一图形状态描述”的设计意图,而不是简单把某个后端的 native PSO 结构原样暴露出去。

头文件注释里直接写了:

  • Unity SRP style
  • Shader independent of PSO

这说明当前设计方向是希望用一套更统一的 pipeline 状态模型去支撑不同后端,而不是要求所有状态都只通过 shader 或 native API 自己的配置路径表达。

当前状态模型

RHIPipelineState 当前主要包含两类信息:

图形状态

计算路径

也就是说,当前同一个抽象接口既能表达 graphics pipeline也能表达 compute pipeline。

类型与有效性

这是这页最值得说明的地方。

GetType()

从现有测试看:

  • 默认创建出来的 pipeline state 类型是 PipelineType::Graphics
  • 当设置了 compute shader 后,类型可以变成 PipelineType::Compute

IsValid() / EnsureValid()

现有测试明确揭示了一个很重要的后端差异:

  • 在 D3D12 下,默认或信息不足的 pipeline state 往往不是立即有效的。
  • 在 OpenGL 路径下,默认 pipeline state 更容易被视为有效。

头文件注释甚至直接写出了当前统一语义:

  • D3D12 需要编译
  • OpenGL 总是有效

这意味着 RHIPipelineState 的“有效”不是完全抽象无差异的概念而是和后端实现成熟度、native API 要求直接相关。

设计理解

从商用引擎经验看,这样的 pipeline state 抽象是合理的:

  • renderer 可以先在统一描述层拼好状态,再交给后端去编译或绑定
  • 输入布局、混合、深度模板和 render target 格式等关键状态有明确归属
  • 计算路径可以与图形路径复用一部分生命周期和绑定逻辑

但当前实现也有现实边界:

  • 还保留了 RHICommandList::SetShader() 这种并行路径,所以整个系统并不是“只有 PSO”这一种绑定范式
  • GraphicsPipelineDescRHIPipelineState 的关系更偏工程实现上的状态收敛,而不是已经完全封装成单一材质系统
  • 有效性判定明显依赖后端

测试体现出的真实使用方式

tests/RHI/unit/test_pipeline_state.cpptest_compute.cpp 给出了当前比较可信的使用路径:

  • 可以先创建默认 GraphicsPipelineDesc 再逐步设置状态
  • 可以读回 RasterizerDescBlendDescDepthStencilStateDescInputLayoutDesc
  • 可以为 graphics pipeline 直接在 GraphicsPipelineDesc 里提供 vertex / fragment shader
  • 可以用 SetComputeShader() 走 compute 路径
  • 在部分后端下 EnsureValid() 会触发或推进有效性检查,但并不保证无条件成功

这说明当前 pipeline state 的职责更像“后端可消费的统一状态对象”,而不是文档层面随便说说的概念壳子。

生命周期

当前接口提供:

通常它由 RHIDevice 创建,并以裸指针形式返回。使用完成后应显式 Shutdown()delete

公共方法

相关文档