Jump to content

  • Log In with Google      Sign In   
  • Create Account


Geometry Shaders


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 dpadam450   Members   -  Reputation: 842

Like
0Likes
Like

Posted 05 March 2014 - 03:39 PM

I think I have found a use for geometry shaders now. My question is:

I have a model of triangles: I Draw it.

I have a model of triangles, that goes through a geometry shader that spits out the same exact triangles as is from step 1.

Is this much/any slower than simply drawing the model? Is there a big overhead? I simply want to add a check before a triangle gets transformed, so that certain triangles never hit the vertex shader. But I don't know if it is too much overhead even to have the most basic geometry shader, that takes in a triangle and simply spits out the same one.

Is that even possible to discard triangles in a geometry shader?


Edited by dpadam450, 05 March 2014 - 03:40 PM.


Sponsor:

#2 mark ds   Members   -  Reputation: 1073

Like
2Likes
Like

Posted 05 March 2014 - 04:17 PM

I simply want to add a check before a triangle gets transformed, so that certain triangles never hit the vertex shader.

 If I'm understanding your intentions correctly, the geometry shader comes after the vertex shader - not before it - so you can't use it to cull triangles based on some arbitrary check.



#3 DaBono   Members   -  Reputation: 926

Like
2Likes
Like

Posted 05 March 2014 - 04:31 PM

As mark ds says, the geometry shader runs after the vertex shader.

 

If I understand correctly you want to do some checking before running them through an expensive vertex shader, am I right?

 

I think you'd have to use a trivial vertex shader, use your geometry shader to check which triangles should be culled, and store the triangles that pass the test in the transform feedback buffer. You can then use that buffer as input to your expensive vertex shader and run the rest of the pipeline.



#4 dpadam450   Members   -  Reputation: 842

Like
0Likes
Like

Posted 05 March 2014 - 05:30 PM

Ah thats right. Never used geometry shaders.



#5 cgrant   Members   -  Reputation: 538

Like
0Likes
Like

Posted 05 March 2014 - 08:37 PM

Being that the GS comes after the VS shader and takes primitives as input, it can be used for culling in a general sense. In your use case, you want to cull primitives before they are transformed, which like many already pointed out, a geometry shader won't work for that purpose, unless you are doing the actual transformation in the geometry shader. However, I don't think this approach will give you whatever performance increase you are looking for. You will need to profile you application to see where the bottleneck is before attempting any form of optimization.



#6 spacerat   Members   -  Reputation: 713

Like
-1Likes
Like

Posted 05 March 2014 - 08:53 PM

Edit / @mhagain: 

 

I apologize. didnt read the question carefully.

 

Still i believe that here is an performance impact on using geometry shaders as it costs additional computations.


Edited by spacerat, 06 March 2014 - 03:46 AM.


#7 mhagain   Crossbones+   -  Reputation: 7442

Like
0Likes
Like

Posted 06 March 2014 - 02:33 AM

>>Is this much/any slower than simply drawing the model? Is there a big overhead? 

 

Yes, it is significantly slower than using static VBO in terms of triangles per second as the tessellation needs also GPU power.

But since you can get a dynamic tessellation per triangle, you might have a same or better overall performance for the same appearance of the scene.

 

You can download this simple sample and play with it to see how it works and whats possible.

 

This question is nothing to do with tesselation.


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 dpadam450   Members   -  Reputation: 842

Like
0Likes
Like

Posted 06 March 2014 - 10:55 AM

My basic idea was that in order to do back face culling, the triangle points have to hit the vertex shader first to determine which way the triangle faces.

As a GPU optimization, it would be cooler if I could pass in the view vector at a stage before the vertex shader, so that triangles get back face culled with the view vector in the 3d model's space. If the dot product of the face normal with the view vector is negative, that triangle/verts would never hit the vertex shader.

Seems like a pretty good optimization to me, any thoughts?  The only flaw is that triangles are made out of transformed points, so you could see a triangle that has point A, while a back facing triangle is connected to point A as well.



#9 phantom   Moderators   -  Reputation: 6796

Like
1Likes
Like

Posted 07 March 2014 - 05:57 AM

It might be sane, but the problem is as stated there is no stage before the VS that you could do this in; at best you could do a pass through-VS and do the work in the GS but that'll hurt as you'll end up spilling out to gfx memory in and introduce ordering.

 

Amusingly the whole VS->[tess]->GS thing is just an artifact of the way the pipeline was setup; current hardware could, quite happily, put a 'GS'-like stage first to operate on a primitive (IA is done in ALU cores these days anyway) before the VS/Tess stages... in fact VS wouldn't really be needed at all in that situation as you could test and transform 3 points just fine.

 

In short; the idea might have merit but the way the software pipeline I arranged means that while the hardware could operate in that manner you aren't going to be able to do it.






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