javascript - Webgl Angular 循环真的很慢

Question

我这里有一些 glsl，它非常有用。仅编译需要 3 分钟左右。我知道这是由于 Angular 原因，Angle 是一款将 opengl es 2.0 代码转换为 directX 9 for webgl on windows 系统的软件。如果我禁用 Angular ，它会在一秒钟内编译。有谁知道嵌套循环的 Angular 太慢的原因。如果有解决方法？我的意思是我不能让每个人在每个着色器上等待超过一分钟。

for ( int b = 0; b < numberOfSplitpoints; b++ ) {
    if ( cameraDepth > splitPoints[b] && cameraDepth < splitPoints[b+1] ) {
        const float numberOfSplitpoints = float( NUMBER_OF_SPLIT_POINTS - 1 );
        vec4 projCoords = v_projTextureCoords[b];

        projCoords /= projCoords.w;
        projCoords = 0.5 * projCoords + 0.5;

        float shadowDepth = projCoords.z;

        projCoords.x /= numberOfSplitpoints;
        projCoords.x += float(b) / numberOfSplitpoints;


        for( int x = 0; x < fullkernelSize; x++ ) {
            for( int y = 0; y < fullkernelSize; y++ ) {
                vec2 pointer = vec2( float(x-kernelsize) / 3072.0, float(y-kernelsize) / 1024.0 );
                float convolution = kernel[x] * kernel[y];
                vec4 color = texture2D(shadowMapSampler, projCoords.xy+pointer);

                if(encodeDepth( color ) + shadowBias > shadowDepth) {
                    light += convolution;
                } else {
                    light += convolution * 0.6;
                }
            }
        } 
    }
}

vec2 random = normalize(texture2D(randomSampler, screenSize * uv / 64.0).xy * 2.0 - 1.0);
float ambiantAmount = 0.0;

const int kernel = 4;

float offset = ssoasampleRad / depth;


for(int x = 0; x<kernel; x++) {

    vec2 a  = reflect(directions[x], random) * offset;

    vec2 b  = vec2( a.x *0.707 - a.y*0.707, 
                    a.x*0.707 + a.y*0.707 );

    ambiantAmount += abientOcclusion(uv, a*0.25, position, normal);
    ambiantAmount += abientOcclusion(uv, b*0.50, position, normal);
    ambiantAmount += abientOcclusion(uv, a*0.75, position, normal);
    ambiantAmount += abientOcclusion(uv, b, position, normal);
}

Answer 1

GLSL ES 没有定义 while 循环和“动态”限定 for 循环是强制性的。ANGLE 利用了这一点并进行了广泛的循环展开:如果你有 for ( int b = 0; b < numberOfSplitpoints; b++ ) , numberOfSplitpoints必须是常量表达式，否则着色器将无法编译。

循环展开应该允许 native 着色器优化器进行更多优化并最大限度地减少分歧，但是(在您的代码中)如果您有 numberOfSplitpoints和 fullkernelSize非常大，展开的代码可能会变得很长(最里面的代码将重复 numberOfSplitpoints*fullkernelSize*fullkernelSize 次)，这可能会导致优化器和编译器陷入各种麻烦。