Freeglut, OpenGL and memory

Question

I've started practicing OpenGL with Glew and Freeglut.

I have a question about my application and was wondering if anyone ran into the same problem (if it is one)?

When I initially execute my application, the memory used is around 22,000 KB. After minimizing my window and maximizing it again, it only takes 2,900-3,300 KB of memory and continues to do so even after minimizing and maximizing the window again as well as performing mouse and keyboard input while the window has the focus.

I'm wondering why this is so? I don't know too much about FreeGlut and I'm wondering if anyone else has noticed this behavior when minimizing/maximizing the window with FreeGlut. Or maybe this is an OS-specific thing?

Sorry for not mentioning it before, but I'm using Windows XP SP3 and I'm setting up the OpenGL context with the following lines of code:

glutInit(&argc, argv);
glutInitContextVersion(3, 3);
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowPosition(30, 30);
glutInitWindowSize(1000, 562);
glutCreateWindow("Testing");

glewExperimental = GL_TRUE;
glewInit();

Byrne

Which OS are you using? How do you setup your GL context (i.e. what do you pass to FreeGLUT)? – Pape

Definitely building a script to do that to all my GL apps! Maybe automatic minimization (no pun intended) should become a common feature amongst operating systems? But in all honesty ("jokes aside", SigTerm) could memory be paged out and then not needed again after restoring the window? – Overrate

How do you measure memory usage and why do you worry about that? Modern system is supposed to have at least 2GB of RAM. On my 8GB machine 22000 KB is 0.27% of total memory usage. You could simply ignore that. – Albumenize

@jozxyqk: " Maybe automatic minimization". No. Automatic minization will annoy the user. You do not want to ever annoy the user. – Albumenize

@SigTerm: Unless you're on an OS like 32-bit Windows... That 22,000 KiB is significantly more when your process address space is limited to 2 GiB and you're sharing part of your address space with the display driver. Still nothing to worry about in most situations though. – Unni

@AndonM.Coleman: You probably wanted to say "unless you're on windows 95/98". 32bit os supports up to 3 GB of RAM, and is expected to support 2GB at least, which is what I'd expect to find on pretty much any modern machine, even if that machine uses WinXP. On 2GB of RAM 22000KB is about 1% of total RAM. Not worth worrying about unless you're writing a daemon/service. And if you're writing daemon, you don't need OpenGL. 22MB was a big deal on win98, when you machine had 64MB of RAM or something. But that was long time ago. – Albumenize

@SigTerm: No, I meant 32-bit Windows in general. Unless you compile your software with a special linker flag, Windows is going to limit you to 2 GiB. And this 2 GiB limit is not a limit on physical RAM mind you, this is your entire address space, so memory mapped I/O and GPU-mapped memory is also subject to this limitation. This limit also applies to 32-bit software running on a 64-bit kernel in Microsoft Windows, sadly. – Unni

@AndonM.Coleman: I believe you're seriously mistaken. On 32bit system you have 4GB of addressable space (2^32 = 4294967296). However, some addresses are reserved for operating system. Normally that's upper half (0x80000000 and up). In addition to that, I'm not going to worry about 20MB that are only spent once if I have 2GB to myself. – Albumenize

@SigTerm: There is not point arguing over this, it is completely unconstructive. But I suggest you change your thought process to limit yourself to what the operating system will actually give a user-mode process, rather than what the hardware supports. Virtual memory is managed by the operating system in modern computers, and they tend to make a distinction between user-mode and kernel-mode. – Unni

@AndonM.Coleman: Suggestion ignored. I have 32bit addresses, which may or may not correspond to hardware memory, may or may not be available, and may or may not even be stored in continuous hardware memory block. Therefore I have 32bit address space. If I had 31bit addresses, then I could say I can have 2GB of accessible memory. Now how much memory I can allocate before allocations start to fail is another story. – Albumenize

@AndonM.Coleman: Recommended reading: you can have more than 2GB of space available for your program on 32bit windows. – Albumenize

@SigTerm: I already told you about this linker flag in a previous comment. I did my thesis on real-time memory management in VxWorks, QNX, Windows, OS X and Linux so I am well aware of this limitation in Windows. You literally cannot address anything above 2 GiB (or 3 GiB with a special flag) in Win32 in user-mode, or you will create an access violation exception. Now the problem here is that in WDDM on Windows, part of the DirectX and OpenGL runtime is implemented in user-mode, so part of your address space (even if you never map GPU resources to user-mode memory) is used by the driver. – Unni

Answer 1

This is highly OS dependent and also depends on how you measure memory usage, but I can give you a little bit of insight into why this might be happening on Microsoft Windows. Microsoft has the following to say about user-mode memory usage in an application that uses a WDDM-based driver:

Existing games and other graphics applications frequently allocate virtual memory for a copy of the video memory resources that the application uses. The application uses this copy to restore the display quickly if the contents of video memory are lost. For example, the application uses this copy if the user presses ALT+TAB or if the user puts the computer in standby. Typically, the DirectX run time manages the copy on behalf of the application when the application creates a managed resource. However, an application can also manage the copy itself. The virtual memory that the copy uses is directly proportional to the video memory resources that the application allocates.

Now, while Microsoft describes this a DirectX problem it actually applies to OpenGL too. Behind the scenes OpenGL usually deals with "device lost" events completely transparently (this is not a part of OpenGL itself, but of the window system -- WGL in this case). Although you can actually receive these events in your software in OpenGL 4.x using one of the robustness extensions you usually want to pretend like they do not exist. In any case, I suspect that this is what is to blame.

Your memory consumption will vary wildly depending on how you measure your application's memory consumption, whether it's simply a count of the number of virtual memory pages allocated (virtual size), or actual resident pages (working/resident set). On Windows, if you look in the task manager at memory consumption that is usually a measure of working set. Working set is a very vague concept, and usually refers to the number of pages that were "recently" referenced; it can grow/shrink depending on when it is sampled irrespective of how much memory is actually resident at that exact instant. I would chalk this up to normal driver behavior, and realize that this memory is probably not going to affect anything seriously.

If you're running on a modern desktop 64-bit platform (x86-64) you actually have a 48-bit hardware address space (256 TiB) and the OS will give you a fraction of this (8 TiB on Windows) for individual user-mode processes, so 22,000 KiB is completely insignificant (if you actually compiled your software as 64-bit).

Unni