为何描述符/Uniform非均匀动态索引难实现？与分支写法有何差异？

描述符的非均匀动态索引实现难度较高：在Vulkan中它曾仅作为扩展存在，多数Android设备不支持Vulkan 1.2或Descriptor Indexing特性；而作为现代图形API的WebGPU完全不支持该特性，足以见得其实现的挑战性。

不过以下两种分支写法却能正常工作：

写法1：if-else分支 #

if (tex_id == 0)
// 从描述符/统一变量0采样
else if (tex_id == 1)
// 从描述符/统一变量1采样

写法2：switch分支 #

switch (tex_id)
case 0: // 从描述符/统一变量0采样;
case 1: // 从描述符/统一变量1采样;

请问：

1. 这两种写法的差异是什么？
2. 为何在设备不支持非均匀动态索引时，图形API不自动模拟类似的分支逻辑？

两种写法的核心差异 #

• 编译优化方向不同：switch语句会被编译器优先识别为离散的常量分支集合，很容易优化成跳转表（jump table），执行时直接通过索引跳转，分支越多性能优势越明显；而if-else是线性判断逻辑，每一个分支都要依次检查条件，分支数量多的时候性能损耗会直线上升。
• 代码维护成本不同：当分支数量超过3个时，switch的结构更清晰，新增、修改分支的成本更低；链式if-else会随着分支增加变得臃肿，可读性和维护性都会下降。
• 默认流程逻辑不同：switch默认存在贯穿（fallthrough）行为——如果不写break，会自动执行下一个case的代码；而if-else是严格的互斥分支，不存在这种隐含逻辑，出错概率更低。

图形API不自动模拟分支逻辑的原因 #

• 性能开销不可控：如果API自动把动态索引转换成分支逻辑，需要在编译着色器时生成所有可能的分支。要是描述符数量多达上百个，生成的代码会极度膨胀，既增加编译时间，又会导致运行时指令缓存命中率暴跌，性能反而远不如开发者手动优化的代码。
• 硬件适配难度大：不同GPU对分支的处理能力差异极大，低端GPU的分支执行效率极低，强制生成大量分支可能导致部分设备直接无法运行，或者性能降到不可接受的程度。API需要保证跨设备的一致性和性能基线，不能做这种可能破坏体验的自动转换。
• 语义歧义风险高：动态索引的语义是「根据运行时变量直接访问任意描述符」，而分支逻辑是「逐个判断常量条件」。如果API自动转换，会出现语义不一致的问题——比如当索引超出分支覆盖范围时，动态索引会触发错误，但自动生成的分支可能会默认处理成某种行为，让开发者难以排查问题，这不符合图形API「明确可控」的设计原则。
• 开发者控制权需求：图形API的核心设计逻辑是让开发者掌握性能优化的主动权。是否用分支、用哪种分支、覆盖多少个索引，这些都是开发者可以根据场景和目标硬件自主选择的优化点，API不应该替开发者做这种可能牺牲性能的决策。

内容的提问来源于stack exchange，提问作者Zebrafish