CODEWITHSUNDEEP
c++opengl
Brandon
Brandon

Reputation: 23498

How does glDeleteTextures and glDeleteBuffers work?

Basically, in my code I hook the glDeleteTextures and glBufferData functions. I store a list of textures and a list of buffers. The buffer list holds checksums and pointers to the buffer. The below code intercepts the data before it reaches the graphics card.

Hook_glDeleteTextures(GLsizei n, const GLuint* textures)
{
    for (int I = 0; I < n; ++I)
    {
        if (ListOfTextures[I] == textures[I])       //??? Not sure if correct..
        {
            //Erase them from list of textures..
        }
    }

    (*original_glDeleteTextures)(n, textures);
}

And I do the same thing for my buffers. I save the buffers and textures to a list like below:

void Hook_glBufferData(GLenum target, GLsizeiptr size, const GLvoid* data, GLenum usage)
{
    Buffer.size = size;
    Buffer.target = target;
    Buffer.data = data;
    Buffer.usage = usage;

    ListOfBuffers.push_back(Buffer);
    (*original_glBufferData(target, size, data, usage);
}

Now I need to delete whenever the client deletes. How can I do this? I used a debugger and it seems to know exactly which textures and buffers are being deleted.

Am I doing it wrong? Should I be iterating the pointers passed and deleting the textures?

Upvotes: 0

Views: 742

Answers (1)

datenwolf
datenwolf

Reputation: 162164

You do realize, that you should to it other way round: Have a list of texture-info objects and when you delete one of them, call OpenGL to delete the textures. BTW: OpenGL calls don't go to the graphics card, they go to the driver and textures may be stored not on GPU memory at all but be swapped out to system memory.

Am I doing it wrong? Should I be iterating the pointers passed and deleting the textures?

Yes. You should not intercept OpenGL calls to trigger data management in your program. For one, you'd have to track the active OpenGL context as well. But more importantly, it's your program that does the OpenGL calls in the first place. And unless your program/compiler/CPU is schizophrenic it should be easier to track the data first and manage OpenGL objects according to this. Also the usual approach is to keep texture image data in a cache, but delete OpenGL textures of those images, if you don't need them right now, but may need them in the near future.

Your approach is basically inside-out, you're putting the cart before the horse.

Upvotes: 1

Related Questions