GLSL中本地数组随机写入为何远慢于循环写入？

这个GLSL里的性能反差问题挺值得深究的，我来给你掰扯清楚为什么两种写法的执行速度差这么大。

先看原始的简化实现：

void foo() {
    vec2 localData[16];
    // ... 其他逻辑
    int i = ...; // 编译时未知的动态索引
    localData[i] = x; // 看似简洁的动态赋值
}

这段代码的意图很直接：把值x写入本地数组localData的动态计算索引位置。但当把关键行替换成下面这种看似“冗余”的循环分支写法后，在多个不同着色器的测试案例中，执行时间几乎大幅降低：

void foo() {
    vec2 localData[16];
    // ... 其他逻辑
    int i = ...; // 同样的动态索引
    for( int j = 0; j < 16; ++j ) {
        if( i == j ) {
            localData[j] = x;
        }
    }
}

核心原因：GPU的并行执行模型与内存访问特性 #

要理解这个差异，得先搞懂GPU的底层执行逻辑：

• GPU是按波前（Wavefront）/ warp为单位并行执行的，同一个波前里的所有线程会同步执行相同的指令。
• 当使用localData[i] = x这种动态索引时，每个线程的i可能各不相同，这会导致内存散列访问——不同线程访问数组的不连续位置。GPU的内存控制器是为连续内存访问优化的，散列访问会引发大量的内存冲突，让内存带宽的利用率暴跌，因为控制器需要逐个处理不连续的内存请求，等待时间大幅增加。
• 而循环+条件判断的写法，GLSL编译器会做分支扁平化优化：因为循环次数是固定的（16次），编译器会把循环展开成16条独立的指令。每个线程会依次检查j是否等于i，但这里的条件分支不会真的让线程分叉执行，而是转换成掩码操作——线程会遍历数组的所有连续位置，只在匹配索引的位置执行赋值，其他位置做无意义的空操作。这种情况下，内存访问是连续顺序的，GPU内存控制器可以批量处理这些请求，带宽利用率拉满，自然执行速度就上去了。

注意事项 #

这种优化只适用于小尺寸的本地数组（比如这里的16元素）。如果数组太大，循环展开后的指令数量会急剧增加，反而会因为指令缓存压力过大导致性能下降。但对于小数组场景，这种“看似冗余”的写法反而更贴合GPU的执行特性。

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