SDK ADD: VRAM MMU (valloc/vfree)

[Raphael]

I coded a small VRAM MMU in the style of the libc alloc files and already submitted it on the PSP Development forum where it had pretty good feedback and also the request to add it to the SDK.
Since I don't have any SVN access and also don't have an idea where to place it best, I'll just provide the link to the sources here, so maybe one of the SDK devs can look over it and then decide to work it into SDK or not.
It's free to use for you guys however you like :)

Best regards,
Raphael

SOURCE

[be2003]

its a little late...

but I LOVE YOU!

[Insert_witty_name]

Raphael has a newer version of this here: http://www.psp-programming.com/forums/i ... 840.0.html

[raf]

Raphael has a newer version of this here: http://www.psp-programming.com/forums/i ... 840.0.html

I also use this code from Raphael. It is very useful, and vote for it to be included in the sdk. If nothing else, it should be added to the subversion repository as a library.

What do you guys think?

Raf.

[dot_blank]

i second the notion for a subversion library of this very useful
VRAM source ...possibly name it libpspvram, linking with -lpspvram

to make everything nice and neat and easily rememberable :)

[be2003]

i like that idea to

as long as raphael submits this version rather than the newer one
because i for one like having more vram space to allocate
it doesnt really matter how long it takes to allocate it
as long as i get to keep what little space the vram provides

[Insert_witty_name]

Newer one is a lot better, and the overhead very small.

[be2003]

ill try it out
can u please post a download link?

[Insert_witty_name]

It's the link I gave above.

The code is attached to the bottom of the post.

[Raphael]

I didn't think to see this thread once again in my life :)
Nice it gets some recognition at last ;)

I'd be glad to have the lib in the subversion as something like libpspvram or equal, I already had quite some feedback from people using this lib in their programs now (much more than I ever thought).

PS: Regarding the allocation overhead of the newer version: You can easily adjust that by changing the __BLOCK_SIZE define to something smaller than 512. The limit is 64 since the block index needs to fit into 15 bit and you need to reach the whole memory range with that (64*2^15 = 2MB).
Block sizes of 64byte should be good enough though, since it's small enough that a 8x8x8bit texture fits into it without waste and only smaller textures cause some very small loss of VRAM. If anyone is really picky about that, you can always use the older version linked at the top of this thread or (version 1.01 with faster vmemavail function) at my blog.

EDIT:
Current links to the two different versions:
valloc 1.01 - slower and depends on malloc
vram 1.0 - faster but little overhead for small allocations

[raf]

Alright,

I committed the libraries to the repository. They are under the libpspvram directory in the trunk.
I added a makefile that will make both the libpspvram.a and the libpspvalloc.a libraries. Make install will install to the pspsdk folders on your system.

For the vram code, I used the latest from Raphael; for the valloc, I used the old code I was using. Will need to update.

I'll let Raphael write some sort of readme, which I could then commit.

SVN WEB: http://svn.ps2dev.org/listing.php?repna ... rev=0&sc=0

SVN URL (for svn client): svn://svn.ps2dev.org/psp/trunk/libpspvram


Raf.

[willow :--)]

Sorry to revive an old thread, I have a question about the usage of these libs.

If I initialize my display buffers like this:
fbp0 = ( u32* ) vrelptr ( valloc ( FRAME_BUFFER_SIZE ) );
fbp1 = ( u32* ) vrelptr ( valloc ( FRAME_BUFFER_SIZE ) );

Assuming I want to free them at some point, is it correct to call:
vfree(fbp0);
vfree(fbp1);

or is it incorrect since they are relative pointers ? (And in that case, how should I do it? Have intermediate pointers after the valloc ?)

[a_noob]

First of all you should probably update it to a more current version, and then you would use vGuPointer(void *) and vCpuPointer(void*). Or you can do
vfree((void*)((u32)fbp0 | 0x04000000)); This will convert it from a relative to a absolute pointer.

[Raphael]

Well, there is no "more current version", as the library was never updated from it's release (didn't have to :). There are just the two different versions (valloc.c old one, vram.c new one), and I still recommend using vram.c, as it doesn't depend on malloc (no dynamic sysram allocations) and is quite a bit faster.

Regarding vfree usage, it expects the exact same pointer that valloc gave, which is an absolute pointer.
So the correct usage would be like this:

Code: Select all

void* fbp = valloc(size);
sceGuDrawBuffer( ..., vrelptr(fbp),..);

vfree(fbp);

or alternatively (not recommended as null pointers aren't detected any more, but works):

Code: Select all

void* fbp = vrelptr(valloc(size));
...

vfree(vabsptr(fbp));