Memory leak when using glDisable(GL_TEXTURE_2D) in draw-call

Question

I've been noticing a small memory leak in my program and I've finally been able to track down the problem.

What i'm doing is drawing out 5 rectangles to the screen by calling this function:

bool OpenGlEntity::fillRect(SDL_Rect rect, float R, float G, float B, float A){

glPushMatrix();

    glDisable(GL_TEXTURE_2D);

    GLfloat vertices_position[] = {
    (GLfloat)rect.x, (GLfloat)rect.y,
    (GLfloat)(rect.x+rect.w), (GLfloat)rect.y,
    (GLfloat)(rect.x+rect.w), (GLfloat)(rect.y+rect.h),
    (GLfloat)rect.x, (GLfloat)(rect.y+rect.h),
    };

    glTranslatef(0, 0, 0);
    //scale
    glScalef(1,1,1);
    //set color
    glColor4f(R, G, B, A);

    glEnableClientState(GL_VERTEX_ARRAY);
    glVertexPointer(2, GL_FLOAT, 0, vertices_position);

    glLockArraysEXT(0, 4);

    glDrawArrays(GL_QUADS, 0, 4);

    glUnlockArraysEXT();

    glDisableClientState(GL_VERTEX_ARRAY);

    glEnable(GL_TEXTURE_2D);
    //reset color
    glColor4f(1.f, 1.f, 1.f, 1.f);

glPopMatrix();

return true;}

If i never run "glDisable(GL_TEXTURE_2D);" (or "glEnable(GL_TEXTURE_2D);") the leak doesn't occur. Why is this?

For me it doesn't many any sense, but then again i'm not that experienced in OpenGL rendering.

Andon M. Coleman Andon M. Coleman · Accepted Answer · 2013-07-29T18:01:29

There are many reasons you could perceive enabling or disabling a particular state to cause a memory "leak". For instance, if you enable trilinear filtering on a texture and the texture does not have mipmap data, the driver will often wind up allocating memory for a mipmap chain/pyramid (whether it generates the actual mipmap levels or not). This would result in a growth of ~33% memory consumption simply because you changed a texture filter state.

By the way, the draw call is not really the source of the increase in memory. Draw calls are generally a point in which the driver commits queued commands. This is why you cannot time the duration of a call to glEnable (...) or glDisable (...) and get a measure of the overhead of changing that state. Smart drivers will run through all state change requests between the last draw call and the current and this is when the majority of state setup really occurs. So in your case, the driver may be deferring some texture setup operations until the first time the texture unit and/or object is bound and enabled. As a result, the driver winds up allocating memory for the texture during the laundry list of tasks it performs when you issue your draw call.

It is tempting to profile an application, see that glDraw (...) appears to be your bottleneck and assume that you are vertex-bound, but this could not be further from the truth in many cases :) This is just one of many reasons why you need more purpose-built tools and APIs to effectively debug, track memory resource allocation, and profile applications that use the GPU.

In any case, chances are what you are experiencing is normal behaviour, drivers have to allocate memory in multiple locations (CPU, GPU, etc..) to deal with events like "device lost." If the "leak" is a one-time occurrence, you can ignore it and chalk it up to driver memory management.

Memory leak when using glDisable(GL_TEXTURE_2D) in draw-call

1 Answers