KOS Texture memory management bug

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
Orion_
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 31
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Fri Nov 21, 2014 3:31 pm
Location: France
Has thanked: 0
Been thanked: 0
Contact:

KOS Texture memory management bug

Post by Orion_ »

There seems to be a bug in the texture memory management of KOS (pvr_mem_malloc)
My game is in 640x480 and is using lots of texture, I had to reduce the vertex buffer to 192k to have more memory.
Despite that, I still don't understand why there is only 5Mbytes of memory left for textures (are the 640x480 double buffers 32bits wide ??)
Anyway, I made a little tracking system of what texture memory should remain (using pvr_state.texture_base) in my own TextureLoad/TextureFree functions (because pvr_mem_available() is broken)
and when I try to pvr_mem_malloc a 512x512 textures (512k of memory) it fails, even if in theory there should be at least 1Mbytes of texture memory available.
I get this after loading/freeing lots of texture while playing, I would say around 100 load/free.
And I get this message "pvr_mem: ERROR -- out of PVR memory; texture heap probably corrupted"
Do you know if a texture memory management bug is known ? or do any of you have a workaround for this ?
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: KOS Texture memory management bug

Post by BlueCrab »

The various internal buffers that are needed for the PVR to operate do indeed take up around 3-4MB or so of the video RAM, so that explains why you'd only have 5MB for textures. That is entirely normal, and an unfortunate side effect of the architecture of the PVR.

That said, pvr_mem_available() should work correctly since about October 22nd of last year. So, if you're using a more recent Git pull of the repository than that, that function should work fine. Before October 22nd, it would only report the amount of space that was essentially allocated and freed, rather than the total available space...

Also remember, even if there is 1MB available in total, you might not have a contiguous 1MB space available, which would cause the allocation of a 1MB texture to fail. That's why trying to track memory usage with pvr_mem_available() or any other such tracking mechanism to determine how much texture memory you can allocate at any given time is not a good idea. Also, remember if you're tracking memory yourself, you also have to deal with how things are aligned by the malloc code and any internal tracking information that the malloc code tags onto each allocated block. Simply put, just keeping track of how many bytes you allocate will not actually work in most situations.
User avatar
Orion_
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 31
Joined: Fri Nov 21, 2014 3:31 pm
Location: France
Has thanked: 0
Been thanked: 0
Contact:

Re: KOS Texture memory management bug

Post by Orion_ »

I'm using KOS 2.0 downloaded from the website.

I will try the GIT version
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: KOS Texture memory management bug

Post by BlueCrab »

Errors in the utility tools should not prevent the rest of KOS from compiling (and you should get the same error with KOS 2.0.0, as it required the same library for compiling that particular tool).

That said, that's complaining about you not having the jpeg development library available on your host system. It's also likely you'd get a similar error about libpng and zlib if you don't have the development library for those available.
User avatar
Orion_
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 31
Joined: Fri Nov 21, 2014 3:31 pm
Location: France
Has thanked: 0
Been thanked: 0
Contact:

Re: KOS Texture memory management bug

Post by Orion_ »

yes, sorry about that, I edited my post in the meantime.
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
User avatar
Orion_
DCEmu Crazy Poster
DCEmu Crazy Poster
Posts: 31
Joined: Fri Nov 21, 2014 3:31 pm
Location: France
Has thanked: 0
Been thanked: 0
Contact:

Re: KOS Texture memory management bug

Post by Orion_ »

I tried a trick which seems to work, even it's a dirty trick ..
I init the polygon using "power of two" width & height, but if the image I need is taking less space, I only malloc "image width rounded to power of two" x "image height" (even if not power of two), the remaining height will not be displayed anyway.
That way I can save some vram space.
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: KOS Texture memory management bug

Post by BlueCrab »

Orion_ wrote:I tried a trick which seems to work, even it's a dirty trick ..
I init the polygon using "power of two" width & height, but if the image I need is taking less space, I only malloc "image width rounded to power of two" x "image height" (even if not power of two), the remaining height will not be displayed anyway.
That way I can save some vram space.
I wouldn't call that a dirty trick. :wink:
It's actually pretty sensible, and definitely something I've seen done in plenty of people's code.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: KOS Texture memory management bug

Post by PH3NOM »

Right, I have previously considered the idea of a TMMU ( Texture Memory Management Unit ) software, that would basically keep texture memory defragmented each time a texture was removed.
However, this means that each time a texture is deleted, every other pointer to VRAM could potentially be changed; all pointers to VRAM that occur before the texture being removed would remain the same, but all pointers to VRAM that occur after the texture being removed would get shifted back to occupy the newly freed block of VRAM.

Anyway that was all brainstorming, not sure how practical it would really be.

But the fact is, 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.
Post Reply