Results 1 to 6 of 6

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

  1. #1
    Senior Member Regular Contributor
    Join Date
    Sep 2013
    Posts
    186

    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
    Senior Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    369
    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
    Senior Member Regular Contributor
    Join Date
    Sep 2013
    Posts
    186
    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
    Newbie OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789
    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
    Senior Member Regular Contributor
    Join Date
    Sep 2013
    Posts
    186
    Well then, thank you all for the quick responses.

Similar Threads

  1. Best Way to Texture Merged Geometries?
    By spectral in forum OpenGL: Basic Coding
    Replies: 1
    Last Post: 11-20-2017, 02:25 AM
  2. Graphics disappear under certain geometries.
    By JamesDean in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 06-27-2014, 11:22 AM
  3. collada, sketchup and geometries
    By ben530 in forum COLLADA
    Replies: 0
    Last Post: 04-01-2014, 04:57 AM
  4. Performance problem with a small voxel engine
    By lorant in forum OpenGL: Advanced Coding
    Replies: 28
    Last Post: 11-15-2011, 01:15 PM
  5. A small problem, please help me...
    By Zhang Yan in forum OpenGL: Basic Coding
    Replies: 3
    Last Post: 10-23-2001, 01:16 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean