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 5 of 5

Thread: Render performance to GBuffer

  1. #1
    Newbie Newbie
    Join Date
    Feb 2014
    Posts
    2

    Render performance to GBuffer

    Hi,
    I am working on a deferred renderer for some time now, and i'm down to performance improvement part.
    I have a model that has 36 meshes summing about 74000 faces, The geometry is rendered as VBOs into GBuffer and i get around 1 ms in result for rendering only the geometry (using a Geforce GT 440 on Linux).
    Now my question is: does anyone have experience with this, and can tell me if this is about the best you can get? it is very hard to benchmark and compare to others and the easiest answer can come from experience i guess.

    I know i really should be doing profiling my opengl calls but it is all a real hassle since i'm working on linux and i just want to know if there is a big difference with what someone has already worked on.

    Thanks in advance
    Last edited by siamac; 02-27-2014 at 07:03 PM. Reason: typo

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,336
    You can do a fair amount of basic "kick the tires" tests without even touching the code. First, it doesn't look like you are triangle setup bound. Even if you have the slower version of a GT440, it should be capable of rasterizing around 594,000 tris/ms, so you're only getting around 10% of that rate.

    Next, resize your window a little. Do you see an improvement with small reductions in window size and worse performance if you resize the window a little larger? If so, then you're at least partially fill-bound. You can find this out a number of other ways (with code changes though), such as drawing the same number of tris but drawing them smaller, reducing the number of G-buffer channels you're writing to, etc.

    Are you doing any state changes between drawing these faces? If so, you're at the mercy of your CPU and its speed there. Comment these out, and check the timing. Also to make sure you're profiling just G-buffer rasterization time, ensure your timer starts after G-buffer binding and basic setup has been started and you've done a glFinish. And before you stop your timer, ensure you've done a glFinish(), otherwise you may not be timing what you think you're timing.

  3. #3
    Newbie Newbie
    Join Date
    Feb 2014
    Posts
    2
    Quote Originally Posted by Dark Photon View Post
    Also to make sure you're profiling just G-buffer rasterization time, ensure your timer starts after G-buffer binding and basic setup has been started and you've done a glFinish. And before you stop your timer, ensure you've done a glFinish(), otherwise you may not be timing what you think you're timing.
    Thanks for the replay. i wasn't calling glFinish for correct timings, but now i see that the resterization is even slower , 1.5 ms
    the timer is now working this way:

    //all bindings/state changes
    glFinish()
    StartTimer();
    DrawElements()
    glFinish();
    EndTimer();

    my shader for this test is just outputting 3 channels with positin/normal/diffuse(white) and no effects. I have tried both directly outputting the position to a 16f frame buffer without packing, and a also packing only the view distance to a 32bit framebuffer and while using a 32bit framebuffer is faster in general, but the number of channels and data size doesn't really affect the Gbuffer rasterization time that much.

    I guess it could also be a driver problem on linux, i will test the timings on windows and repost if that is the case for future reference for others.

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    989
    You measure CPU time. That has little to do with the time required for the GPU to render your stuff. You want to use ARB_timer_query to measure actual rendering time on the GPU.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,336
    Quote Originally Posted by aqnuep View Post
    You measure CPU time. That has little to do with the time required for the GPU to render your stuff. You want to use ARB_timer_query to measure actual rendering time on the GPU.
    ARB_timer_query is useful if you know for sure that you are GPU limited. If you don't, it's best to start with CPU timers IMO, as what you end up getting from the GPU timers in this case is useless.

    Could be there's a trick I don't know about though, so please provide tips if you know what I'm talking about.
    Last edited by Dark Photon; 03-02-2014 at 01:36 PM.

Posting Permissions

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