Mmuhack para Wiz por Exophase

[nintiendo1]

Exophase acaba de un mmuhack para la Wiz. Os dejo aquí su post:


I wrote an mmuhack that follows the old fashioned technique that Squidge first introduced. In other words, something that modifies sys_newuname rather than a kernel module (since I can't write those w/o source). However, it is different from Squidge's in a couple ways. First, it scans /proc/kallsyms (or /proc/ksyms if it can't load that) to get the address of sys_newuname, so it shouldn't be as prone to breaking between kernel versions. Second, it flushes icache/dcache between uname patches - this is vital or it won't work for coherency issues (it is self modifying code afterall). Third, it does some sanity checks to make sure the process is working as expected along the way.

I tried to flush icache/dcache in the usual GP2X way (with syscall 0x9F0002) but it didn't work. Maybe you have to do icache/dcache separately now instead of it merging the two, I don't know, I didn't investigate. Instead I just wrote some functions to flush all of icache/dcache in software by loading in new things. If anyone can point out an alternative that'd be good. I tried making the dcache flush load the icache flush routine instead of from a BSS section area but that failed to work - it might be that text section things are not data cacheable.

Anyway, here are the files:

http://exophase.devzero.co.uk/wiz_mmuhack.c
http://exophase.devzero.co.uk/asm_util.S

I'm getting as much as 2ms per frame improvement or more (hard to tell exactly, timing is really inconsistent for some reason) so it's definitely worth it, even if your program just writes to the whole framebuffer once per frame (Temper potentially does multiple, for BG and sprites).

Edit: Still doesn't work all the time, not at all sure why. Just keep trying it until it does, I guess :/ (tell me if anyone has any ideas)

[Raydenito]

¿¿Pero no decia que no estaba mu contento con la Wiz??

[Rivroner]

¿¿Pero no decia que no estaba mu contento con la Wiz??

Pues por eso intenta arreglar la velocidad de respuesta de la ram.

Y sí, tampoco le gustaban los controles pero es un coder y al fin y al cabo les gusta programar, juegan más bien poco :D [wei]

[pakoito]

Dijo que sin el MMUHACK las aplicaciones cargaban peor que en la 2x...con él ya se vería.

[AOJ]

Puede ganar hasta 2ms extra por frame? Esto es una pasada!

A ver si consiguen perfeccionarlo entre todos. O aún mejor, a ver si GPH suelta el código fuente y pone las cosas más fáciles.

[Rivroner]

Todo este proceso tb lo pasó la GP2X, al final los emuladores iban casi el doble de rápido que en los primeros meses.Supongo que pa verano como mucho ya tendremos los emus de GP2X corriendo realmente el doble de rápido que en GP2X , no como ahora que corren muy poco más rápido y eso con más del doble de mhz.

[Puck2099]

A ver si consiguen perfeccionarlo entre todos. O aún mejor, a ver si GPH suelta el código fuente y pone las cosas más fáciles.

El código lo ha soltado a algunas personas, lógicamente hasta que no salga a la venta no van a soltar nada de código a disposición de todo el mundo.

[nintiendo1]

El código lo ha soltado a algunas personas, lógicamente hasta que no salga a la venta no van a soltar nada de código a disposición de todo el mundo.

La pregunta es si lo soltarán cuando salga la consola, aunque por tu frase parece que si...

Saludos.

< - >


It seems to work just like my original on the gp2x :)

kk = frames/sec.

Without MMU hack:
root@wiz:/mnt/sd# ./fbtest.gpe
The framebuffer device was opened successfully.
320x240, 16bpp
The framebuffer device was mapped to memory successfully.
kk = 1, time = 1199554732
kk = 101, time = 1199554733
kk = 152, time = 1199554734
kk = 153, time = 1199554735
kk = 152, time = 1199554736
kk = 152, time = 1199554737
kk = 152, time = 1199554738
kk = 153, time = 1199554739
kk = 152, time = 1199554740
kk = 152, time = 1199554741
kk = 152, time = 1199554742
kk = 152, time = 1199554743
kk = 153, time = 1199554744
kk = 152, time = 1199554745
kk = 152, time = 1199554746
kk = 152, time = 1199554747
kk = 152, time = 1199554748
kk = 153, time = 1199554749
kk = 152, time = 1199554750
kk = 152, time = 1199554751

with MMU hack

root@wiz:/mnt/sd# ./fbtestmmu.gpe
The framebuffer device was opened successfully.
320x240, 16bpp
The framebuffer device was mapped to memory successfully.
got uname location 533a8
uname backup: e1a0c00d e92dd810 e24cb004 e1a04000
uname now: e3a000a3 e12fff1e e24cb004 e1a04000
test 1: expected 0xA3, got a3
uname now: e3a000e9 e12fff1e e24cb004 e1a04000
test 2: expected 0xE9, got e9
modifying pagetable at 1d00000
hacking coarse pagetable entry mapping to 2a00000
hacking coarse pagetable entry mapping to 2a00000
[snip!]
kk = 1, time = 1199554908
kk = 186, time = 1199554909
kk = 236, time = 1199554910
kk = 236, time = 1199554911
kk = 236, time = 1199554912
kk = 236, time = 1199554913
kk = 235, time = 1199554914
kk = 236, time = 1199554915
kk = 236, time = 1199554916
kk = 236, time = 1199554917

55% improvement. Nice!

Nice work Exophase, now all we need is a kernel module :)


:rever::rever::rever::rever::rever::rever:

Viva el Exophase [wei5][wei5]

Saludos.

[Raydenito]

Un 55 % de mejora :asomb:

Madredelamorhermoso...

[Bizkaitarra]

Y eso que es, ¿una especie de librería o algo, que optimiza?

[Puck2099]

Y eso que es, ¿una especie de librería o algo, que optimiza?

Cachea la memoria para acelerar los accesos.

[Ozius]

puf, que buena mejora sí señor. A ver cuanto mejora el mame cuando lo integre franxis y nos hacemos una buena idea del potencial de la consola

[doble-h]

cuanta ram tiene la wiz? y la gp2x?

[Bizkaitarra]

Cachea la memoria para acelerar los accesos.
Ajam, ta bien el asunto, una especie de paginación en más baja escala esta bien
Supongo que en cada programa se usará como una librería o similar no? es lo que no entiendo muy bien, si es así o no.

[Franxis]

puf, que buena mejora sí señor. A ver cuanto mejora el mame cuando lo integre franxis y nos hacemos una buena idea del potencial de la consola

El MAME gana muy poco de velocidad (quizás un 5%) en el modo de video normal, como en la gp2x, ya que el acceso a la memoria alta se reduce a escribir en el framebuffer completo de video cada FPS (utilizando el memcpy() en ensamblador ARM). Si que se gana algo más de rendimiento al usar el modo de video escalado de 16 bit, ya que implica bastante más trabajo que los memcpy().

Lo que si que se gana es en poder cargar juegos más grandes, ya que puedo usar la memoria alta como la RAM accesible con Linux con la misma velocidad (en teoría, en la práctica estoy teniendo algunos problemas con "algo" que usa parte de la memoria alta y que al sobreescribirlo me produce relentizaciones horrendas, a ver si doy con ese "algo").

[Ozius]

El MAME gana muy poco de velocidad (quizás un 5%) en el modo de video normal, como en la gp2x, ya que el acceso a la memoria alta se reduce a escribir en el framebuffer completo de video cada FPS (utilizando el memcpy() en ensamblador ARM). Si que se gana algo más de rendimiento al usar el modo de video escalado de 16 bit, ya que implica bastante más trabajo que los memcpy().

Lo que si que se gana es en poder cargar juegos más grandes, ya que puedo usar la memoria alta como la RAM accesible con Linux con la misma velocidad (en teoría, en la práctica estoy teniendo algunos problemas con "algo" que usa parte de la memoria alta y que al sobreescribirlo me produce relentizaciones horrendas, a ver si doy con ese "algo").

Bueno, algo es algo, si sirve para la carga de juegos más grandes tampoco está mal.

Lo raro es que se siga teniendo problemas con los accesos a toda la RAM y no lo hayan solucionado de alguna forma los de gph con la wiz.

[Puck2099]

Bueno, algo es algo, si sirve para la carga de juegos más grandes tampoco está mal.

Lo raro es que se siga teniendo problemas con los accesos a toda la RAM y no lo hayan solucionado de alguna forma los de gph con la wiz.

El problema está en que la RAM a la que no "se puede" acceder la usa el sistema para ciertos asuntos que nosotros nos los saltamos a la torera al programar a bajo nivel, por eso es normal que los de GPH no hagan nada para "solucionarlo".

[Ozius]

El problema está en que la RAM a la que no "se puede" acceder la usa el sistema para ciertos asuntos que nosotros nos los saltamos a la torera al programar a bajo nivel, por eso es normal que los de GPH no hagan nada para "solucionarlo".

ya, me lo imaginaba que sería memoria "protegida" para uso del sistema, pero se reservaban bastante cantidad de RAM no? al final es una puñeta caparle a los usuarios el usar todo el potencial del hardware.

[Puck2099]

ya, me lo imaginaba que sería memoria "protegida" para uso del sistema, pero se reservaban bastante cantidad de RAM no? al final es una puñeta caparle a los usuarios el usar todo el potencial del hardware.

Tampoco tanta, de 64 MB hay 42 MB visibles, el resto es para el framebuffer, el buffer de sonido y el 3D.

Los de GPH tienen que dejarlo de forma que si alguien quiere poner un juego 3D no tenga que andar tocando registros porque otro juego ha escrito cosas en esa zona y no la ha vuelto a dejar como se la encontró.

[hardyx]

El MAME gana muy poco de velocidad (quizás un 5%) en el modo de video normal, como en la gp2x, ya que el acceso a la memoria alta se reduce a escribir en el framebuffer completo de video cada FPS (utilizando el memcpy() en ensamblador ARM).
Y de usar funciones en ensamblador de ARM como memcpy, memcmp, memset, a usar las de la librería de C también se nota bastante la diferencia de rendimiento ¿verdad?

[Franxis]

Y de usar funciones en ensamblador de ARM como memcpy, memcmp, memset, a usar las de la librería de C también se nota bastante la diferencia de rendimiento ¿verdad?

si claro