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.

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.

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 ?

use gdebugger and check the memory for both apps if you can.

Do you have a GL context for each window? Are you sharing resources with wglShareLists?

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.