Vulkan Specialization Constants 详解：在“运行时配置”和“编译期优化”之间取得平衡

一、引言：为什么 Vulkan 需要 Specialization Constants

在 Vulkan 中，Shader 通常会先被编译成 SPIR-V，然后在创建 Pipeline 时交给驱动进一步编译、优化并生成 GPU 可执行代码。对于开发者来说，一个常见问题是：

如果某些参数在程序运行时才知道，但一旦确定后又希望它像编译期常量一样被优化，该怎么办？

例如：

Fragment Shader 中最多支持多少盏灯？
是否开启 PCF 阴影过滤？
是否开启法线贴图？
Compute Shader 的 workgroup size 是多少？
某个后处理 pass 使用 9-tap blur 还是 13-tap blur？
某个材质分支是否可以完全裁剪掉？

如果使用 Uniform Buffer 或 Push Constants，这些值虽然可以运行时修改，但对驱动编译器来说，它们通常不是编译期常量。编译器很难基于这些值进行彻底的静态优化。

如果使用 #define 宏，则需要为每种组合单独生成不同的 Shader 代码，管理成本较高。

Specialization Constants 正是为了解决这个问题而设计的。它允许我们在 Shader 中声明"可特化常量"，并在 Pipeline 创建阶段由 CPU 侧传入具体值。这样，Shader 源码可以保持统一，但驱动在创建 Pipeline 时已经知道这些值，因此可以把它们当作常量参与优化。

一句话概括：

Specialization Constants 是一种"在 Shader 编译后、Pipeline 创建前注入具体值的常量机制"。

它不是普通运行时变量，而是 Pipeline 变体生成机制的一部分。

二、Specialization Constants 的核心思想

Specialization Constants 的位置介于两类机制之间：

机制	赋值时间	是否可频繁变化	编译器能否强优化	典型用途
`#define` 宏	Shader 编译前	不方便	可以	离线编译多个 Shader 版本
Specialization Constants	Pipeline 创建时	不能逐 draw 修改	可以	创建 Pipeline 变体
Push Constants	命令录制时	可以频繁变化	通常不能按常量优化	小量高频参数
UBO / SSBO	Draw / Dispatch 前	可以频繁变化	通常不能按常量优化	大量运行时数据

从工程角度看，Specialization Constants 适合描述"中低频变化，但对 Shader 结构影响很大"的参数。

例如：

复制代码

layout(constant_id = 0) const int LIGHT_COUNT = 4;
layout(constant_id = 1) const bool ENABLE_SHADOW = true;

这里 LIGHT_COUNT 和 ENABLE_SHADOW 在 GLSL 里看起来像普通 const，但它们的最终值不是写死在 Shader 源码中的，而是可以在创建 Pipeline 时由应用程序指定。

如果 ENABLE_SHADOW = false，驱动有机会直接删除阴影采样相关代码。

如果 LIGHT_COUNT = 4，驱动有机会展开循环，减少动态分支和循环控制开销。

这就是 Specialization Constants 的主要价值：它把某些"运行时才确定"的配置提升成"Pipeline 编译期可见"的常量。

三、它和 Uniform Buffer、Push Constants 的根本区别

很多初学者会把 Specialization Constants、Uniform Buffer、Push Constants 混在一起。它们都可以把 CPU 侧数据传给 Shader，但语义完全不同。

1. Uniform Buffer：运行期数据

Uniform Buffer 适合传递模型矩阵、视图矩阵、投影矩阵、材质参数、光源数组等运行期数据。

例如：

复制代码

layout(set = 0, binding = 0) uniform UBO {
    mat4 view;
    mat4 proj;
    vec4 lightPos;
} ubo;

这些数据在 Shader 执行时从显存中读取。它们可以每帧更新、每个对象更新、每个 draw 更新。

但问题是：编译器通常不能假设 ubo.lightCount 是固定值。即使你每次都传 4，编译器也不能据此安全地删除其他分支。

2. Push Constants：小而快的运行期数据

Push Constants 适合传递少量高频变化的数据，例如 object ID、材质索引、某个开关、矩阵索引等。

复制代码

layout(push_constant) uniform Push {
    int materialIndex;
    float roughnessScale;
} pc;

它比 UBO 更轻量，不需要 Descriptor Set，但仍然属于运行期参数。它适合"频繁变化"，不适合"生成大量静态优化版本"。

3. Specialization Constants：Pipeline 创建期常量

Specialization Constants 的值在 Pipeline 创建时指定。Pipeline 创建完成后，这个 Pipeline 内部的 Specialization Constant 值就固定了。

这意味着：

不能在 vkCmdDraw 之前临时修改；
不能像 Push Constants 一样频繁变化；
不同 Specialization Constant 组合通常对应不同 Pipeline；
优点是驱动编译器能基于这些值优化 Shader。

所以它不是为了替代 UBO 或 Push Constants，而是为了管理 Pipeline 级别的 Shader 变体。

四、Shader 侧如何声明 Specialization Constants

1. GLSL 写法

在 Vulkan GLSL 中，可以使用 layout(constant_id = N) 声明 specialization constant。

复制代码

#version 450

layout(constant_id = 0) const int LIGHT_COUNT = 4;
layout(constant_id = 1) const bool ENABLE_NORMAL_MAP = true;
layout(constant_id = 2) const float EXPOSURE = 1.0;

layout(location = 0) in vec3 inNormal;
layout(location = 1) in vec2 inUV;

layout(location = 0) out vec4 outColor;

void main()
{
    vec3 color = vec3(0.0);

    for (int i = 0; i < LIGHT_COUNT; ++i)
    {
        color += vec3(0.1);
    }

    if (ENABLE_NORMAL_MAP)
    {
        color *= 1.2;
    }

    outColor = vec4(color * EXPOSURE, 1.0);
}

这里有三个 specialization constants：

复制代码

constant_id = 0 -> LIGHT_COUNT
constant_id = 1 -> ENABLE_NORMAL_MAP
constant_id = 2 -> EXPOSURE

Shader 中提供的 4、true、1.0 是默认值。如果 CPU 侧没有提供对应的 specialization 数据，就会使用默认值。

2. 用于 Compute Shader 的 local size

Specialization Constants 在 Compute Shader 中特别常见，因为 workgroup size 经常需要根据设备、算法或数据规模调整。

普通写法：

复制代码

layout(local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

使用 specialization constants：

复制代码

#version 450

layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;

layout(set = 0, binding = 0) buffer Data {
    float values[];
} dataBuffer;

void main()
{
    uint index = gl_GlobalInvocationID.x;
    dataBuffer.values[index] *= 2.0;
}

CPU 侧可以在创建 Compute Pipeline 时指定：

复制代码

constant_id = 0 -> local_size_x
constant_id = 1 -> local_size_y

这样同一个 SPIR-V 模块可以创建出多个 Compute Pipeline：

复制代码

Pipeline A: 8  x 8  workgroup
Pipeline B: 16 x 16 workgroup
Pipeline C: 32 x 8  workgroup

这对于 GPU compute、图像处理、粒子模拟、tile-based pass 非常实用。

五、CPU 侧如何传入 Specialization Constants

Vulkan 中主要使用两个结构体：

复制代码

VkSpecializationMapEntry
VkSpecializationInfo

其核心思想是：

VkSpecializationMapEntry 描述某个 constant_id 在数据块中的偏移和大小；
VkSpecializationInfo 持有整个数据块和所有映射表；
VkPipelineShaderStageCreateInfo::pSpecializationInfo 指向它。

1. Shader 示例

假设 Fragment Shader 中有如下声明：

复制代码

layout(constant_id = 0) const int LIGHT_COUNT = 4;
layout(constant_id = 1) const bool ENABLE_SHADOW = true;
layout(constant_id = 2) const float EXPOSURE = 1.0;

2. C++ 侧准备数据结构

建议不要手写偏移，而是用 offsetof。

复制代码

struct SpecializationData
{
    int32_t  lightCount;
    VkBool32 enableShadow;
    float    exposure;
};

SpecializationData specData{};
specData.lightCount   = 8;
specData.enableShadow = VK_TRUE;
specData.exposure     = 1.5f;

注意：布尔类型建议使用 VkBool32，不要直接用 C++ 的 bool。因为 Vulkan 对 specialization boolean 的大小有明确要求，使用 bool 容易引入大小和对齐问题。

3. 建立 constant_id 到数据块的映射

复制代码

std::array<VkSpecializationMapEntry, 3> mapEntries{};

mapEntries[0].constantID = 0;
mapEntries[0].offset     = offsetof(SpecializationData, lightCount);
mapEntries[0].size       = sizeof(SpecializationData::lightCount);

mapEntries[1].constantID = 1;
mapEntries[1].offset     = offsetof(SpecializationData, enableShadow);
mapEntries[1].size       = sizeof(SpecializationData::enableShadow);

mapEntries[2].constantID = 2;
mapEntries[2].offset     = offsetof(SpecializationData, exposure);
mapEntries[2].size       = sizeof(SpecializationData::exposure);

这里的 constantID 必须与 GLSL 中的 layout(constant_id = N) 对应。

4. 填写 VkSpecializationInfo

复制代码

VkSpecializationInfo specializationInfo{};
specializationInfo.mapEntryCount = static_cast<uint32_t>(mapEntries.size());
specializationInfo.pMapEntries   = mapEntries.data();
specializationInfo.dataSize      = sizeof(SpecializationData);
specializationInfo.pData         = &specData;

5. 挂到 Shader Stage 上

复制代码

VkPipelineShaderStageCreateInfo fragStageInfo{};
fragStageInfo.sType  = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO;
fragStageInfo.stage  = VK_SHADER_STAGE_FRAGMENT_BIT;
fragStageInfo.module = fragmentShaderModule;
fragStageInfo.pName  = "main";
fragStageInfo.pSpecializationInfo = &specializationInfo;

然后将 fragStageInfo 放入 VkGraphicsPipelineCreateInfo::pStages，最终调用：

复制代码

vkCreateGraphicsPipelines(
    device,
    pipelineCache,
    1,
    &pipelineCreateInfo,
    nullptr,
    &pipeline
);

创建完成后，这个 Pipeline 中的 LIGHT_COUNT、ENABLE_SHADOW、EXPOSURE 就已经被固定。

六、完整示例：使用 Specialization Constants 控制光源数量和阴影开关

1. Fragment Shader

复制代码

#version 450

layout(constant_id = 0) const int LIGHT_COUNT = 4;
layout(constant_id = 1) const bool ENABLE_SHADOW = true;

layout(location = 0) in vec3 fragNormal;
layout(location = 1) in vec3 fragWorldPos;

layout(location = 0) out vec4 outColor;

vec3 evaluateLight(int index, vec3 normal, vec3 worldPos)
{
    vec3 lightDir = normalize(vec3(1.0, 1.0, 1.0));
    float ndotl = max(dot(normal, lightDir), 0.0);
    return vec3(ndotl) * 0.2;
}

float evaluateShadow(vec3 worldPos)
{
    return 0.6;
}

void main()
{
    vec3 normal = normalize(fragNormal);
    vec3 color = vec3(0.0);

    for (int i = 0; i < LIGHT_COUNT; ++i)
    {
        color += evaluateLight(i, normal, fragWorldPos);
    }

    if (ENABLE_SHADOW)
    {
        color *= evaluateShadow(fragWorldPos);
    }

    outColor = vec4(color, 1.0);
}

如果创建 Pipeline 时：

复制代码

LIGHT_COUNT = 1
ENABLE_SHADOW = false

驱动编译器可以把循环简化为一次光照计算，并完全移除阴影分支。

如果创建 Pipeline 时：

复制代码

LIGHT_COUNT = 8
ENABLE_SHADOW = true

驱动可以针对 8 盏灯和阴影路径生成另一个版本。

这就是 specialization 的本质：一个 Shader 模块，多个 Pipeline 变体。

七、Specialization Constants 的性能意义

Specialization Constants 的性能优势主要来自静态优化，而不是传参速度。

它可能带来的优化包括：

1. 分支消除

例如：

复制代码

if (ENABLE_PCF)
{
    shadow = sampleShadowPCF();
}
else
{
    shadow = sampleShadowSimple();
}

如果 ENABLE_PCF 是 UBO 变量，GPU 运行时仍然需要处理分支逻辑。

如果 ENABLE_PCF 是 specialization constant，创建 Pipeline 时值已经确定。编译器可以直接删除不可能执行的路径。

2. 循环展开

例如：

复制代码

for (int i = 0; i < LIGHT_COUNT; ++i)
{
    accumulateLight(i);
}

如果 LIGHT_COUNT 是普通 Uniform，编译器很难确定循环次数。

如果 LIGHT_COUNT 是 specialization constant，编译器可能把循环展开为固定次数的指令序列，从而减少循环控制开销，并为寄存器分配、指令调度提供更多优化空间。

3. 死代码删除

例如：

复制代码

if (USE_NORMAL_MAP)
{
    normal = sampleNormalMap();
}

当 USE_NORMAL_MAP = false 时，法线贴图采样、TBN 计算、相关纹理访问都可能被删除。

这类优化对于复杂材质系统非常重要。

4. 更好的寄存器和指令调度

当编译器知道某些参数是常量，就能更准确地安排寄存器使用、指令顺序和内联策略。尤其在移动 GPU、tile-based GPU、复杂 fragment shader、compute shader 中，这种收益可能更明显。

不过需要注意：Specialization Constants 不保证一定带来性能提升。最终优化效果取决于驱动、GPU 架构、Shader 复杂度和具体写法。它提供的是"让编译器有机会优化"的信息，而不是强制优化指令。

八、Specialization Constants 的代价：Pipeline 数量膨胀

Specialization Constants 最大的工程风险是 Pipeline 变体爆炸。

假设你有以下开关：

复制代码

USE_NORMAL_MAP    true / false
USE_SHADOW        true / false
USE_CLEARCOAT     true / false
USE_SKINNING      true / false
LIGHT_COUNT       1 / 2 / 4 / 8

变体数量可能是：

复制代码

2 × 2 × 2 × 2 × 4 = 64

如果再加入 MSAA、Blend Mode、Depth State、Render Pass、Shader Stage 组合，Pipeline 数量会迅速膨胀。

这会带来几个问题：

Pipeline 创建耗时增加；
Pipeline Cache 体积增大；
启动时间或加载时间变长；
Pipeline 管理复杂度上升；
热更新、预编译、异步创建需求增加。

因此，Specialization Constants 不是越多越好。

正确的策略是：

只把"真正影响 Shader 结构"的参数做成 specialization constants；
不要把每帧变化的数据做成 specialization constants；
不要把连续变化的浮点参数做成 specialization constants；
对常用组合进行预热或缓存；
对罕见组合延迟创建或异步创建；
控制 Pipeline Variant 的组合空间。

九、什么时候应该使用 Specialization Constants

适合使用的场景

1. Shader 功能开关

例如：

复制代码

layout(constant_id = 0) const bool USE_NORMAL_MAP = false;
layout(constant_id = 1) const bool USE_OCCLUSION_MAP = false;
layout(constant_id = 2) const bool USE_EMISSIVE = false;

这类开关直接决定代码路径是否存在，非常适合 specialization。

2. 固定循环次数

例如光源数量、采样核大小、模糊半径等级：

复制代码

layout(constant_id = 3) const int SAMPLE_COUNT = 16;

如果循环次数固定，编译器更容易展开和优化。

3. Compute Shader workgroup size

这是最典型的使用场景之一。

复制代码

layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;

不同 GPU 对 workgroup size 的偏好不同。Specialization Constants 可以让同一个 Compute Shader 在不同设备上创建不同的最优 Pipeline。

4. 移动端性能优化

移动 GPU 往往对分支、纹理采样、寄存器压力更敏感。通过 specialization constants 删除无用代码路径，可能显著降低 fragment shader 的执行成本。

5. 材质系统的有限变体

PBR 材质常见开关包括：

复制代码

baseColorTexture
normalTexture
metallicRoughnessTexture
occlusionTexture
emissiveTexture
alphaMode

可以将部分材质特征变成 specialization constants，用一个通用 Shader 生成多个优化后的材质 Pipeline。

十、不适合使用的场景

1. 每帧变化的数据

例如：

复制代码

camera position
view matrix
projection matrix
time
delta time
object transform
light position

这些应该使用 UBO、SSBO 或 Push Constants，而不是 Specialization Constants。

2. 每个 draw 都不同的数据

例如每个物体的材质颜色、对象 ID、骨骼矩阵索引。

这些值如果做成 specialization constants，就意味着每个对象可能需要一个 Pipeline，这通常不可接受。

3. 连续变化的浮点参数

例如曝光值、粗糙度、金属度、颜色系数。

虽然 specialization constants 支持 float，但如果这个 float 会频繁变化，就不应该使用。否则 Pipeline 数量会变得不可控。

4. 过多布尔开关

布尔开关看起来便宜，但多个布尔开关组合会指数增长。

如果某个开关不会显著减少 Shader 成本，就不值得 specialization。

十一、Specialization Constants 与 Pipeline Cache 的关系

由于 specialization constants 在 Pipeline 创建时参与编译，不同 specialization 值通常会生成不同的 Pipeline 结果。因此，应当配合 Pipeline Cache 使用。

工程中常见做法：

程序启动时加载已有 Pipeline Cache；
创建常用 Pipeline 变体；
运行过程中按需创建罕见变体；
程序退出或合适时机保存 Pipeline Cache；
下次启动时复用缓存，减少 Pipeline 创建成本。

需要注意的是，Pipeline Cache 的命中与驱动、设备、驱动版本、Pipeline 状态、Shader 模块、specialization 数据等因素有关。不能简单认为"只要有 Cache 就完全没有成本"。

更稳妥的做法是：

常用 Pipeline 预创建；
罕见 Pipeline 异步创建；
不要在渲染关键路径同步创建大量 Pipeline；
尽量减少不必要的 specialization 组合；
对材质和 pass 做清晰的变体分类。

十二、与 Shader 宏的对比

Specialization Constants 和 Shader 宏都能生成优化后的代码，但工程体验不同。

使用宏的方式

复制代码

#define LIGHT_COUNT 4
#define ENABLE_SHADOW 1

优点：

前端编译器也能看到常量；
离线编译结果明确；
对某些工具链较直观。

缺点：

每种组合都需要生成不同 Shader 源码或编译参数；
Shader 管理复杂；
SPIR-V 文件数量可能增多；
运行时灵活性较差。

使用 Specialization Constants 的方式

复制代码

layout(constant_id = 0) const int LIGHT_COUNT = 4;
layout(constant_id = 1) const bool ENABLE_SHADOW = true;

优点：

一个 SPIR-V 模块可以创建多个 Pipeline 变体；
不需要为每种组合保存不同 Shader 文件；
与 Vulkan Pipeline 创建流程自然结合；
适合运行时根据设备能力选择变体。

缺点：

前端编译阶段不能完全替代宏；
Pipeline 数量仍然会增加；
不同驱动优化质量可能不同；
调试时需要明确当前 Pipeline 使用了哪些 specialization 值。

简单来说：

宏更偏"离线变体生成"，Specialization Constants 更偏"运行时 Pipeline 变体生成"。

十三、与 Pipeline Layout、Descriptor Set 的关系

Specialization Constants 不属于 Descriptor Set，也不属于 Push Constant Range。

它不会占用：

复制代码

set
binding
descriptor
push constant range
uniform buffer
storage buffer

它直接挂在 Shader Stage 的创建信息上：

复制代码

VkPipelineShaderStageCreateInfo::pSpecializationInfo

因此，它不会改变 Descriptor Set Layout，也不需要在 VkPipelineLayout 中声明。

但是，它可能间接影响 Shader 是否使用某些资源。例如：

复制代码

layout(constant_id = 0) const bool USE_NORMAL_MAP = false;

layout(set = 1, binding = 0) uniform sampler2D normalMap;

void main()
{
    if (USE_NORMAL_MAP)
    {
        vec3 n = texture(normalMap, uv).xyz;
    }
}

即使 USE_NORMAL_MAP = false，从工程安全性上仍应保持 Pipeline Layout 与 Shader 接口匹配。不要依赖 specialization 后的死代码删除来规避资源声明问题。Descriptor Layout 设计应当稳定、明确、可验证。

十四、常见错误与排查方法

错误 1：constant_id 对不上

Shader：

复制代码

layout(constant_id = 3) const int SAMPLE_COUNT = 16;

CPU：

复制代码

mapEntry.constantID = 0;

这种情况下 CPU 传入的数据不会作用到 SAMPLE_COUNT。结果 Shader 会使用默认值。

排查方法：

建立统一枚举；
不要在 Shader 和 C++ 中手写散乱数字；
使用反射工具或生成代码；
在调试日志中打印 Pipeline 的 specialization 配置。

例如：

复制代码

enum SpecConstantID : uint32_t
{
    SPEC_LIGHT_COUNT   = 0,
    SPEC_ENABLE_SHADOW = 1,
    SPEC_EXPOSURE      = 2
};

错误 2：bool 使用 C++ bool

错误写法：

复制代码

struct SpecializationData
{
    bool enableShadow;
};

建议写法：

复制代码

struct SpecializationData
{
    VkBool32 enableShadow;
};

因为 C++ bool 通常是 1 字节，而 Vulkan specialization boolean 需要按 VkBool32 处理。否则可能导致大小不匹配或数据解释错误。

错误 3：手写 offset

错误写法：

复制代码

mapEntry.offset = 4;

建议写法：

复制代码

mapEntry.offset = offsetof(SpecializationData, exposure);

C++ 结构体可能存在对齐和 padding。手写 offset 容易出错。

错误 4：以为可以 draw 前修改

Specialization Constants 在 Pipeline 创建阶段固定。不能这样使用：

复制代码

// 错误理解：以为改 specData 后再 draw 会生效
specData.lightCount = 16;
vkCmdDraw(...);

Pipeline 创建后，修改 specData 不会改变已经创建好的 Pipeline。

如果需要不同值，应该创建另一个 Pipeline。

错误 5：把高频参数做成 specialization constants

例如：

复制代码

layout(constant_id = 0) const float time = 0.0;

这是错误设计。time 每帧变化，应该使用 UBO 或 Push Constants。

错误 6：变体组合失控

不要因为 specialization constants 好用，就把所有材质参数都做成 specialization constants。

正确方式是先分类：

复制代码

影响 Shader 结构的参数 -> specialization constants
影响数据值的参数 -> UBO / Push Constants / SSBO
影响资源绑定的参数 -> Descriptor Set
影响固定功能状态的参数 -> Pipeline State / Dynamic State

十五、工程设计建议：如何组织 Specialization Constants

1. 使用明确的变体描述结构

复制代码

struct MaterialVariantKey
{
    bool useNormalMap;
    bool useOcclusionMap;
    bool useEmissiveMap;
    uint32_t lightCount;
};

然后为它生成 hash，用于 Pipeline Cache 或 Pipeline Map：

复制代码

struct PipelineKey
{
    VkRenderPass renderPass;
    VkFormat colorFormat;
    VkFormat depthFormat;
    MaterialVariantKey materialVariant;
};

这样可以避免 Pipeline 管理混乱。

2. 对 specialization 数据做集中封装

复制代码

struct PbrSpecData
{
    VkBool32 useNormalMap;
    VkBool32 useOcclusionMap;
    VkBool32 useEmissiveMap;
    int32_t  lightCount;
};

class SpecializationBuilder
{
public:
    void add(uint32_t constantID, uint32_t offset, size_t size);

    VkSpecializationInfo build(const void* data, size_t size);

private:
    std::vector<VkSpecializationMapEntry> entries;
};

大型引擎中，最好不要在每个 Pipeline 创建函数里手写 VkSpecializationMapEntry。

3. 控制变体数量

可以将变体分成几类：

复制代码

核心变体：启动时创建
常用变体：加载场景时创建
罕见变体：运行时异步创建
调试变体：仅开发环境启用

不要在渲染线程中遇到一个材质就同步创建一个 Pipeline，否则容易产生卡顿。

4. 建议记录 Pipeline 创建日志

例如：

复制代码

Create Pipeline:
  shader = pbr.frag.spv
  USE_NORMAL_MAP = true
  USE_OCCLUSION_MAP = false
  LIGHT_COUNT = 4
  renderPass = GBuffer

这对调试 Pipeline 爆炸、Pipeline Cache 未命中、材质显示错误非常有帮助。

十六、在 Vulkan 渲染器中的典型使用方式

一个成熟 Vulkan 渲染器中，Specialization Constants 通常用于以下层级：

1. Material System

复制代码

PBR 材质是否使用 normal map
是否使用 occlusion map
是否启用 alpha test
是否启用 clearcoat
是否启用 skinning

2. Lighting Pass

复制代码

tile light count
cluster size
shadow mode
IBL sample count

3. Post Processing

复制代码

blur kernel size
bloom sample count
tone mapping mode
FXAA / TAA 开关

4. Compute Pass

复制代码

local_size_x
local_size_y
tile size
scan block size
particle group size

5. Debug / Visualization

复制代码

debug view mode
show normals
show roughness
show metallic
show overdraw

不过 debug view mode 如果切换频繁，也可以用 Push Constants 或 UBO。是否使用 specialization constants，取决于它是否值得生成独立 Pipeline。

十七、一个更完整的 Compute Shader 示例

Shader

复制代码

#version 450

layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;

layout(constant_id = 2) const bool ENABLE_THRESHOLD = true;
layout(constant_id = 3) const float THRESHOLD_VALUE = 0.5;

layout(set = 0, binding = 0, rgba8) uniform readonly image2D inputImage;
layout(set = 0, binding = 1, rgba8) uniform writeonly image2D outputImage;

void main()
{
    ivec2 coord = ivec2(gl_GlobalInvocationID.xy);

    vec4 color = imageLoad(inputImage, coord);

    if (ENABLE_THRESHOLD)
    {
        float luminance = dot(color.rgb, vec3(0.299, 0.587, 0.114));
        color.rgb = luminance > THRESHOLD_VALUE ? color.rgb : vec3(0.0);
    }

    imageStore(outputImage, coord, color);
}

C++ 侧

复制代码

struct ComputeSpecData
{
    uint32_t localSizeX;
    uint32_t localSizeY;
    VkBool32 enableThreshold;
    float thresholdValue;
};

ComputeSpecData specData{};
specData.localSizeX = 16;
specData.localSizeY = 16;
specData.enableThreshold = VK_TRUE;
specData.thresholdValue = 0.75f;

std::array<VkSpecializationMapEntry, 4> entries{};

entries[0] = {
    0,
    offsetof(ComputeSpecData, localSizeX),
    sizeof(ComputeSpecData::localSizeX)
};

entries[1] = {
    1,
    offsetof(ComputeSpecData, localSizeY),
    sizeof(ComputeSpecData::localSizeY)
};

entries[2] = {
    2,
    offsetof(ComputeSpecData, enableThreshold),
    sizeof(ComputeSpecData::enableThreshold)
};

entries[3] = {
    3,
    offsetof(ComputeSpecData, thresholdValue),
    sizeof(ComputeSpecData::thresholdValue)
};

VkSpecializationInfo specInfo{};
specInfo.mapEntryCount = static_cast<uint32_t>(entries.size());
specInfo.pMapEntries = entries.data();
specInfo.dataSize = sizeof(ComputeSpecData);
specInfo.pData = &specData;

VkPipelineShaderStageCreateInfo stageInfo{};
stageInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO;
stageInfo.stage = VK_SHADER_STAGE_COMPUTE_BIT;
stageInfo.module = computeShaderModule;
stageInfo.pName = "main";
stageInfo.pSpecializationInfo = &specInfo;

VkComputePipelineCreateInfo pipelineInfo{};
pipelineInfo.sType = VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO;
pipelineInfo.stage = stageInfo;
pipelineInfo.layout = computePipelineLayout;

VkPipeline computePipeline = VK_NULL_HANDLE;

vkCreateComputePipelines(
    device,
    pipelineCache,
    1,
    &pipelineInfo,
    nullptr,
    &computePipeline
);

这个例子中，同一份 Compute Shader 可以生成多个版本：

复制代码

8x8  + threshold on
16x16 + threshold on
16x16 + threshold off
32x8 + threshold off

其中 threshold off 的版本有机会完全删除阈值计算逻辑。

十八、最佳实践总结

应该做

用 specialization constants 表达 Pipeline 级别的静态配置。
用它控制 Shader 分支、循环次数、Compute workgroup size。
使用 offsetof 计算偏移。
使用 VkBool32 表达布尔 specialization constant。
为 constant id 建立统一枚举。
配合 Pipeline Cache 使用。
控制 Pipeline 变体数量。
在 Pipeline Key 中记录 specialization values。
对常用变体预创建。
避免在渲染关键路径同步创建大量 Pipeline。

不应该做

不要用它传每帧变化的数据。
不要用它传每个 draw 不同的数据。
不要把连续浮点参数大量 specialization。
不要无节制添加布尔开关。
不要把它当成 Push Constants。
不要认为修改 CPU 侧数据会影响已创建 Pipeline。
不要依赖死代码删除来逃避 Descriptor Layout 设计。
不要忽略 Pipeline 数量膨胀问题。

十九、结语

Specialization Constants 是 Vulkan 中非常重要但容易被低估的机制。

它的本质不是"另一种传参方式"，而是"Pipeline 级别的 Shader 变体机制"。它允许开发者在保持 Shader 模块统一的同时，为不同设备、不同材质、不同渲染路径生成经过优化的 Pipeline。

从引擎设计角度看，它最适合处理这些问题：

复制代码

这个功能开不开？
这个循环固定跑几次？
这个 Compute Shader 的 workgroup size 是多少？
这个材质是否需要某条昂贵路径？
这个后处理 pass 是否可以裁掉某些采样？

但它并不适合处理这些问题：

复制代码

当前帧时间是多少？
当前相机矩阵是多少？
当前物体颜色是多少？
当前 draw 的对象 ID 是多少？

掌握 Specialization Constants 的关键，是理解它在 Vulkan 架构中的位置：

它发生在 Shader Module 之后，Pipeline 创建期间，Draw / Dispatch 之前。

也正因为它位于这个阶段，它才能同时具备两种特性：

复制代码

比 #define 更灵活；
比 Uniform / Push Constants 更容易被静态优化。

这就是 Vulkan Specialization Constants 的真正价值。