使用OpenGL和GLSL的SSAO算法的奇怪表现行为(Strange performance behaviour with SSAO algorithm using OpenGL and GLSL)

 我正在使用Oriented-Hemisphere渲染技术研究SSAO（屏幕空间环境遮挡）算法。 
 
 I）算法 
 
 该算法需要输入： 
 
 
 
 1包含预计算样本的数组（在主循环之前加载 - >在我的示例中，我使用根据z轴定向的64个样本 ）。 
 
 
 1噪声纹理包含也根据z轴定向的归一化旋转矢量（该纹理生成一次）。 
 
 
 来自GBuffer的2个纹理：包含视图空间中的位置和法向量的'PositionSampler'和'NormalSampler'。 
 
 
 以下是我使用的片段着色器源代码： 
 
#version 400

/*
** Output color value.
*/
layout (location = 0) out vec4 FragColor;

/*
** Vertex inputs.
*/
in VertexData_VS
{
    vec2 TexCoords;

} VertexData_IN;

/*
** Inverse Projection Matrix.
*/
uniform mat4 ProjMatrix;

/*
** GBuffer samplers.
*/
uniform sampler2D PositionSampler;
uniform sampler2D NormalSampler;

/*
** Noise sampler.
*/
uniform sampler2D NoiseSampler;

/*
** Noise texture viewport.
*/
uniform vec2 NoiseTexOffset;

/*
** Ambient light intensity.
*/
uniform vec4 AmbientIntensity;

/*
** SSAO kernel + size.
*/
uniform vec3 SSAOKernel[64];
uniform uint SSAOKernelSize;
uniform float SSAORadius;

/*
** Computes Orientation matrix.
*/
mat3 GetOrientationMatrix(vec3 normal, vec3 rotation)
{
    vec3 tangent = normalize(rotation - normal * dot(rotation, normal)); //Graham Schmidt process 
    vec3 bitangent = cross(normal, tangent);

    return (mat3(tangent, bitangent, normal)); //Orientation according to the normal
}

/*
** Fragment shader entry point.
*/
void main(void)
{
    float OcclusionFactor = 0.0f;

    vec3 gNormal_CS = normalize(texture(
        NormalSampler, VertexData_IN.TexCoords).xyz * 2.0f - 1.0f); //Normal vector in view space from GBuffer
    vec3 rotationVec = normalize(texture(NoiseSampler,
        VertexData_IN.TexCoords * NoiseTexOffset).xyz * 2.0f - 1.0f); //Rotation vector required for Graham Schmidt process

    vec3 Origin_VS = texture(PositionSampler, VertexData_IN.TexCoords).xyz; //Origin vertex in view space from GBuffer
    mat3 OrientMatrix = GetOrientationMatrix(gNormal_CS, rotationVec);

    for (int idx = 0; idx < SSAOKernelSize; idx++) //For each sample (64 iterations)
    {
        vec4 Sample_VS = vec4(Origin_VS + OrientMatrix * SSAOKernel[idx], 1.0f); //Sample translated in view space

        vec4 Sample_HS = ProjMatrix * Sample_VS; //Sample in homogeneus space
        vec3 Sample_CS = Sample_HS.xyz /= Sample_HS.w; //Perspective dividing (clip space)
        vec2 texOffset = Sample_CS.xy * 0.5f + 0.5f; //Recover sample texture coordinates

        vec3 SampleDepth_VS = texture(PositionSampler, texOffset).xyz; //Sample depth in view space

        if (Sample_VS.z < SampleDepth_VS.z)
            if (length(Sample_VS.xyz - SampleDepth_VS) <= SSAORadius)
                OcclusionFactor += 1.0f; //Occlusion accumulation
    }
    OcclusionFactor = 1.0f - (OcclusionFactor / float(SSAOKernelSize));

    FragColor = vec4(OcclusionFactor);
    FragColor *= AmbientIntensity;
}
 
 结果如下（没有模糊渲染通过）： 
 
  
 
 直到这里似乎都是正确的。 
 
 二）表演 
 
 我注意到NSight调试器在性能方面有一个非常奇怪的行为： 
 
 如果我将相机靠近龙的方向移动，演出将受到严重影响。 
 
 但是，在我看来，情况并非如此，因为SSAO算法适用于Screen-Space，并且不依赖于龙的基元数量。 
 
 这里有3个屏幕截图，包含3个不同的摄像头位置（这3个案例中所有1024 * 768像素着色器都使用相同的算法执行）： 
 
 a）GPU闲置：40％（像素受影响：100％） 
 
  
 
 b）GPU闲置：25％（影响像素：100％） 
 
  
 
 c）GPU闲置：2％！ （像素受影响：100％） 
 
  
 
 我的渲染引擎在我的示例中使用了2个渲染通道： 
 
 
 
 材料通行证 （填写位置和正常采样器） 
 
 
 Ambient pass （填充SSAO纹理） 
 
 
 我认为问题来自这两个通行证的执行，但事实并非如此，因为我在客户端代码中添加了一个条件，即如果摄像机静止，则无法计算物质通行证。 所以当我拍摄上面这3张照片的时候，只有Ambient Pass被执行了。 所以这种缺乏表现与物质关系无关。 我可以给你的另一个论据是，如果我移除龙的网格（只有飞机的场景），结果是相同的：我的相机更接近飞机，更缺乏性能！ 
 
 对我而言，这种行为是不合逻辑的！ 就像我上面所说的那样，在这三种情况下，所有像素着色器都是使用完全相同的像素着色器代码执行的！ 
 
 现在我注意到另一个奇怪的行为，如果我直接在片段着色器中更改一小段代码： 
 
 如果我更换该行： 
 
FragColor = vec4(OcclusionFactor);
 
 由该行： 
 
FragColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
 
 缺乏表现消失！ 
 
 这意味着如果SSAO代码被正确执行（我试图在执行过程中放置​​一些断点来检查它），并且在末尾没有使用这个OcclusionFactor来填充最终的输出颜色，所以不缺乏性能！ 
 
 我认为我们可以得出结论，问题不是来自于“FragColor = vec4（OcclusionFactor）”这一行之前的着色器代码;“ ... 我认为。 
 
 你怎么能解释这样的行为？ 
 
 我在客户端代码和片段着色器代码中尝试了很多代码的组合，但是我找不到解决这个问题的方法！ 我真的迷失了。 
 
 非常感谢您的帮助！ 

I'm working on the SSAO (Screen-Space Ambient Occlusion) algorithm using Oriented-Hemisphere rendering technique.
 
I) The algorithm
 
This algorithm requires as inputs:
 
 
 
1 array containing precomputed samples (loaded before the main loop -> In my example I use 64 samples oriented according to the z axis).
 
 
1 noise texture containing normalized rotation vectors also oriented according to the z axis (this texture is generated once).
 
 
2 textures from the GBuffer: the 'PositionSampler' and the 'NormalSampler' containing the positions and normal vectors in view space.
 
 
Here's the fragment shader source code I use:
 
#version 400

/*
** Output color value.
*/
layout (location = 0) out vec4 FragColor;

/*
** Vertex inputs.
*/
in VertexData_VS
{
    vec2 TexCoords;

} VertexData_IN;

/*
** Inverse Projection Matrix.
*/
uniform mat4 ProjMatrix;

/*
** GBuffer samplers.
*/
uniform sampler2D PositionSampler;
uniform sampler2D NormalSampler;

/*
** Noise sampler.
*/
uniform sampler2D NoiseSampler;

/*
** Noise texture viewport.
*/
uniform vec2 NoiseTexOffset;

/*
** Ambient light intensity.
*/
uniform vec4 AmbientIntensity;

/*
** SSAO kernel + size.
*/
uniform vec3 SSAOKernel[64];
uniform uint SSAOKernelSize;
uniform float SSAORadius;

/*
** Computes Orientation matrix.
*/
mat3 GetOrientationMatrix(vec3 normal, vec3 rotation)
{
    vec3 tangent = normalize(rotation - normal * dot(rotation, normal)); //Graham Schmidt process 
    vec3 bitangent = cross(normal, tangent);

    return (mat3(tangent, bitangent, normal)); //Orientation according to the normal
}

/*
** Fragment shader entry point.
*/
void main(void)
{
    float OcclusionFactor = 0.0f;

    vec3 gNormal_CS = normalize(texture(
        NormalSampler, VertexData_IN.TexCoords).xyz * 2.0f - 1.0f); //Normal vector in view space from GBuffer
    vec3 rotationVec = normalize(texture(NoiseSampler,
        VertexData_IN.TexCoords * NoiseTexOffset).xyz * 2.0f - 1.0f); //Rotation vector required for Graham Schmidt process

    vec3 Origin_VS = texture(PositionSampler, VertexData_IN.TexCoords).xyz; //Origin vertex in view space from GBuffer
    mat3 OrientMatrix = GetOrientationMatrix(gNormal_CS, rotationVec);

    for (int idx = 0; idx < SSAOKernelSize; idx++) //For each sample (64 iterations)
    {
        vec4 Sample_VS = vec4(Origin_VS + OrientMatrix * SSAOKernel[idx], 1.0f); //Sample translated in view space

        vec4 Sample_HS = ProjMatrix * Sample_VS; //Sample in homogeneus space
        vec3 Sample_CS = Sample_HS.xyz /= Sample_HS.w; //Perspective dividing (clip space)
        vec2 texOffset = Sample_CS.xy * 0.5f + 0.5f; //Recover sample texture coordinates

        vec3 SampleDepth_VS = texture(PositionSampler, texOffset).xyz; //Sample depth in view space

        if (Sample_VS.z < SampleDepth_VS.z)
            if (length(Sample_VS.xyz - SampleDepth_VS) <= SSAORadius)
                OcclusionFactor += 1.0f; //Occlusion accumulation
    }
    OcclusionFactor = 1.0f - (OcclusionFactor / float(SSAOKernelSize));

    FragColor = vec4(OcclusionFactor);
    FragColor *= AmbientIntensity;
}
 
And here's the result (without blur render pass):
 
 
Until here all seems to be correct.
 
II) The performance
 
I noticed NSight Debugger a very strange behaviour concerning the performance:
 
If I move my camera closer and closer toward the dragon the performances are drastically impacted.
 
But, in my mind, it should be not the case because SSAO algorithm is apply in Screen-Space and do not depend on the number of primitives of the dragon for example.
 
Here's 3 screenshots with 3 different camera positions (with those 3 case all 1024*768 pixel shaders are executed using all the same algorithm):
 
a) GPU idle : 40% (pixel impacted: 100%)
 
 
b) GPU idle : 25% (pixel impacted: 100%)
 
 
c) GPU idle : 2%! (pixel impacted: 100%)
 
 
My rendering engine uses in my example exaclly 2 render passes:
 
 
 
the Material Pass (filling the position and normal samplers)
 
 
the Ambient pass (filling the SSAO texture)
 
 
I thought the problem comes from the addition of the execution of these two passes but it's not the case because I've added in my client code a condition to not compute for nothing the material pass if the camera is stationary. So when I took these 3 pictures above there was just the Ambient Pass executed. So this lack of performance in not related to the material pass. An other argument I could give you is if I remove the dragon mesh (the scene with just the plane) the result is the same: more my camera is close to the plane, more the lack of performance is huge!
 
For me this behaviour is not logical! Like I said above, in these 3 cases all the pixel shaders are executed applying exactly the same pixel shader code!
 
Now I noticed another strange behaviour if I change a little piece of code directly within the fragment shader:
 
If I replace the line:
 
FragColor = vec4(OcclusionFactor);
 
By the line:
 
FragColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
 
The lack of performance disappears!
 
It means that if the SSAO code is correctly executed (I tried to place some break points during the execution to check it) and I don't use this OcclusionFactor at the end to fill the final output color, so there is no lack of performance!
 
I think we can conclude that the problem does not come from the shader code before the line "FragColor = vec4(OcclusionFactor);"... I think.
 
How can yo explain a such behaviour?
 
I tried a lot of combination of code both in the client code and in the fragment shader code but I can't find the solution to this problem! I'm really lost.
 
Thank you very much in advance for your help!

原文：https://stackoverflow.com/questions/31682173