GPUWeb 项目中关于着色器阶段存储资源限制的兼容性设计思考

在 GPUWeb 项目的开发过程中，着色器阶段存储资源限制的设计引发了一系列关于兼容性验证时机的讨论。本文将深入分析这一技术问题，探讨不同验证方案的优缺点，并最终给出合理的解决方案。

问题背景

在 WebGPU 规范中，存在两类与存储资源相关的限制：

1. maxStorage(Buffer/Texture)sPerShaderStage：每个着色器阶段可用的最大存储资源数量
2. maxStorage(Buffers/Textures)In(Vertex/Fragment)Stage：顶点/片段着色器中可用的最大存储资源数量

当前实现中存在一个不一致性：前者在创建绑定组布局（bindGroupLayout）和管线布局（pipelineLayout）时就进行验证，而后者仅在创建管线时才进行验证。

技术挑战

考虑以下典型用例：

1. 创建一个包含存储纹理的绑定组布局
2. 使用该布局创建管线布局
3. 创建一个不引用任何资源的基础着色器
4. 尝试创建渲染管线

按照当前规范，即使着色器本身不使用任何资源，只要管线布局引用的存储资源超过限制，就会在管线创建时报错。这与开发者直觉相悖，也与其他限制的验证时机不一致。

解决方案分析

开发团队考虑了多种可能的解决方案：

1. 统一验证时机：将maxStorage(Buffers/Textures)In(Vertex/Fragment)Stage的验证提前到绑定组布局和管线布局创建时，与其他限制保持一致。

2. 放宽核心限制：允许创建超出限制的绑定组布局和管线布局，仅在创建管线时报错。

3. 基于实际使用验证：仅在实际使用的资源超过限制时报错，允许创建不使用的资源。

4. 维持现状：保持当前的验证时机和方式。

经过深入讨论，团队发现：

• 方案3在技术上不可行，因为不同管线共享同一布局时必须保持兼容性
• 方案2会导致创建"无效"对象，违反API设计原则
• Vulkan等底层API要求在管线布局创建时就满足限制

最终决策

基于技术一致性和底层API兼容性考虑，团队决定采用方案1：

• 将maxStorage(Buffers/Textures)In(Vertex/Fragment)Stage的验证提前到绑定组布局和管线布局创建阶段
• 保持与其他资源限制相同的验证逻辑
• 确保API行为的一致性和可预测性

这一决策虽然会导致某些理论上可用的配置被拒绝，但保证了API的严谨性和跨平台兼容性，同时也简化了实现复杂度。

总结

GPUWeb项目通过这一讨论，进一步明确了资源限制验证的设计原则：优先保证API行为的一致性和底层兼容性，即使这意味着在某些边缘情况下会显得过于严格。这种设计选择有助于减少实现差异，提高开发者体验，最终推动WebGPU生态的健康发展。