GLSL 几何着色器的性能出乎意料地变慢答案

【问题标题】：Performance of GLSL geometry shaders unexpectedly slowGLSL 几何着色器的性能出乎意料地变慢
【发布时间】：2012-03-12 15:21:38
【问题描述】：

我正在尝试学习如何编写 GLSL 几何着色器。我的测试项目是这样工作的：我有 N 个 VBO，它们正在建模“草叶”。如果没有着色器，每片草叶基本上只是一条有 20 段的线带。我能够使用几乎 N=10k 刀片或多或少平滑地制作此动画，因此有 200,000 行。

着色器获取每个线段并将其吹出以该线段为中心的相同长度的圆柱体，因此草叶现在是具有维度的管。因此，CPU 没有任何变化，但现在我正尝试利用 GPU 添加更多几何图形，以便为刀片着色。圆柱体有 30 个部分，因此每个刀片有 60 个三角形，1200 个三角形。

问题是，为了让它流畅地动画，我不得不缩减到只有 25 个刀片。那只有 30k 个三角形，这基本上比我之前完全不使用着色器时处理的几何体更少。

这是在 Macbook Pro、Snow Leopard、AMD Radeon HD 6750M 上运行的。不知道这是不是一张好卡。

着色器代码非常简单——顶点着色器只有 gl_Position = gl_Vertex。光照发生在几何着色器中：简单的环境、镜面反射和漫反射组件，基本上直接来自教程。片段着色器同样简单，只是将草的颜色乘以从几何着色器传递过来的光强度。

顺便说一下，这是一个旧版本的 OpenGL，2.1 -- 所以它是 GLSL 1.2，所以要使用地理着色器，它需要 GL_EXT 东西。以防万一。

此外，堆栈是在 Java 之上的 JOGL 之上的 GLGraphics 之上的处理。如果这是一个因素，我会感到惊讶，除非它以某种方式在 CPU 上模拟着色器代码，但我认为 OpenGL 不会自动为你做这种事情。

无论如何，这些数字是否合理，还是我做错了什么？我是否不切实际地期望地理着色器能够创造奇迹？

【问题讨论】：

【解决方案1】：

从来没有人指责几何着色器速度很快。尤其是在增加几何尺寸时。

您的 GS 正在取一条线，不仅对顶点数据进行 30 倍放大，而且还在每个新顶点上进行光照计算。这不会很快，很大程度上是由于缺乏并行性。每个 GS 调用必须进行 60 次光照计算，而不是让 60 个单独的顶点着色器调用并行进行 60 次光照计算。

您基本上是在几何着色器中创建了一个巨大的瓶颈。

将光照材料放入片段着色器可能会更快（是的，真的）。

【讨论】：

这很有趣......自从我了解了地理着色器后，我一直想知道为什么它们没有在顶点着色器之前出现。这看起来更合乎逻辑——首先进行镶嵌，然后在顶点着色器中进行照明，然后转到片段着色器。我只是不确定我是否真的“得到”了几何着色器——它们真正用于/有益于什么。
@eeeeaaii：几何着色器不适用于镶嵌；他们可以做到，但 DX11/GL4.x 专门为曲面细分添加着色器是有原因的。几何着色器用于在每个基元级别上做事。它们的主要用途是分层渲染，您可以将不同的对象渲染到layered render target 的不同层。您还可以将它们用于正常工作的点精灵（剪切到精灵的大小，而不是精灵的中心）。