Mmuhack As Kernel Module

[notaz]

Here:
http://notaz.gp2x.de/releases/mmuhack_wiz_r3.zip

Use it exactly the same as you use it on F100/F200. Tested on 1.0.0 and 1.0.1 kernels.

Edit: updated link to r3.

 

[Franxis]

The terminal trace seems ok:
CODE
Installing NK's kernel module for Squidge MMU Hack...
Using mmuhack.ko
mmuhack: loaded, will use 026ec000-0fffffff (38MB RAM used by Linux)
mmuhack: MMU hack applied (4114 entries)


But i don't see the MMU hack applied .

With Exophase MMU hack Out Run runs at 46 fps, but with the kernel module there are only 35 fps (the same as if no MMU hack is applied).

Also if i remove the flushcache() calls the screen is not corrupted (as it would be expected).

I compile in Windows using the modified DevKitGp2x and linking dynamically. Also i use the flushcache.s i used in the GP2X and the same code activating the MMU Hack (changing mmuhack.o by mmuhack.ko). I apply the MMU Hack just after mmap() the upper memory area.

Also i see in the trace "38MB RAM used by Linux". Is it true? It was supposed to be 48MB used by Linux.

Regards.

 

[notaz]

But i don't see the MMU hack applied .

With Exophase MMU hack Out Run runs at 46 fps, but with the kernel module there are only 35 fps (the same as if no MMU hack is applied).
Hm, strange, I'll try it with MAME myself and see what's going on.

Also i see in the trace "38MB RAM used by Linux". Is it true? It was supposed to be 48MB used by Linux.

The kernel is booted with "mem=42M", and few megs are taken by the kernel code itself.

 

[Franxis]

You can download MAME 2.0 source code and update the src/wiz/ directory with the contents of this ZIP file:
www.talfi.net/gp32_franxis/mame4all_src_wiz_mmuhack.zip

 

[notaz]

ok I've found the problem, I shouldn't have removed the AP bits. Apparently faults happen then, and kernel removes C B bits. Here is the fixed version:

http://notaz.gp2x.de/releases/mmuhack_wiz_r2.zip

Looks like it gives a few FPS more, probably due to Exophase's version suffering those strange cache problems.

 

[sam fisher]

This is pretty awesome .

 

[Franxis]

ok I've found the problem, I shouldn't have removed the AP bits. Apparently faults happen then, and kernel removes C B bits. Here is the fixed version:

http://notaz.gp2x.de/releases/mmuhack_wiz_r2.zip

Looks like it gives a few FPS more, probably due to Exophase's version suffering those strange cache problems.

Truly it runs, and it runs a lot faster than the Exophase's version!!!.

Is GPH setting the cache correctly in the Linux part???

Out Run runs better using the upper memory now than using the Linux memory!!!

 

[sam fisher]

. Maybe the Wiz isn't as slow as people think .

 

[Pickle]

I dont see much change in with it on or off always around slighly about 13 fps. CPU must be the bottleneck.

 

[notaz]

Is GPH setting the cache correctly in the Linux part???

yes it's all set, just confirmed that. If they weren't, things would be a lot slower then on GP2X F100.

Out Run runs better using the upper memory now than using the Linux memory!!!

Probably because things get reordered and they better fit into cache.

I've forgot one check in r2 (which could cause problems), so please use r3:
http://notaz.gp2x.de/releases/mmuhack_wiz_r3.zip

I dont see much change in with it on or off always around slighly about 13 fps. CPU must be the bottleneck.

What are you testing it on?

 

[Exophase]

ok I've found the problem, I shouldn't have removed the AP bits. Apparently faults happen then, and kernel removes C B bits. Here is the fixed version:

http://notaz.gp2x.de/releases/mmuhack_wiz_r2.zip

Looks like it gives a few FPS more, probably due to Exophase's version suffering those strange cache problems.

No, it's probably because I wasn't turning on caching, just write buffer (iirc). Reading from the framebuffer is usually a good indication that you're doing something wrong, although if you need it for sake of having more memory that's another story. I definitely don't get more speed with yours than mine, it's the same.

QUOTE (notaz)
Probably because things get reordered and they better fit into cache.


I find this a little suspect. How much faster are we really talking? I get a ton of drift in my measurements for some reason, it's actually pretty strange.

Avoiding way collisions to the extent that it significantly improves performance is dumb luck at best, especially on 4-way set associative cache. What may be more likely is better spatial locality of reference which decreases the number of row precharge/address commands on the memory, but I find this unlikely as well since usually a row is smaller than a page.

 

[Pickle]

opps, im running quake2. Just tried version 3 no change.
I noticed this:

mmuhack: loaded, will use 02a00000-0fffffff (42MB RAM used by Linux)
mmuhack: MMU hack applied (0 entries)

That should more than 0 right? Franxis has over 4000. Im not specifically using the upper memory, but it should effect the fb right?

 

[Franxis]

, so please use r3:
http://notaz.gp2x.de/releases/mmuhack_wiz_r3.zip

Ok, thank you for all

 

[Franxis]

That should more than 0 right? Franxis has over 4000. Im not specifically using the upper memory, but it should effect the fb right?

It has to be entries!. If 0 is reported it seems the MMU Hack has not been applied!. You should move the MMU Hack just after the mmap() of the upper memory area. If you are using SDL i don't know where you have to put it (maybe just after the SDL initialization?).

 

[Pickle]

Thanks for the hint:
quake2:
rmmod: mmuhack: No such file or directory
Using ./mmuhack.ko
mmuhack: loaded, will use 02a00000-0fffffff (42MB RAM used by Linux)
mmuhack: MMU hack applied (39 entries)
MMU hack loaded

Still not much faster still around 13.5 fps


Tyr-sdlquake with and without 25.5 fps

Using ./mmuhack.ko
mmuhack: loaded, will use 02a00000-0fffffff (42MB RAM used by Linux)
mmuhack: MMU hack applied (600 entries)
MMU hack loaded

 

[Franxis]

I find this a little suspect. How much faster are we really talking? I get a ton of drift in my measurements for some reason, it's actually pretty strange.

Yes, i have also experienced minor changes leading to extreme variations in the performance. Examples:
- Changing a variable or function static<->global.
- Use 48-64MB upper memory instead of 42-64MB.
- Removing dead code.
- Minor changes in the compilation options.
- Compiling dynamically instead of statically.
- Compiling with DevKitGp2x instead of the Linux toolchain.
Could it be performance variations due to the code fitting better or worse in the cache?
But it is really strange because it didn't appear in the GP2X, and the GP2X has the same cache total size and cache page size as the WIZ.
Could it be a bottleneck in the memory bus? It shouldn't because it is 16bit 2x frequency Vs 32bit
Could it be something weird in the GPH Linux port, drivers or configuration? Or just the hardware?

 

[Franxis]

MMU hack loaded

Still not much faster still around 13.5 fps

Tyr-sdlquake with and without 25.5 fps

Using ./mmuhack.ko
mmuhack: loaded, will use 02a00000-0fffffff (42MB RAM used by Linux)
mmuhack: MMU hack applied (600 entries)
MMU hack loaded


It has no sense, it has to be faster. If the MMU hack is applied correctly you should see graphic artifacts (to be solved using flushcache()). Just to try, move the MMU Hack just before playing but after seeing something in the screen (e.g. the intro).

 

[Pickle]

MMU hack loaded

Still not much faster still around 13.5 fps

Tyr-sdlquake with and without 25.5 fps

Using ./mmuhack.ko
mmuhack: loaded, will use 02a00000-0fffffff (42MB RAM used by Linux)
mmuhack: MMU hack applied (600 entries"]
MMU hack loaded[/quote]It has no sense, it has to be faster. If the MMU hack is applied correctly you should see graphic artifacts (to be solved using flushcache()). Just to try, move the MMU Hack just before playing but after seeing something in the screen (e.g. the intro).


I put it right before the while loop starts in both quakes, everything should be init by then. I suppose I could put it right before the SDL_Flip?

Update: I put the it in the frame flip area in tyr-sdlqauke and still got 600 entries and got 20 fps eck!

 

[Exophase]

Yes, i have also experienced minor changes leading to extreme variations in the performance. Examples:
- Changing a variable or function static<->global.
- Use 48-64MB upper memory instead of 42-64MB.
- Removing dead code.
- Minor changes in the compilation options.
- Compiling dynamically instead of statically.
- Compiling with DevKitGp2x instead of the Linux toolchain.
Could it be performance variations due to the code fitting better or worse in the cache?
But it is really strange because it didn't appear in the GP2X, and the GP2X has the same cache total size and cache page size as the WIZ.
Could it be a bottleneck in the memory bus? It shouldn't because it is 16bit 2x frequency Vs 32bit
Could it be something weird in the GPH Linux port, drivers or configuration? Or just the hardware?

I don't know, but the best thing you can do is to study and try to gain a better understanding of why things are this way. The dynamic vs static is especially worrisome. Usually in cases where you don't know why one thing is a lot slower than the other you're not hitting anywhere close to an optimal speed and it pays to understand why instead of just going with what works best.

QUOTE ('Franxis')
It has no sense, it has to be faster. If the MMU hack is applied correctly you should see graphic artifacts (to be solved using flushcache()). Just to try, move the MMU Hack just before playing but after seeing something in the screen (e.g. the intro).


I think this indicates a lack of understanding of what the mmuhack is doing. You'll only see graphical artifacts if you have cache coherency problems with the higher memory, and normally that will only happen if you're reading to the framebuffer as you're writing to it. Not reading in bulk, because the framebuffer is much bigger than the cache. If you're reading from it a scanline at a time then you should stop because you're thrashing through cache. Instead you should be going to an intermediate buffer.

Normally the framebuffer is just written to, and because ARM9 is strictly read allocate only memory only written to will never enter the cache. If you're not reading from the framebuffer in piecemeal small enough to fit in the cache then you won't see visual artifacts.

 

[notaz]

. Reading from the framebuffer is usually a good indication that you're doing something wrong, although if you need it for sake of having more memory that's another story. I definitely don't get more speed with yours than mine, it's the same.

Yeah, same thing with PicoDrive. No effect on cache enable and no need for cache flushing when enabled, as I never read from framebuffer. Also the improvement seems to be rather negligible in my case, no more then 5%, Pickle probably also gets something like that, just that because of other bottlenecks and low fps it's almost impossible to notice.

But I think default mmuhack should enable caching for those who may need it, it should cause no harm if caching is not needed (if no reading is done).

Probably because things get reordered and they better fit into cache.

I find this a little suspect. How much faster are we really talking? I get a ton of drift in my measurements for some reason, it's actually pretty strange.

Could be some undocumented implementation details we are dealing with here.