• Advertisement

Volzotan

Member
  • Content count

    3
  • Joined

  • Last visited

Community Reputation

106 Neutral

About Volzotan

  • Rank
    Newbie
  1. Okay, here's a first result. Rendering with 77% of the triangles (by ignoring the last 23%, which are degenerate) gave me 110 fps instead of 90 fps (which I get if I render 100% of the triangles). So yes, there's indeed a speedup.   However, I still have to compare that particular example against the cache-optimized alternative mhagain also mentioned.
  2. Hey, thanks for your quick and detailed replies!       I'm not going to do such fancy things. Please excuse me for not being able to go into detail here, but let me clarify this a little bit:   The situation is simply that we know beforehand that, for our particular case, after a certain transformation in the vertex shader, we have - let's say - 50% of the triangles being degenerate, and at the same time being located at the back of our vertex and index buffers. So we could just ignore them in our drawcall, with actually zero overhead.   Of course, having the data re-organized this way (only once, during preprocessing!) instead of ordering it with a cache optimizer implies a certain overhead itself, as it potentially limits cache performance.   Please let us also assume that our application is vertex bound, e.g. because we have a large laser-scanned model, which is tesselated very regularly with many small triangles, and we use a moderately-sized viewport, instead of having a high-resolution viewport and optimized low-poly game models.   So, if I get you right, I can still expect a performance gain (-> vertex bound, 50% less vertex processing) by limiting my draw call to non-degenerate triangles, but in order to evaluate whether it's worth the effort, I have to compare my method with its re-organized data layout against a cache-optimized variant that renders all triangles and uses the GPU to discard degenerate ones, right? :-)
  3. Hi everyone,   I have been wondering how big the overhead of using degenerate triangles with indexed triangle lists is.   I've been asking around at NVIDIA DevZone, but not getting any reply:   https://devtalk.nvidia.com/default/topic/534530/general-graphics-programming/overhead-for-degenerate-triangles/?offset=2#3761674   I also saw that old GD thread, which was interesting, but did not give me a definite answer:   http://www.gamedev.net/topic/221281-render-cost-of-degenerate-triangles/     The situation is the following: - Render a list of indexed triangles - Do some fancy stuff in a vertex shader - After the vertex shader, some vertices will be located at the same world position, meaning there will be some degenerate tris     My Question: Assume I would know beforehand which triangles will become degenerate, and I could exclude them from rendering. How big do you think would the speedup be in that case?   Please note that the indices of the corresponding joint vertices might still be different, so the GPU should not be able to discard triangles before the vertex processing stage, meaning that it still has to transform each vertex before finding out which triangle is degenerate. BTW, does the GPU realize this at all in that case? Does anyone have a reference where some GPU manufacturer has explained how the filtering of degenerate triangles works, and when it is applied?   Any help is appreciated. Thanks a lot in advance!   Best,   Volzotan        
  • Advertisement