RHICapabilities

命名空间: XCEngine::RHI

类型: struct

头文件: XCEngine/RHI/RHICapabilities.h

描述: 描述当前设备支持的功能开关、资源上限、光栅限制和版本信息，是 renderer 初始化阶段的主要特性查询入口。

角色概述

RHICapabilities 是 RHIDevice 暴露给上层的能力快照。它的定位很明确：

在 renderer 启动时决定某条渲染路径是否可用
给资源系统提供尺寸和数量上限
为调试与日志输出提供设备能力摘要

这类结构在商业引擎里很常见，因为高层 renderer 往往需要先读一遍“当前设备能不能做某件事”，再决定启用哪些 feature set。

字段分组

功能开关

bSupportsRayTracing
bSupportsMeshShaders
bSupportsExplicitMultiThreading
bSupportsGeometryShaders
bSupportsTessellation
bSupportsComputeShaders
bSupportsDepthBoundsTest
bSupportsAlphaToCoverage
bSupportsIndependentBlend
bSupportsLogicOps
bSupportsMultiViewport
bSupportsConservativeRasterization
bSupportsProgrammableSamplePositions

资源与渲染上限

maxTexture2DSize
maxTexture3DSize
maxTextureCubeSize
maxRenderTargets
maxViewports
maxVertexAttribs
maxConstantBufferSize
maxAnisotropy
maxColorAttachments

线宽、点大小相关限制

minSmoothedLineWidth
maxSmoothedLineWidth
minPointSize
maxPointSize
maxPointSizeAA
maxLineWidth
maxLineWidthAA

版本与 shader 模型

majorVersion
minorVersion
shaderModel

当前实现语义

这是一个纯 public struct，带默认值，没有 getter / setter，也没有更复杂的 feature query 层级。也就是说：

默认构造时，布尔项基本都是 false
数值项基本是 0 或 1.0f
真正的能力数据由具体后端设备在初始化时填充

这种设计非常直接，适合当前阶段的引擎实现，但也意味着它不是那种高度抽象、可按扩展名逐项查询的 capability database。

测试揭示出的保证边界

tests/RHI/unit/test_capabilities.cpp 很适合拿来理解“这份结构当前到底保证到什么程度”。

现有测试主要验证的是：

常见纹理尺寸、render target 数量、viewport 数量等至少大于某些下限
majorVersion / minorVersion 非负
D3D12 下 shaderModel 非空
各项 line width / point size 数据不小于基础值
maxConstantBufferSize 在一个合理范围内

这说明当前 RHICapabilities 更像“运行时可用的设备特征摘要”，而不是一份经过严格标准化校验的完整硬件契约。

怎么正确使用

推荐把它用于：

启动时 feature gating
选择 render path
做日志输出和诊断
对资源尺寸做防御性检查

不建议把它当成：

跨平台精确一致的能力数据库
替代后端专用 feature query 的唯一信息源
细粒度扩展发现系统

和商用引擎能力系统的关系

很多成熟引擎会把能力系统做得更分层，例如把 adapter info、feature support、format support、optional extensions 分开表示。当前 RHICapabilities 还没有走到那一步，它更像一个实用的第一层设备能力快照。

这对当前阶段反而是合理的：

renderer 能快速消费
文档和测试更容易保持一致
后续如果要拆分也有基础数据模型可演进

3.7 KiB Raw Blame History Unescape Escape