Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: Performance problem: Few big geometries vs many small geometries

  1. #1
    Intern Contributor
    Join Date
    Sep 2013
    Posts
    81

    Performance problem: Few big geometries vs many small geometries

    Hi there.
    I was just playing around with my application and rendering different meshes just to see the differences in performance when I noticed something curious:
    First, I wanted to try to draw so many triangles on screen that my frame rate dropped below 60. I created a Display of size 1024x1024 and I put a single quad (consisting of 2 triangles) for each pixel.
    That is 1 048 576 quads. And each of them had 4 floats vertex data, 4 floats texture coordinates and 4 floats for a multiplicative color. Each quad had a size of just 1 pixel in width and height.
    Frame rate did still not drop below 60. I was quite pleased.

    But then I tried something different. I tried to render just 100 quads (still 2 triangles per quad) but each quad was 1024x1024 in size. Still the same shader, the same texture and everything else was also the same.
    However, my frame rate dropped below 60 now and was around 48 to 52 and pending.
    I am completely baffled by that. I would have guessed that those millions of triangles would be much more work then just a 100 big quads. How can this be? Is this normal?

    I was using VBO's by the way with glDrawElements.

    Thank you all for your help.

  2. #2
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    315
    In the first case, you're drawing 1 million fragments. In the second, you're drawing 100 million fragments (and change). Since neither case is likely to be vertex processing bound, how you're drawing the quads isn't affecting things much. But overdrawing pixels by a factor of 100, that's pretty expensive.

  3. #3
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    24
    When a fragment is drawn, there is somewhere a synchronisation point to access in write mode to this pixel in the render buffer.

    In the second case, a lot of pixels (1024x1024) are written 100 times. This leads to a lot of concurrent access, and the different fragment processing threads have to wait.

  4. #4
    Intern Contributor
    Join Date
    Sep 2013
    Posts
    81
    That makes sense.
    But I originally thought the overhead of drawing 2 000 000 tiny triangles would be much larger. Guess I was wrong.

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,182
    Quote Originally Posted by Cornix View Post
    That makes sense.
    But I originally thought the overhead of drawing 2 000 000 tiny triangles would be much larger. Guess I was wrong.
    Depends how you draw the triangles. If you make 2,000,000 draw calls you'll see the overhead alright, but if you draw all of them in a single call then you're really just talking about some extra vertex processing and bandwidth, and these are not huge numbers for modern GPUs.

  6. #6
    Intern Contributor
    Join Date
    Sep 2013
    Posts
    81
    Well then, thank you all for the quick responses.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •