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

Question

我正在尝试学习如何编程GLSL几何着色器.我的测试项目是这样的:我有N个VBO,它们正在模拟"草叶".如果没有着色器,每片草叶基本上都是一条带有20段的线条.几乎N = 10k刀片,我能够或多或少地平滑动画,这样就可以达到200,000行.

着色器采用每个线段并将其吹出到以该线段为中心的相同长度的圆柱体,因此草叶现在是具有维度的管.因此CPU中没有任何变化,但现在我正在尝试利用GPU来添加更多几何体,以便我可以遮挡刀片.圆柱体有30个截面,因此每个刀片有60个三角形,1200个三角形.

问题是,为了让它顺利进行动画,我不得不缩小到只有25个刀片.这只是30k三角形,基本上比我之前处理时没有使用着色器时的LESS几何形状.

这是在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会自动为你做这种事情.

无论如何,这些数字看起来是否合理,或者我做错了什么？我不切实际地期望地理着色器能够创造奇迹吗？

Answer 1

没有人指责几何着色器是快速的.特别是在增加几何尺寸时.

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

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

将照明内容放入片段着色器可能会更快(是的,真的).