Freeing Texture problem?

[lerabot]

I've hit a wall recently checking for memory leak.

Here's a simple structure of my code:
I use -lGL to load my texture using the png_to_texture function from the DCEmu tutorial.
I made myself a couple of classes to handle stuff like scene, and gameObjects.

I was trying to figure out memory usage by using mallinfo.uordblks and mallinfo.fordblks but that showed no real info.
I then discovered pvr_mem_available() which showed much more info, each time I reloaded a "scene" I noticed my memory dropping quickly.

Using glDeleteTexture fixed that and I can now load a new scene and the old texture do seems to free properly, using pvr_mem_available() to check between each loading.

However, after reloading the scene 6 times (which was also the number of time it took to crash before freeing my texture proprely), the program still crash, with plenty of pvr memory available.

I could post a zip with all my code, but I'm just wondering if I'm msssing out on something? Should glDeleteTexture do the job?

[bogglez]

Yes, it should remove the data from VRAM.
But it's also possible that the PNG loading code doesn't free its memory. Once the texture data has been passed to glTexImage2D it should be freed from RAM.

And please don't send a huge zip. Just create a minimal test case. Should be simple enough by commenting out lots of code.

[lerabot]

I'll look at the PNG loading code again before sending code.

Do you know if there's a function like pvr_mem_available() or any thing else useful I could use to keep track of memory?

Thanks so much bogglez.

[111]

I'll look at the PNG loading code again before sending code.

it's probably the case, I've already encountered something like this: viewtopic.php?f=29&t=104054

Do you know if there's a function like pvr_mem_available() or any thing else useful I could use to keep track of memory?

There is none. But you can use something like this: https://dcemulation.org/phpBB/viewtopic ... 0#p1009180

Regarding vram, you may want to check out this:
viewtopic.php?f=29&t=103573



also, stay the hell away from KGL (it's not "production ready", to put it mildly). Relying on kgl was the biggest mistake I made while working on my project ("OutbreakX"). Save yourself some trouble and use PVR\PLX API instead, you'll thank me later.

[lerabot]

After making sure that I free the data after it's being assigned to a glTexture, my game doesn't crash anymore! But the images end up being all black. Not after the first load tho, after the 6-7 load! Making progress...

After reading those thread, I have one big question,

PHEN0M said this:

like BlueCrab said, the way KOS handles Texture Memory Management, removing a texture results in Fragmented memory in VRAM; you could have 1mb of free VRAM, but that 1mb could be in 64x64x2 chunks with in-use memory chunked in between free chunks.

So let say I load a 512x512 tex, and a bunch of small one if the first scene, then I unload it to make space for the second scene (again maybe one big texture and a couple of 64x64, or 64x128 one). At some point I'll try to load data but the memory will be fragmented and KOS might not be able to find a decent space for 512x512 texture anymore.

Am I getting that wrong? Should I have static adresses for memory?

EDIT : PROGRAM IS FIXED!! I was missing some free for certain things, and I used GL_ACTIVE_TEXTURE to check if the number of texture was correct.

[BlueCrab]

It's not necessarily a problem limited to KOS when you're talking about memory fragmentation. That's a very common issue that developers had to deal with when dealing with smaller memory systems.

Optimizing the order that textures are allocated and freed is really the only way to prevent memory fragmentation, short of completely clearing and reallocating everything once in a while (that is to say, compacting the texture heap). Compaction is possible, but not exactly a very friendly thing to do. It'd probably be possible to do with GL, with some clever code thrown into the library (at least it'd probably be easier with it than without it).

[bogglez]

Actually fragmentation could be reduced by creating buckets of textures by size or at least something them by size and then putting smaller textures on one end while putting bigger ones on the other. So deallocating a big texture makes room for exactly another new big texture without fragmentation.

Most games also don't need to load textures during gameplay but at loading screens so there are opportunities for memory compaction.

You can also load textures which are used long term at the start of memory and textures that are swapped out all the time at the other end. That way you can guarantee that most of the texture memory used is always compact.

[BlueCrab]

Most games also don't need to load textures during gameplay but at loading screens so there are opportunities for memory compaction.

Which, as I said, would be simple enough to make it so GL could do... Considering how GL keeps track of textures internally and all. Since we know the raw texture pointers should only ever be persistently stored inside the library, it'd be relatively easy to have a library function to do compaction. It'd also be possible to have GL keep track of deleted textures and attempt to reuse them when requests of the same size come in, but I'm reasonably sure that pvr_mem_malloc() should already effectively do that.

When you have a bunch of stuff that could be accessing raw pointers, of course it's really a lot more difficult to do compaction in a general way.

Implementing alternative allocators could also be helpful (like a slab allocator as you proposed), but they're hard to do generally. It's much easier if you know that you're going to have a bunch of objects of a few distinct sizes. It certainly wouldn't be something I'd propose replacing the pvr_mem_malloc() stuff with generally, but might make an interesting thing to augment it with.

[lerabot]

Thanks so much guys, I have a way better idea at how I should manage texture now.

It's so nice to work with KOS, the number of ported librairies, documentation and tool make it a blast to work with.

Also, as I was looking around for info, and learning how to make thing, I've wrote "basic" guides. Should I try to submit those to booglez for the wiki? And feel free to edit those if I'm making blatant mistake.

[BlueCrab]

Feel free to post any "guides" you might have on the forum. That's the best way that people can see and comment on them and thus help to improve them.

Also, bogglez certainly isn't the only person who can edit the wiki.

[bogglez]

If you write some good guides I'm sure you'll get wiki access quickly. If it's one thing we're missing it's documentation

[bogglez]

I have split the forum thread: viewtopic.php?f=29&p=1053627
Please don't feel afraid to open a new forum thread once the discussion diverges too much from the original topic.

[lerabot]

I have a wierd issue now and I can,t put my finger on why it does that.
Depending on what order I free my textures, I don't get the same memory back?

I have 2 arrays, one is a texture array, the second one is a "gameObject" array. Each gameObject contains a texture aswell.

I load my texture array first, then my gameObjects.
If I unload my texture first than my gameObjects, I get almost all my mem back.
if I unload the gameObject first, then my textures, I get 1/3 back.

Is it just common knowledge that i should unload in the same order than I load my stuff?

[lerabot]

I figured it out,

Some of my gameObject use texture from other gameObject. Deleting the texture will delete the next texture loaded. Is that supposed to happen?

Right now I'm just deleting them manually and it's working fine, but I wonder if there's a way (within openGL) to know if a texture slot holds a texture. Checking if the adress/data of the textureID doesn't seem to give much info.

[lerabot]

I figured it out,

Some of my gameObject use texture from other gameObject. Deleting the texture will delete the next texture loaded. Is that supposed to happen?

Right now I'm just deleting them manually and it's working fine, but I wonder if there's a way (within openGL) to know if a texture slot holds a texture. Checking if the adress/data of the textureID doesn't seem to give much info.

[bogglez]

What do you mean by next texture?
If you mean that game objects A and B both use texture object 5, then calling glDeleteTextures will delete that texture, there is no internal reference counting in OpenGL. You should introduce your own mechanism for thay.
If by next you mean that deleting texture object 5 also deletes texture object 6 then we have a bug.

[lerabot]

let's imagine that I have an array of gameObject, and that member 1 uses the same texture as member 0. if I run this:

glDeleteTextutes(1, obj[0].tex.id);
glDeleteTextutes(1, obj[1].tex.id);

I will delete 2 texture, the texture used for gameObject 0 and another texture. I'll run this some other time today but I believe it deletes the next texture loaded.

Since obj[0].tex.id == obj[1].tex.id, I believe it should only delete the texture the first time around and ignore (?) the second call, seeing that the texture is freed already.

[bogglez]

I had a look at the code and sadly it's very obviously broken.. Not sure why ph3nom went for a linked list here although he could just use an array due to the texture indices.
If anybody wants to patch the code (by fixing the linked list implementation or by switching to an array), here's my (hopefully) correct implementation:
https://bitbucket.org/bogglez/libgl15/s ... ture.c-690

[lerabot]

thanks so much booglez! I knew something was kinda wrong.
there was a bunch of patch on -lgl recently, I can't wait to update mine and break everything