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

Thread: Poor First Run Performance

  1. #1
    Intern Contributor
    Join Date
    May 2008
    Posts
    99

    Poor First Run Performance

    When I start my application for the first time after a reboot, I get poor performance and the Nvidia driver reports 250+ MB of evicted memory. However, if I kill my app and restart, then the performance is much better and the driver doesn't report any memory eviction. But, there is only 1.5 MB free on the GPU. Both runs are identical.

    I tried removing the on-disk shader cache, but subsequent runs were still ok.

    Obviously, I have to fix the memory eviction, but I wonder why the first run is different from subsequent runs. Is the driver caching a file that gives it memory information about my app? Is there anything else that could explain this?

    Thanks.

  2. #2
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    I cannot help myself but post this: This really sounds clever.
    Sorry - no idea...

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,188
    Quote Originally Posted by ViolentHamster View Post
    Obviously, I have to fix the memory eviction, but I wonder why the first run is different from subsequent runs.
    Hmm... Not sure if the shader cache thing is related here, though it might be. If so, maybe its causing a different timing and a different ordering of GL operations (?) The first run it's going to take longer because the disk cache is cold.

    What happens if before the first run you forceably read the on-disk shader cache into the memory cache. For instance, on UNIX/Linux, assuming sh/bash and that you haven't relocated where your shader/kernel caches are (you may have, so plug in the appropriate path here):

    Code :
    find ~/.nv -type f | xargs cat > /dev/null 2>&1

    Or just disable the shader cache to force the same behavior every time (i.e. slow recompiliation and reoptimization).

    Also, related to the memory overrun scenario, might validate that you're creating all your big framebuffer and renderbuffers first, and that these are not being freed and recreated later, potentially creating odd-sized holes to fill.

  4. #4
    Intern Contributor
    Join Date
    May 2008
    Posts
    99
    Quote Originally Posted by Dark Photon View Post
    Hmm... Not sure if the shader cache thing is related here, though it might be. If so, maybe its causing a different timing and a different ordering of GL operations (?) The first run it's going to take longer because the disk cache is cold.
    That's what it turned out to be. It was shader cache related. When the shader cache is already on disk, apparently the driver can prevent the eviction.

Posting Permissions

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