0
\$\begingroup\$

I just set up some simple vertex/fragment shaders for handling lighting instead of using the openGL calls. I have a few terrain VBOs setup that are drawing a million or so triangles for testing (bunch of random spikey ground). I noticed that if make the spikey ground spikes higher by multiplying all of their heights by 5, I see the FPS drop from about 98hz to about 44hz.

Searching the web, I found https://www.khronos.org/opengl/wiki/Performance which says "Fragment processing takes longer for large polygons than for small ones", which would explain why I see the decrease.

However, I can't find anything that says why. So my question is, why does fragment processing time vary based on the size of the polygons?

\$\endgroup\$
1
\$\begingroup\$

"The fragment shader is the OpenGL pipeline stage after a primitive is rasterized. For each sample of the pixels covered by a primitive, a "fragment" is generated." opengl wiki

Therefore the larger the polygon (actually the larger the rasterized primitive corresponding to that polygon) the more pixels you need to process...

\$\endgroup\$
  • \$\begingroup\$ But if I have terrain covering the entire view in both cases, shouldn't it be processing the same number of pixels, thus doing the same amount of work in both cases? \$\endgroup\$ – Dtor Jan 8 '17 at 21:50
  • \$\begingroup\$ one pixel can be covered by many overlapping primitives (e.g. for blending etc). Spikey landscapes will increase the likelihood of these overlapping fragments. \$\endgroup\$ – Biggy Smith Jan 8 '17 at 22:04
  • \$\begingroup\$ Ok got it. I was thinking the fragment processing didn't happen until after everything was drawn, so depth test would have removed fragments that were occluded before they were processed. Looks like that is not true. Thanks! \$\endgroup\$ – Dtor Jan 8 '17 at 22:17
  • 1
    \$\begingroup\$ @Dtor You can simulate that behavior (and possibly improve performance) by rendering the geometry twice: In the first pass, disable color write and render only the depth. This tends to be very fast since the fragment shader in most cases does not need to run at all. The second pass then renders the same geometry again, but with a regular shader, depth write disabled and depth test set to equal. That ensures that no occluded fragments are processed in this pass. This technique is often called Z-Prepass if you want to read more about it. \$\endgroup\$ – Quinchilion Jan 9 '17 at 1:19
  • \$\begingroup\$ @Quinchilion that sounds useful, I'll have to look into it. Is it something that people typically do? Or is not used much due to having to draw twice or portability or something that leads to ordering the draw calls being better? \$\endgroup\$ – Dtor Jan 9 '17 at 3:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.