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 ?
KOS Texture memory management bug
- Orion_
- 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
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- 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
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.
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.
- Orion_
- 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
I'm using KOS 2.0 downloaded from the website.
I will try the GIT version
I will try the GIT version
Retro Game Programming -> http://onorisoft.free.fr/ <-
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- 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
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.
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.
- Orion_
- 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
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, ...
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
- Orion_
- 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
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 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, ...
Dreamcast, PS1, PCe, MD, Atari, Jaguar, GP32, GBA, ...
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- 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
I wouldn't call that a dirty trick.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.
It's actually pretty sensible, and definitely something I've seen done in plenty of people's code.
- PH3NOM
- 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
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.
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.