Jump to content
  • Advertisement
Sign in to follow this  
Kario

OpenGL OpenGL slowdown with multiple apps

This topic is 2807 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have the following problem with my Application. We build a OpenGL Application that at some point has to run other child App that also uses OpenGL. The problem is if the master App allocated too much memory for textures the child App starts to run very slowly even is the master App frees textures before launching the child App.
While the child App renders (real-time) the master App does nothing and just idles, it does not make any OpenGL calls. I have been struggling with this problem for quite some time now and still has no answer to why nvidia driver:
- does not free up memory for child App when master App frees textures.
- does not simply unload textures that are not currently used by master App and make some room for textures that are frequently used (this seems like a such an obvious and simple optimization).
It is only after I close the master App and resize the child App windows that child App starts to run at normal speed.

Share this post


Link to post
Share on other sites
Advertisement
How are your freeing your textures? Make sure you call glFlush after deleting your textures (and maybe glFinish), before you start your child app.

Is this on Windows or some other platform?

If the master app really doesn't need to draw anything, you could also try freeing the gl context of the master app before starting the child app.

-Chris

Share this post


Link to post
Share on other sites

How are your freeing your textures? Make sure you call glFlush after deleting your textures (and maybe glFinish), before you start your child app.

Is this on Windows or some other platform?

If the master app really doesn't need to draw anything, you could also try freeing the gl context of the master app before starting the child app.

-Chris


Thanks for the reply.
This is Windows. It has been tested on XP/Vista/Windows 7. On Windows 7 I get some more wired behaviour. Its a CAD App and in windows 7 when the App starts, vewports get screwed up, just like one viewport would receive other viewport's back buffer on SwapBuffers () and it runs very slowly. Than after a few renders (must be intensive, lots of geometry) it just starts to work fine and fast and no problem with viewports - very strange.

glFlush does not work. It's already there. I free textures with glDeleteTextures () call and I can observer memory footprint go down ~250MB as I do this with a specific test case I use for this problem.
My theory is that the card's memory gets fragmented and new frame buffer no longer fits. The driver does not defragment memory or swap textures vs frame memory data just only textures vs textures. But this is my theory.

There is one more thing thay might be relevant. On Windows XP (this is not tested on other systems) I can observer that the master App takes up 100% CPU when in idle. This happens when a few glDrawElements () calls are made. The driver seems to start a thread and eat up CPU (but with a low priority). When glDrawElements calls are replaced with a classic glBegin () / glEnd () this does not happen. When few frames (to viewports) are renderer with very little load the strange thread seems to go away. It does not go away or does not stop using CPU when App idles.

Share this post


Link to post
Share on other sites
You could try pre-allocating a texture at least as big as the framebuffer you need in your second app, at the start of your first app, then delete it right before you start the child app. Maybe that will give it the contiguous space it needs. Note, however, that for the video card to actually upload the texture, you may need to draw with it at least once (maybe every once in a while, even). But if you're running into this problem, maybe you're already starved for vram, and you can't afford to allocate the framebuffer.

Does this happen on both nvidia and ati? Are your video card drivers up to date on all machines?

Share this post


Link to post
Share on other sites
Just tested this on ATI - the same behavior. However this does not happen on laptops as that does not have specific video memory but share memory between GPU and CPU.
I really need to test this with other applications. Any suggestion for OpenGL CAD App that I can try for free ?

Share this post


Link to post
Share on other sites
Hrm, can't say that I know of any.

At this point, it's probably worth setting up perfhud, and using that to get more information.
http://developer.nvidia.com/object/nvperfhud_home.html

Share this post


Link to post
Share on other sites
Some more observations:
- gdebugger does not tell me more that I already know - I'm out of v-ram.
- I use one gl context per app.
- When I launch child app first that the master app - both run fast.
- When the slowdown occurse child app has >no< tetxures resident ! That stay that way and are not put resident vs parent App textures - why ?
- When I use AA configured from nVidia Panel 8AA causes this to happed. When child app uses wglChoosePixelFormatARB this happen with only 2AA settings (even with driver overriding app settings) - it seems that creating a windows and that killing it (for pixel format test) takes up v-ram permanently !

I'm starting to think that this is just some windows inability to effectively manage vram memory and the only way to solve this is to go around this problem and limit vram consumption per app.
I just cant understand how it is that currently unused resources stay in vram and couse resource problems, and even deallocating them cant help (a linear per app buffer in vram that cannot be restructured or even shrinked if unused ??). Those kind of issues has been resolved ages ago with virtual memory for CPU.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!