Return to Answer

Here is a basic rule of thumb about GS's: never use a GS because you think it will make rendering faster. You should use it when it makes what you're trying to do possible. If what you're trying to do is an optimization, use something else.

For more information about GS-induced slowdowns, read this article.

Here is a basic rule of thumb about GS's: never use a GS because you think it will make rendering faster. You should use it when it makes what you're trying to do possible. If what you're trying to do is an optimization, use something else.

In order for OpenGL to execute a geometry shader, it must perform what is known as "primitive assembly". When you render a series of triangles via GL_TRIANGLE_STRIP, OpenGL will do internal stuff to convert every 3 adjacent vertices into an individual triangle, modifying the winding order appropriately.

Each index from an element array buffer will produce the same outputs from a vertex shader. So the GPU will often cache these outputs in a post-T&L cache. If it sees an index that is already in the cache, the VS is not run again; it just fetches data from the cache.

Adding to this is the fact that many GL 3.x-class GPUs (aka: DX10) had rather small post-GS buffers. The smaller the buffer, the fewer GS invocations you can have active simultaneously. So your hardware effectively bottlenecks on the GS. Because tessellation is a big feature of 4.x class hardware, most such hardware has buffers sufficient to make heavier GS use viable.

• Point-sprites. Maybe, if you're careful about your output data size.
• Layered rendering. And as for layered rendering, consider that AMD came up with an extension who's whole purpose is to allow the VS to cover most of the layered rendering duties.
• Setup for Transform Feedback operations, particularly multiple streams. But that's GL 4.x stuff there.

In order for OpenGL to execute a geometry shader, it must perform what is known as "primitive assembly". When you render a series of triangles via GL_TRIANGLE_STRIP, OpenGL will do internal stuff to convert every 3 adjacent vertices into an individual triangle, modifying the winding order appropriately.

Each index from an element array buffer will produce the same outputs from a vertex shader. So the GPU will often cache these outputs in a post-T&L cache. If it sees an index that is already in the cache, the VS is not run again; it just fetches data from the cache.

Adding to this is the fact that many GL 3.x-class GPUs (aka: DX10) had rather small post-GS buffers. The smaller the buffer, the fewer GS invocations you can have active simultaneously. So your hardware effectively bottlenecks on the GS. Because tessellation is a big feature of 4.x class hardware, most such hardware has buffers sufficient to make heavier GS use viable.

• Point-sprites, mainly to get around size limits and clipping problems. Maybe, if you're careful about your output data size.
• Layered rendering. NVIDIA even has an extension who's defining purpose is to effectively strip a GS of the ability to do anything except layered rendering. Plus, consider that AMD came up with an extension who's whole purpose is to allow the VS to cover most of the layered rendering duties. Which is now an ARB extension.
• Setup for Transform Feedback operations, particularly multiple streams. But thanks to compute shaders in GL 4, you don't really need that very often.

Normally, when not using a GS, this process is performed once. When you use a GS however, it must be performed before the GS executes. But it must also be performed after the GS, because a GS can output a totally different primitive type (e.g. quads). So now you're making the system basically do a bunch of extra work for nothing. After all, OpenGL can't assume that your GS is doing nothing.

Normally, when not using a GS, this process is performed once. When you use a GS however, it must be performed before the GS executes. But it must also be performed after the GS, because a GS can output a totally different primitive type (e.g. quads).