Jump to content

  • Log In with Google      Sign In   
  • Create Account

Geometry Shader for a quad or not ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Alundra   Members   -  Reputation: 924

Like
0Likes
Like

Posted 16 May 2014 - 09:13 PM

Hi all,

I would add a Billboard component for Actor who is just a render of a quad with a texture oriented with the camera.

Is it better to send a point and generate the quad using geometry shader or directly send a static buffer + matrix ?

Thanks



Sponsor:

#2 Ohforf sake   Members   -  Reputation: 1832

Like
0Likes
Like

Posted 17 May 2014 - 01:47 AM

If you want to draw multiple actors like that, in a single draw call, then you will probably store the per actor data (position, texture frame, ...) in the vertex buffer. In that case, if you provide the quads directly, you will have to duplicate that data 4 times.
Thus I would suggest either geometry shader (send points and expand them to quads) or instancing. Instancing a quad multiple times would give you the same end result, but be more flexible if you need more complicated shapes then quads in the future.

#3 Buckeye   Crossbones+   -  Reputation: 6287

Like
0Likes
Like

Posted 17 May 2014 - 07:29 AM


Instancing a quad multiple times would give you the same end result, but be more flexible if you need more complicated shapes then quads in the future.

For purposes of flexibility, I would think rather the other way 'round. If you want the option of different (run-time selectable) billboard shapes, you can maintain just a point-list and a GS with routines for various shapes to be chosen by a flag. Seems that would be more efficient that changing the shape CPU-side.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#4 Tasty Texel   Members   -  Reputation: 1359

Like
1Likes
Like

Posted 17 May 2014 - 01:26 PM

On my Intel HD Graphics 3000 thingy extracting quads from points is about twice as fast as instancing quads.



#5 theagentd   Members   -  Reputation: 602

Like
0Likes
Like

Posted 18 May 2014 - 07:41 AM

I also have experience where instancing is slower than geometry shaders.



#6 ATEFred   Members   -  Reputation: 1125

Like
0Likes
Like

Posted 18 May 2014 - 08:32 AM

It does depend heavily on HW. ATI gave a presentation at gdc this year that showed that on their hw using the GS was somewhat slower than calling DrawInstanced with 4 verts per quad and doing the work in the VS instead, whereas on recent NV hw it was pretty much the same.



#7 mhagain   Crossbones+   -  Reputation: 8276

Like
9Likes
Like

Posted 18 May 2014 - 09:03 AM

The thing here is that you're only measuring the front-end of the graphics pipeline instead of doing a proper end-to-end measurement.  So you count the number of vertices you have, you see that you can cut them to a quarter, you think that this should be a huge win, but all too often it isn't.

 

There's a LOT of stuff that goes on beyond mere vertex submission and just measuring number of vertices and expecting that to be a primary determinator of performance is a case of ignoring all of the other stuff.

 

For, say, a quad that occupies a 64x64 region of the screen, you have 4 vertices but 4096 pixels/fragments.  That alone should tell you that the pixel/fragment side is where the real gains are to be made.

 

In the case of the GS stage, just having it active with nothing more than a simple pass-through shader will give you a 5% to 20% performance hit.  So you need to be absolutely certain that the operations you're doing in there (specifically moving per-vertex work to per-primitive) are going to give you back more than 5% to 20% in order for it to be viable.  And as I've discussed above, the vertex overhead is going to be so low that this is hugely unlikely in your use case.

 

The exception is cases where you absolutely must use the GS, such as multiple viewports, stream out, adjacency, calculating normals, or anything else that needs to operate on an entire primitive.  That's where the GS is useful.  But using it to generate additional vertices on the fly - not so much.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#8 Buckeye   Crossbones+   -  Reputation: 6287

Like
0Likes
Like

Posted 18 May 2014 - 09:14 AM

@mhagain - you make some excellent observations. Converting a pointlist to the desired billboard shape CPU-side once, rather than each render, may be a better option.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#9 mhagain   Crossbones+   -  Reputation: 8276

Like
1Likes
Like

Posted 18 May 2014 - 03:12 PM

@mhagain - you make some excellent observations. Converting a pointlist to the desired billboard shape CPU-side once, rather than each render, may be a better option.

 

I would say diifferent.  Unless the OP has some kind of weird pathological case, this is going to be down in the noise on any performance graph, no matter which is used.  As a general rule vertex submission for sprite quads is strictly in "don't sweat the small stuff" territory.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS