PDA

View Full Version : geometry-shader .. just, how slow?



CarstenT
04-24-2014, 10:41 AM
Hi all,
My first 3d was terrain-data. Pretty easy, all things considered. To cope with the excessive data I tried to involve the geometry-shader. The framerate dropped to 20-30 % by just using the pass-through shader. Is that standard or should I expect far better performance .. perhaps in particular favourable circumstances? The shader sparks my imagination, but not at that performance-price!
Cheers

Aleksandar
04-24-2014, 12:29 PM
Maybe this thread (https://www.opengl.org/discussion_boards/showthread.php/181179-Geometry-shader-a-threat-for-high-performance) is a good start. :)
I had a very bad experience with GS. What do you actually want to achieve?

tonyo_au
04-24-2014, 05:18 PM
I only use GS in 2 cases.

1) rendering various icons for points like diamond/square/plus/cross but I notice the speed hit and am thinking of changing it to do the work in the vertex shader using instancing

2) the other is to save render passes on tins (terrain) geometry where I want to overlay grids and contour lines. My main win hear is in avoiding z-buffer fighting and I am about as fast with using GS as the extra draw passes.

I am not convinced using GS to discard geometry is actually quicker than using the cpu to rebuild the index buffer particularly with storage buffers

mhagain
04-25-2014, 11:35 AM
I haven't extensively used a GS in OpenGL, but in D3D having the stage active with just a pass-through shader gives maybe a 5% to 10% hit.

I'm personally satisfied that it's a non-feature for what most people seem to want to use it for, which is point-to-quad expansion in a particle system, or other similar primitive expansion/decimation scheme.

The main things I've used the GS for include:



Shadow volume extrusion (although I haven't compared this with a pure CPU solution as I was late to the party with shadow volumes).
Generating per-triangle normals on the fly (my vertex format was already bloated, and these normals were only used in one specific rendering pass).
Generating extra sets of texcoords for detail texturing (where triangle orientation matters).
Collapsing an expensive once-per-vertex operation to a cheaper once-per-triangle operation.


In other words I don't see much value in it for adding or removing vertices/triangles (aside from shadow volumes where it seems that it can save you a lot of work on the CPU, and is friendlier for static vertex buffers), but it's quite useful for anything that needs to operate on (and have knowledge of) an entire primitive, and even then you need to be careful that the saving you get is greater than what you lose from just having the GS stage active.

Dark Photon
04-25-2014, 04:14 PM
Geometry shader can yield some pretty impressive speedups in some circumstances. For instance:

* Instance culling using geometry shaders (http://rastergrid.com/blog/2010/02/instance-culling-using-geometry-shaders/) (rastergrid)
* GPU based dynamic geometry LOD (http://rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/)

(adapted to use modern transform feedback techniques which avoid readbacks/synchronization/etc. of course). But still I would echo the above comments: bench it w/ and w/o a geometry shader to make sure it's really faster than the alternative.

CarstenT
04-26-2014, 01:00 AM
Thanks for the input. The performance-penalty was not a fig of my imagination then. Alexandar, it's not so much a particular task, but rather a potential for problem-solving in general. As a newb I'm not at all tied to conventional ways of solving anything.