clearing memory on the cpu side


I have a program where I need to create a few buffers to run in different shader programs. The total size of the buffers’s data is 0.7GB. I have a 16 GB cpu RAM and 1.5GB GDDR5 graphics card RAM.

Since I am using a 32 bit Visual Studio 2008, I seem to be running out of space on the cpu side.

I have a couple of questions:-

  1. Does changing to a different version of Visual Studio,say 2012 32/64 redistributable, help? I have read that they are still 32 bit in nature.
    2.Once I send the data onto the gpu using glBufferData(…,data), can i then clear the data on the cpu side? I tried doing data.clear() since data was a vector, and it didn’t seem to clear up any memory on the cpu side ( I was looking at the Task Manager memory usage).
    3.I have two different shaders and their buffers are totally different. So lets say, I am done the first program, can I clear the buffer’s footprint “on the gpu side” without deleting the program?

Any links/pointers to good clean up practices will help.


  1. If you compile a 64bit program you get all the perks of a bigger address space. But 0.7GiB should not be a problem on 32bit.
  2. Note that buffers are server side but that does not mean they are in VRAM. They also can be in system memory. Mostly the driver guesses where to put it by usage patterns, the driver also can change the memory location later one.
    Anyway after sending data with glBufferData you can delete the source memory! Using erase() on a vector does not guarantee that the allocated memory will be freed. You can use the shrink_to_fit() function, but its only available in C++11.
    Also the runtime library that provides memory functions like malloc, caches memory pages and does not give them directly back to the operating system. The task manager only shows the view of the operating system.
  3. Shaders and buffers are separate OpenGL objects, that can be deleted separately.

Just to clear up the (apparently fairly common) misconception on Visual Studio in question 1: Supposedly Visual Studio itself is still a 32-bit application. That just means that your development environment runs in 32-bit mode. It can build 64-bit applications just fine, and has been able to do that for some time (2005?). The free Express versions were limited to building 32-bit applications until recently, but that restriction is also lifted with Visual Studio 2012.