GLSL几何着色器的性能意外降低 [英] Performance of GLSL geometry shaders unexpectedly slow

问题描述

我正在尝试学习如何对GLSL几何着色器进行编程.我的测试项目是这样的:我有N个VBO正在建模草叶".如果没有着色器，则每个草叶基本上只是一个具有20个线段的线带.我几乎可以使用N = 10,000片刀片使动画大致平滑，因此有200,000条线.

I'm trying to learn how to program GLSL Geometry shaders. My test project works like this: I have N VBO's which are modeling "blades of grass". Without the shader, each blade of grass is just basically a line strip with 20 segments. I was able to get this animating more or less smoothly with almost N=10k blades so that's 200,000 lines.

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

The shader takes each line segment and blows it out to a cylinder of the same length centered on that line segment, so the blades of grass are now tubes with dimensionality. So nothing has changed in the CPU, but now I'm trying to leverage the GPU to add more geometry so I can shade the blades. The cylinder has 30 sections so that's 60 triangles, 1200 triangles per blade.

问题是，要使其平滑地动画，我只能缩小到25个刀片.那只有3万个三角形，基本上比以前完全不使用着色器时要处理的几何要少.

The thing is, to get it to animate smoothly I had to scale back to only 25 blades. That's only 30k triangles, which is basically LESS geometry than I was dealing with before when I wasn't using shaders at all.

这是在Macbook Pro，Snow Leopard，AMD Radeon HD 6750M上运行的.不知道那是不是一张好牌.

This is running on a Macbook Pro, Snow Leopard, AMD Radeon HD 6750M. No idea if that's a good card or not.

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

The shader code is pretty simple -- the vertex shader just has gl_Position = gl_Vertex. Lighting is happening in the geometry shader: simple ambient, specular and diffuse components, basically straight out of the tutorials. Fragment shader is similarly simplistic, just multiplies the grass color by the light intensity that was passed over from the geometry shader.

顺便说一下，这是OpenGL的旧版本2.1，因此它是GLSL 1.2，因此要使用地理着色器，需要GL_EXT.如果相关的话.

This is an old version of OpenGL by the way, 2.1 -- so it's GLSL 1.2, so to use the geo shader it needs the GL_EXT thingy. In case that's relevant.

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

Also, the stack is Processing on top of GLGraphics on top of JOGL on top of Java. I'd be surprised if that was a factor, unless somehow it's emulating the shader code on the CPU but I didn't think OpenGL did that kind of thing automatically for you.

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

Anyway, do these numbers seem reasonable, or am I doing something wrong? Am I unrealistically expecting geo shaders to work miracles?

推荐答案

没有人曾指责过几何着色器过快.尤其是在增加几何尺寸时.

No one has ever accused Geometry Shaders of being fast. Especially when increasing the size of geometry.

您的GS正在一条直线上，不仅对顶点数据进行了30倍的放大，而且还在这些新顶点的每一个上进行光照计算.这并不是很快，主要是由于缺乏并行性.每个GS调用必须执行 60 个光照计算，而不是有60个单独的顶点着色器调用并行执行60个光照计算.

Your GS is taking a line and not only doing a 30x amplification of vertex data, but also doing lighting computations on each of those new vertices. That's not going to be terribly fast, in large part due to a lack of parallelism. Each GS invocation has to do 60 lighting computations, rather than having 60 separate vertex shader invocations doing 60 lighting computations in parallel.

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

You're basically creating a giant bottleneck in your geometry shader.

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

It would probably be faster to put the lighting stuff in the fragment shader (yes, really).

这篇关于GLSL几何着色器的性能意外降低的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！