I’m facing a little problem when running programs that use the wglMakeCurrent() function repeatedly (i.e. in junction with a pbuffer).
If I watch the processes list of the Windows Task Manager, it shows me an continuously increasing memory usage of a running program that uses the wglMakeCurrent() function!
After I’ve removed the calls to wglMakeCurrent() this increase disappeared.
I’ve tested this with my own program and some other and even the EMBM sample from ATI.com shows this behaviour so it is probably not a mistake of my own…
My graphics card is a ATI Radeon 9600Pro and it seems that on Nvidia cards this increase doesn’t happen (tested with a Geforce4 MX420).
Does someone know this problem? Is it a driver related issue?
-Keth
P.S. using wglMakeContextCurrentARB() leads to the same problems
I’d suggest you check for memory leaks using Purify or something similiar, instead of the task manager. If your app passes memory checks using such a tool than don’t worry. If you suspect a memory leak in the driver I guess you could submit a bug report.
If you suspect a driver bug, you SHOULD submit a bug report, and, if possible, a small test program which demonstrates the behavior. The top tier vendors are very responsive to well written bug reports.
…until the window is finally destroyed. Although, I could be wrong. There might be some hidden code in the constructor/destructor for the CClientDC class.
[This message has been edited by gator (edited 02-02-2004).]
Originally posted by Kethvain: No, I allocate the DC once at the start of the app and release it when the app shuts down.
The OpenGL context is tied to the HDC you make it current to, so whenever you want to use OpenGL functions, the HDC you last tied to the RC must be valid.
The HDC you get for a HWND (the one you get from BeginPaint, the one you get from GetDC(), etc) will always be a temporary one (and must be promptly released) unless you registered the window class with the CS_OWNDC class style , which guarantees that the HDC from that window will always be - numerically - the same. As a result, for example, that HDC will preserve the state (HBRUSH, HPEN, etc) between two WM_PAINT invocations (if it was a temporary HDC, on every WM_PAINT you would get the default values).
Using CS_OWNDC windows is the usual thing in OpenGL unless you know what you are doing. That way, for trivial rendering (single window, single threaded) you only need to do wglMakeCurrent when you create your HWND and get the HDC, as you know that the HDC is never going to be released by the system behind your back.
Historical note: In the times of Win 3.1 (and upto a lesser extent Win 9x), CS_OWNDC used to be a resource hungry attribute in the sense that you locked the HDC so it couldn’t be reused until the window was destroyed. In WinNT and derivatives, you have more than enough available HDCs.
Edit: UBB URL
[This message has been edited by evanGLizr (edited 02-02-2004).]
@gator:
Thanks for your answer but I don’t use the MFC along with my application.
@evanGLizr:
The window class is registered with the CS_OWNDC stylebit set.
Since the increase in memory usage seems to appear along with my Radeon card only but not with the Geforce card and programs not written by myself produce this behaviour also, I guess it may be a problem with the driver, hardware or whatever…
Maybe someone could test a program that uses constantly calls to wglMakeCurrent() (or wglMakeContextCurrentARB(); for instance: http://www.ati.com/developer/ATI_EMBM.html ) and check if it produces an increase in memory usage?
[This message has been edited by Kethvain (edited 02-03-2004).]
[This message has been edited by Kethvain (edited 02-03-2004).]
[This message has been edited by Kethvain (edited 02-03-2004).]
I’ve spent a day or two restructuring my code, trawling the web and this forum and I can’t solve my memory leak either.
I just read your last post and I cannot tell you my relief! What do you know, I have a Mobility Radeon 9600.
You know what, I’m going to be specifying nVidia kit for our products once again. I tried to upgrade the drivers on this machine but their installation program couldn’t even detect that it was a Radeon…
It’s common that driver upgrades don’t recognize the mobile chips; that happens both for ATI and NVIDIA mobile chips. Try installing Detonator on a Dell with a GeForce Go – ain’t gonna work. The reason is allegedly that the OEMs tweak the drivers to work with the specific flat panels they put in their machines, and these tweaks would be lost if generic drivers could install on top.
I’ve just let the ATI EMBM demo run for a couple of minutes and the memory used by the process stayed constant at about 13 megs. Overall virtual memory usage didn’t indicate any memory leak either.
This is Win2k SP4 with Catalyst 4.5 and a Radeon 9500 Pro.
Perhaps the source of your problems is your notebook vendor (DELL?).
@zeck: Does that demo actually use wglMakeCurrent() every frame?
Sometimes, you have to switch to different contexts, because you’re rendering to pbuffers. If there’s a memory leak everytime you do, well, that’s unfortunate.
Originally posted by jwatte: @zeck: Does that demo actually use wglMakeCurrent() every frame?
I don’t know. I just ran it because Kethvain suggested it had the same issue. I didn’t look at the source code.
However, the description indicates that some rendering to a pbuffer is going on, and as the sample is animated, this would have to happen per frame. shrug
Out of context response. Try seing if there is something else not properly released. I just finished reading another problem, and there might be some out of the ordinary errors if opengl specific internal variables are not used. obviously thats not the problem you have, but if that error is possible, than an array overflow might also get passed the error checking routines. if its a game, double check your game loop.