Jump to content

  • Log In with Google      Sign In   
  • Create Account

mshafey

Member Since 14 Feb 2012
Offline Last Active Private

Posts I've Made

In Topic: Posssible memory leak in OpenGL Intel Win7 drivers

16 February 2012 - 09:54 AM

On reconsidering this, memory usage starting low, followed by an increase then stabilize is probably nothing to be worried about. It's where the stabilize part doesn't happen that you need to start worrying (that's a real leak - stabilization isn't a leak, it's just using resources). What's actually happening would be internal driver behaviour so we're reduced to guessing here, but going by your final stripped down program a reasonable and plausable guess would be that the driver is buffering up geometry used by immediate mode calls - it may for example be writing them into a dynamic VBO and then issuing real draw calls behind the scenes from that.


Thanks. We realized this is true. From here:

Memory Usage

It seems to be common to think that there is a memory leak in the OpenGL driver. Some users write simple programs such as this


glClear(...);
SwapBuffers(...);

and they observe that their memory usage goes up each time their Display function is called. That is normal. The driver might allocate some memory space and since the driver is basically a black box, we don't know what it is doing. The driver might be doing some work at optimizing in a secondary thread or preparing some buffering area. We don't know what it is doing, but there is no memory leak.


The problem is, in our application we're dealing with many OpenGL contexts at once (up to 30). For Windows XP on the same hardware, OpenGL memory is small compared to Windows 7. So in a day my application memory goes up to 1.5 GB on Win 7, but stays at 500 MB on XP.

We'll either require more memory or reduce the number of contexts used.

Thanks for the useful input everyone.

In Topic: Posssible memory leak in OpenGL Intel Win7 drivers

15 February 2012 - 12:07 PM

No. I'm finding the same behavior with QGLWidget (not using GLUT). Also, VLC with OpenGL output seems to have this memory increase problem as well.

In Topic: Posssible memory leak in OpenGL Intel Win7 drivers

15 February 2012 - 10:15 AM


Thanks for the suggestion. I've tried your code, it works, but it doesn't fix the leak. I'm still seeing memory leaking at the same rate on the affected platforms.

That's interesting. Let's try to pin down which call is causing it. What happens if you comment out the glTexSubImage2D call? And if you comment out the glMapBuffer block (but leave glTexSubImage2D in and coming from the PBO)?


gDEBugger with the code I posted in the first post. Upon application exit it says "Checking for memory leaks - Context 1 deleted. Memory Leak: 2 object(s) are leaked in GL Context 1 [Leak Size: 2,400KB]". Here are Process Explorer graphs for the original code running for a few minutes.

GPU graph: http://i.imgur.com/KgXix.png
Performance graph: http://i.imgur.com/bD9RH.png

I took out glMapBuffer()/glUnmapBuffer() block. Leak persists. Same for the glTexSubImage2D() call. Took them both out and still. Which lead me to remove everything except just basic calls to draw a rectangle switching colors. I'm sorry I sent everyone in the wrong direction here. It seems like even the most basic GL code causes Windows 7 machines to leak memory. I trimmed it down to this and it still leaks.


void paintGL();
void timerCallback(int value);
void changeSize(int w, int h);

unsigned char c = 255;

int main(int argc, char **argv)
{
	glutInit(&argc, argv);
	glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA);
	glutInitWindowPosition(300, 300);
	glutInitWindowSize(640, 480);
	int windowHandle = glutCreateWindow("Window");
	glutDisplayFunc(paintGL);
	glutReshapeFunc(changeSize);
	timerCallback(0);
	glutMainLoop();
	glutDestroyWindow(windowHandle);
	return 0;
}

void paintGL()
{
	c = c? 0 : 255;
	glColor3ub(c, c, c);
	glBegin(GL_QUADS);
	{
		glVertex3f(-1, 1, 0);
		glVertex3f(1, 1, 0);
		glVertex3f(1, -1, 0);
		glVertex3f(-1, -1, 0);
	}
	glEnd();

        glutSwapBuffers();
}

void changeSize(int w, int h)
{
	glViewport(0, 0, w, h);
}

void timerCallback(int value)
{
	glutPostRedisplay();
	glutTimerFunc(5, timerCallback, 0);
}


I might add that in some runs, this code starts off at about 18 MB and goes up to and then stabilizes at 40 MB in a 5-6 minutes.

In Topic: Posssible memory leak in OpenGL Intel Win7 drivers

14 February 2012 - 01:23 PM

@OP: have you tried this using glBufferSubData instead of glMapBuffer? It would be interesting to know if the same symptoms are observed with that. The following should be equivalent:

void mapAndCopyToBuffer(char* img1)
{
	glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB, pixelbufferHandle);
	glBufferSubData (GL_PIXEL_UNPACK_BUFFER_ARB, 0, w * h * s, img1);
	glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, w, h, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, 0);
}

Oh - and make sure that the value of s is 4. ;)


Thanks for the suggestion. I've tried your code, it works, but it doesn't fix the leak. I'm still seeing memory leaking at the same rate on the affected platforms.

In Topic: Posssible memory leak in OpenGL Intel Win7 drivers

14 February 2012 - 11:54 AM

seems like you don't free your mappedBuf after using it. you need to do this if you want to really free some memory:


But we didn't allocate any memory here. What I understand is that after the call to glMapBuffer(), mappedBuf should be treated as GPU memory, so it's not up to us to free it. We copy the texture into this mapped memory, then call glUnmapBuffer() to indicate to OpenGL that we're done copying/modifying that buffer (the buffer that belongs to the driver, not us).

Just to be sure, I tried to delete[] mappedBuf now (before the statement where I set it to NULL). It crashes.

PARTNERS