如何提高自定义 OpenGL ES 2.0 深度纹理生成的性能？

Question

我有一个开源 iOS 应用程序，它使用自定义 OpenGL ES 2.0 着色器来显示分子结构的 3D 表示。它通过使用在矩形上绘制的程序生成的球体和圆柱体冒名顶替者来实现这一点，而不是使用大量顶点构建的相同形状。这种方法的缺点是，这些冒充对象的每个片段的深度值需要在片段着色器中计算，以便在对象重叠时使用。

不幸的是，OpenGL ES 2.0 不允许您写入 gl_FragDepth ，所以我需要将这些值输出到自定义深度纹理。我使用帧缓冲区对象 (FBO) 对场景进行传递，仅渲染与深度值相对应的颜色，并将结果存储到纹理中。然后将该纹理加载到渲染过程的后半部分，其中生成实际的屏幕图像。如果该阶段的片段处于存储在屏幕上该点的深度纹理中的深度级别，则显示该片段。如果没有，就被扔掉。有关该过程的更多信息，包括图表，可以在我的帖子 此处。

这种深度纹理的生成是我的渲染过程中的一个瓶颈，我正在寻找一种方法来使其更快。它似乎比应有的速度慢，但我不明白为什么。为了正确生成此深度纹理​​，请禁用 GL_DEPTH_TEST，使用 glBlendFunc(GL_ONE, GL_ONE) 启用 GL_BLEND，并且 < code>glBlendEquation() 设置为 GL_MIN_EXT。我知道以这种方式输出的场景在 iOS 设备中的 PowerVR 系列等基于图块的延迟渲染器上并不是最快的，但我想不出更好的方法来做到这一点。

我的球体深度片段着色器（最常见的显示元素）看起来是这个瓶颈的核心（仪器中的渲染器利用率固定为 99%，表明我受到片段处理的限制）。目前看起来如下：

precision mediump float;

varying mediump vec2 impostorSpaceCoordinate;
varying mediump float normalizedDepth;
varying mediump float adjustedSphereRadius;

const vec3 stepValues = vec3(2.0, 1.0, 0.0);
const float scaleDownFactor = 1.0 / 255.0;

void main()
{
    float distanceFromCenter = length(impostorSpaceCoordinate);
    if (distanceFromCenter > 1.0)
    {
        gl_FragColor = vec4(1.0);
    }
    else
    {
        float calculatedDepth = sqrt(1.0 - distanceFromCenter * distanceFromCenter);
        mediump float currentDepthValue = normalizedDepth - adjustedSphereRadius * calculatedDepth;

        // Inlined color encoding for the depth values
        float ceiledValue = ceil(currentDepthValue * 765.0);

        vec3 intDepthValue = (vec3(ceiledValue) * scaleDownFactor) - stepValues;

        gl_FragColor = vec4(intDepthValue, 1.0);
    }
}

在 iPad 1 上，使用直通着色器进行显示需要 35 - 68 毫秒来渲染 DNA 空间填充模型的帧（iPhone 4 上为 18 到 35 毫秒）。根据 PowerVR PVRUniSCo 编译器（其 SDK 的一部分） ，该着色器最多使用 11 个 GPU 周期，最差使用 16 个周期。我知道建议您不要在着色器中使用分支，但在这种情况下，这会带来比其他情况更好的性能。

当我简化它时

precision mediump float;

varying mediump vec2 impostorSpaceCoordinate;
varying mediump float normalizedDepth;
varying mediump float adjustedSphereRadius;

void main()
{
    gl_FragColor = vec4(adjustedSphereRadius * normalizedDepth * (impostorSpaceCoordinate + 1.0) / 2.0, normalizedDepth, 1.0);
}

，在 iPad 1 上需要 18 - 35 毫秒，但在 iPhone 4 上只需要 1.7 - 2.4 毫秒。该着色器的估计 GPU 周期数为 8 个周期。基于周期计数的渲染时间的变化似乎不是线性的。

最后，如果我只输出恒定的颜色：

precision mediump float;

void main()
{
    gl_FragColor = vec4(0.5, 0.5, 0.5, 1.0);
}

iPad 1 上的渲染时间降至 1.1 - 2.3 毫秒（iPhone 4 上为 1.3 毫秒）。

渲染时间的非线性缩放以及 iPad 和 iPhone 4 之间第二个着色器的突然变化让我觉得我在这里遗漏了一些东西。包含这三个着色器变体的完整源项目（查看 SphereDepth.fsh 文件并注释掉相应部分）和测试模型可以从 此处，如果您想亲自尝试一下。

如果您已经读到这里，我的问题是：根据此分析信息，如何提高自定义深度着色器在 iOS 设备上的渲染性能？

Answer 1

根据 Tommy、Pivo​​t 和 rotoglup 的建议，我实施了一些优化，使应用程序中深度纹理生成和整体渲染管道的渲染速度提高了一倍。

首先，我重新启用了之前使用的预先计算的球体深度和照明纹理，效果甚微，只是现在在处理该纹理的颜色和其他值时使用正确的 lowp 精度值。这种组合，再加上适当的纹理贴图，似乎可以带来约 10% 的性能提升。

更重要的是，我现在在渲染深度纹理和最终的光线追踪冒名顶替者之前进行一次传递，在其中放置一些不透明的几何体来阻止永远不会渲染的像素。为此，我启用深度测试，然后使用简单的不透明着色器绘制出构成场景中对象的正方形，并按 sqrt(2) / 2 缩小。这将创建覆盖所表示球体中已知不透明区域的嵌入正方形。

然后，我使用 glDepthMask(GL_FALSE) 禁用深度写入，并在距离用户更近一个半径的位置渲染方形球体冒名顶替者。这使得 iOS 设备中基于图块的延迟渲染硬件能够有效地去除在任何条件下都不会出现在屏幕上的片段，但仍然可以根据每个像素的深度值在可见球体冒名顶替者之间提供平滑的交叉点。这在下面的粗略插图中进行了描述：

在本例中，顶部两个不透明的阻挡方块冒名顶替者不会阻止渲染这些可见对象的任何片段，但它们会阻止最低冒名顶替者的大部分片段。然后，最前面的冒名顶替者可以使用每像素测试来生成平滑的交叉点，而来自后面的冒名顶替者的许多像素不会因渲染而浪费 GPU 周期。

我没有想过禁用深度写入，但在进行最后渲染阶段时保留了深度测试。这是防止冒名顶替者简单地相互堆叠的关键，但仍然使用 PowerVR GPU 中的一些硬件优化。

在我的基准测试中，渲染我上面使用的测试模型每帧的时间为 18 - 35 毫秒，与我之前得到的 35 - 68 毫秒相比，渲染速度几乎翻倍。将同样的不透明几何体预渲染应用于光线跟踪通道可使整体渲染性能提高一倍。

<罢工>
奇怪的是，当我尝试使用内嵌八边形和外接八边形（绘制时应覆盖约 17% 的像素，并且在块片段方面更有效）进一步细化时，性能实际上比使用简单的正方形时更差。在最坏的情况下，Tiler 利用率仍然低于 60%，因此可能较大的几何图形会导致更多的缓存未命中。

编辑（5/31/2011）：

根据 Pivot 的建议，我创建了内接和外接八边形来代替我的矩形，只是我遵循了建议 此处 用于优化光栅化三角形。在之前的测试中，尽管删除了许多不必要的片段并让您更有效地阻止被覆盖的片段，但八边形的性能比正方形差。通过按如下方式调整三角形绘制：

我能够将总体渲染时间平均减少 14%通过从正方形切换到八边形来实现上述优化。现在，深度纹理可在 19 毫秒内生成，偶尔会下降至 2 毫秒，高峰至 35 毫秒。

编辑2（5/31/2011）：

我重新审视了Tommy使用step函数的想法，现在由于八边形我有更少的碎片需要丢弃。这与球体的深度查找纹理相结合，现在在 iPad 1 上为我的测试模型生成深度纹理的平均渲染时间为 2 毫秒。我认为在这个渲染案例中这已经达到了我所希望的效果，并且比我开始的地方有了巨大的进步。对于后代，这是我现在使用的深度着色器：

precision mediump float;

varying mediump vec2 impostorSpaceCoordinate;
varying mediump float normalizedDepth;
varying mediump float adjustedSphereRadius;
varying mediump vec2 depthLookupCoordinate;

uniform lowp sampler2D sphereDepthMap;

const lowp vec3 stepValues = vec3(2.0, 1.0, 0.0);

void main()
{
    lowp vec2 precalculatedDepthAndAlpha = texture2D(sphereDepthMap, depthLookupCoordinate).ra;

    float inCircleMultiplier = step(0.5, precalculatedDepthAndAlpha.g);

    float currentDepthValue = normalizedDepth + adjustedSphereRadius - adjustedSphereRadius * precalculatedDepthAndAlpha.r;

    // Inlined color encoding for the depth values
    currentDepthValue = currentDepthValue * 3.0;

    lowp vec3 intDepthValue = vec3(currentDepthValue) - stepValues;

    gl_FragColor = vec4(1.0 - inCircleMultiplier) + vec4(intDepthValue, inCircleMultiplier);
}

我已经更新了测试示例 这里，如果您希望看到这种新方法与我最初所做的相比的实际效果。

我仍然愿意接受其他建议，但这对于该应用程序来说是一个巨大的进步。

Answer 2

在桌面上，许多早期的可编程设备都是这种情况，虽然它们可以同时处理 8 个或 16 个或任何片段，但它们实际上只有一个程序计数器来容纳大量片段（因为这也意味着只有一个获取/解码单元，并且其他一切之一，只要它们以 8 或 16 像素为单位工作）。因此，最初禁止条件，并且在那之后的一段时间内，如果对一起处理的像素的条件评估返回不同的值，则这些像素将以某种安排在较小的组中进行处理。

尽管 PowerVR 并不明确，但其 应用程序开发建议有一个关于流量控制的部分，并提出了很多关于动态分支的建议，通常只有在结果可以合理预测的情况下才是一个好主意，这让我认为它们处于同一类型的东西。因此，我建议速度差异可能是因为您包含了条件。

作为第一个测试，如果您尝试以下操作会发生什么？

void main()
{
    float distanceFromCenter = length(impostorSpaceCoordinate);

    // the step function doesn't count as a conditional
    float inCircleMultiplier = step(distanceFromCenter, 1.0);

    float calculatedDepth = sqrt(1.0 - distanceFromCenter * distanceFromCenter * inCircleMultiplier);
    mediump float currentDepthValue = normalizedDepth - adjustedSphereRadius * calculatedDepth;

    // Inlined color encoding for the depth values
    float ceiledValue = ceil(currentDepthValue * 765.0) * inCircleMultiplier;

    vec3 intDepthValue = (vec3(ceiledValue) * scaleDownFactor) - (stepValues * inCircleMultiplier);

     // use the result of the step to combine results
    gl_FragColor = vec4(1.0 - inCircleMultiplier) + vec4(intDepthValue, inCircleMultiplier);

}

Answer 3

其中许多要点已被其他发布答案的人涵盖，但这里的首要主题是您的渲染做了很多将被丢弃的工作：

1. 着色器本身做了一些潜在的冗余工作。< /strong> 向量的长度可能被计算为 sqrt(dot(向量, 矢量))。您不需要开方来拒绝圆之外的片段，并且无论如何，您都可以通过对长度进行平方来计算深度。此外，您是否考虑过深度值的显式量化是否实际上是必要的，或者您是否可以仅使用帧缓冲区的硬件从浮点到整数的转换（可能带有额外的偏差以确保您的准-深度测试稍后就会出来）？

2. 许多片段都在圆之外。只有您正在绘制的四边形面积的 π/4 才能产生有用的深度值。此时，我认为您的应用程序严重偏向于片段处理，因此您可能需要考虑增加绘制的顶点数量，以换取必须着色的区域的减少。由于您是通过正交投影绘制球体，因此任何外接正多边形都可以，但根据缩放级别，您可能需要一点额外的尺寸，以确保光栅化足够的像素。

3. 许多片段被其他片段轻微遮挡。正如其他人指出的那样，您没有使用硬件深度测试，因此没有充分利用 TBDR 尽早终止着色工作的能力。如果您已经实现了 2) 的某些内容，那么您所需要做的就是在您可以生成的最大深度处绘制一个内接正多边形（穿过球体中间的平面），并在最小深度处绘制您的真实多边形（球体的前面）。 Tommy 和 rotoglup 的帖子都已包含状态向量细节。

请注意，2) 和 3) 也适用于您的光线追踪着色器。

Answer 4

我根本不是移动平台专家，但我认为让您感到困扰的是：

• 您的深度着色器非常昂贵，
• 当您禁用 GL_DEPTH 测试时，您的深度通道会出现大量透支，

不需要额外的测试吗？通过，在深度测试之前绘制有帮助吗？

此通道可以进行 GL_DEPTH 预填充，例如通过绘制表示为四面相机（或立方体，可能更容易设置）的每个球体，并将其包含在关联的球体中。此通道可以在没有颜色遮罩或片段着色器的情况下绘制，只需启用 GL_DEPTH_TEST 和 glDepthMask 即可。在桌面平台上，此类通道的绘制速度比颜色+深度通道更快。

然后在深度计算过程中，您可以启用GL_DEPTH_TEST并禁用glDepthMask，这样您的着色器就不会在被较近的几何体隐藏的像素上执行。

该解决方案将涉及发出另一组绘制调用，因此这可能没有好处。