Mmu Hack: What Exactly Does It Do?


Noremakk

Still Fresh
Joined
Jan 29, 2008
Messages
67
*pokes title*

I see Squidge's MMU hack in almost every program I have on my GP2X, but I'm just curious: what exactly does it do? Is it an easy way to use the 2X's second processor? Does it make programming easier?

Also: can I save space by just putting the MMU hack file on the root of my SD card and deleting it from all the numerous folders it's in?

Thanks for your expertise, and to Squidge for making... whatever it is. :p
 
Noremakk said:
*pokes title*

I see Squidge's MMU hack in almost every program I have on my GP2X, but I'm just curious: what exactly does it do? Is it an easy way to use the 2X's second processor? Does it make programming easier?

Also: can I save space by just putting the MMU hack file on the root of my SD card and deleting it from all the numerous folders it's in?

Thanks for your expertise, and to Squidge for making... whatever it is. :p
Wiki!

The MMU hack is a hack that helps fix a problem with the MMU and the upper 32 mb of RAM.
In real simple terms it caches the upper 32 mb allowing for faster memory access. So any program that uses the upper 32 mb can get a boost by loading this module. The framebuffer is located in the upper 32 mb, so any program could benefit from the hack.
It has nothing to do with the second processor, and it doesnt make programming easier.

I dont know if you can move it, basically the code to use it does a insmod on the mmuhack.o
There also can be different version of the module, so it may not be a good idea to delete them.
If we did it right there should have been a global location for the module, then there wouldnt have to be so many copies. Althought the original hack was not in a kernel module format, so that may have had something to do with it.
 
Last edited by a moderator:
I noticed a considerable speed boost in my Yeti3D (re)port when I applied it - and the disappearence of graphical artifacts when usingSDL_HWSURFACEs...
It's a boon to the gp2x community, really. Thanks Squidge and Notaz!
 
* Takes a bow * :ph34r: :D

Thank you, thank you ;)

It's scary when you think about it. There's a little piece of me inside a lot of (most?) gp2x software :blink:
 
The day MMUHACK appeared the GP2X Scene got 2 more years of life :)

Thank you very much Squidge ;)
 
Squidge said:
* Takes a bow * :ph34r: :D

Thank you, thank you ;)

It's scary when you think about it. There's a little piece of me inside a lot of (most?) gp2x software :blink:
At least 80% of all the 2X software I have has mmuhack.o inside it.
 
Last edited by a moderator:
Yes, very good "invention" :) Would be cool, if these Hack could be part of the GP2X Firmware. I'm not a coder but maybe every game could benefit automaticly from this. :)
 
To reiterate/expand a little...

mmuhack allows the upper memory region to be cached and write buffered. It's the second aspect that gives improvements in most programs, not the first. Usually the frame buffer is only written to and never read. This means that cache lines will never be allocated for it, so it won't be cached anyway. Having write buffering on allows the CPU to continue doing instructions after a store while the write buffer is drained in the background, unless the write buffer is full (then it's stalled and has to wait). For writing out a steady stream of data this effectively translates into overlapping the few instructions inbetween the stores with the stores themselves, making each write out a few cycles shorter (still takes a number of cycles per write because main memory isn't fast).

If programs depended on caching then they'd be much slower without mmuhack. Temper 0.5 actually did for some games (for part of the screen) which is why it suffered severely w/o it. This is actually not a good way to do things (and was changed later) because rarely do you want the framebuffer to stream into cache. Although it will make multiple writes to the same locations faster (good for several layers) it'll thrash cache terribly. It's probably better to write into a scanline buffer which is cached then write that out to main memory if there's a lot of overdraw, as unintuitive as that sounds.
 
slaanesh said:
Why wasn't the MMU fully functional for the entire memory region in the first place?

Was this by design or due to a problem with software controlling the MMU?
By design. It's just some default Linux stuff. It was done this way so the two cores could share memory in that region without worrying about cache coherency issues.
 
Last edited by a moderator:
Exophase said:
To reiterate/expand a little...

mmuhack allows the upper memory region to be cached and write buffered. It's the second aspect that gives improvements in most programs, not the first. Usually the frame buffer is only written to and never read. This means that cache lines will never be allocated for it, so it won't be cached anyway. Having write buffering on allows the CPU to continue doing instructions after a store while the write buffer is drained in the background, unless the write buffer is full (then it's stalled and has to wait). For writing out a steady stream of data this effectively translates into overlapping the few instructions inbetween the stores with the stores themselves, making each write out a few cycles shorter (still takes a number of cycles per write because main memory isn't fast).
Holy shit! So even though I *don't* want the upper memory to be cached, I'm still losing performance when I draw straight onto the framebuffers?!? :eek:

That's another thing to look at when I next have time to work on T2K, then...
 
Last edited by a moderator:
Firefox said:
Holy shit! So even though I *don't* want the upper memory to be cached, I'm still losing performance when I draw straight onto the framebuffers?!? :eek:
You can have buffered writes without caching. That could even be faster than caching :)
Can't remember if mmuhack allows you to have only buffered writes.
 
Last edited by a moderator:
Squidge said:
Sure it does, just recompile it :)
I am so lazy :)

Did you try to play with sections? You can map 1 MB pages which could avoid TLB trashing...
IIRC the kernel already maps 940 memory as sections, but you don't use the same virtual addresses.

It's been so long since I switched on my gp2x :rolleyes:

EDIT: I already wrote about this here
 
Last edited by a moderator:
Firefox said:
Holy shit! So even though I *don't* want the upper memory to be cached, I'm still losing performance when I draw straight onto the framebuffers?!? :eek:

That's another thing to look at when I next have time to work on T2K, then...
No, not if you're only writing to it, since ARM does not allocate cache lines for writes. You could be killing cache if you read from it, however (but if you don't have mmuhack at that'd be much worse)
 
Last edited by a moderator:
Back
Top