[PORT] GP2X

[Sandman]

Look at this:
"The ARM940T was used by GPH's implementation of Linux to control video processing. Using the 940T core in Linux for other tasks apart from video processing is difficult but possible. Accessing the hardware directly makes it easier to use both CPUs."
Wikipedia is never wrong. ;D Also, in the Magic Eyes documentation it is said: "Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache".

Updating the binaries can be done by a very simple program, much like the "patch" that is done after a firmware update. You just run it, the program updates the libraries and you're done: EVERY game has hardware accelerated stuff. For your own game, you can also just include the shared object with your application, in its folder. It will use it instead of the one in /lib. However there is a downside. There is no FPU in the GP2X, but the official firmware is compiled using hardware floats. This means that it gets emulated at runtime. The alternative is to compile using software floats, which is faster if there is no FPU available. Using static linking, you can use software floats.

The upper 32MB is indeed not 'visible' to Linux. It is non-cached and slow in access, but there is an MMU hack made by Squidge. See here and for the MMU hack under "Speed issue".

[SplinterGU]

I don't said that the people use the 2nd CPU for video... I think that gp2x use it... not people... gp2x... the people can will use 2nd cpu for they wish...

The specs (and soft samples) don't say this that you say... divide memory CPU is only software (SO) definition... not hardware restriction... both CPU can access to whole memory...

[SplinterGU]

Look at this:
"The ARM940T was used by GPH's implementation of Linux to control video processing. Using the 940T core in Linux for other tasks apart from video processing is difficult but possible. Accessing the hardware directly makes it easier to use both CPUs."
Wikipedia is never wrong. ;D Also, in the Magic Eyes documentation it is said: "Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz, >220MIPS), 4KB I-Cache + 4KB D-Cache".

Updating the binaries can be done by a very simple program, much like the "patch" that is done after a firmware update. You just run it, the program updates the libraries and you're done: EVERY game has hardware accelerated stuff. For your own game, you can also just include the shared object with your application, in its folder. It will use it instead of the one in /lib. However there is a downside. There is no FPU in the GP2X, but the official firmware is compiled using hardware floats. This means that it gets emulated at runtime. The alternative is to compile using software floats, which is faster if there is no FPU available. Using static linking, you can use software floats.

The upper 32MB is indeed not 'visible' to Linux. It is non-cached and slow in access, but there is an MMU hack made by Squidge. See here and for the MMU hack under "Speed issue".

indeed... thanks... ;)

drumpi: well, how you can see... here are (somebody without have a gp2x) GOOD programmers... ;)

[Drumpi]

I see :D :D :D
I tried to search post about second core in gp32spain, but is very hard to find (looks like there are a lot of massive posters :P). Just for reference, look at this: http://wiki.gp32spain.com/index.php/Estado_de_la_emulaci%C3%B3n#Sega_Mega_drive (sorry, only spanish)

Adelantó en rendimiento y prestaciones a DrMDx gracias al uso del segundo procesador para el sonido con una calidad de 44Khz

But this is not the question. The question is if it's easy or not to use the second core, for graphics, sound, 3d or else (and how, if you got time to teach a total noob ;D ;D ;D ;D). Scene is scene, people who know programming, but his level... for me are pro, but a monkey with a "hello world" glowing, rotating an jumping in C is a pro for me :P
Meanwhile, i will try to take here some experienced people with gp2x HW.

I hope i'm not bothering you two whit my noob things... and worst english :)

[SplinterGU]

in the url that I tell you, you can found some papers and projects that can help you...

for simplify your task, you can use this...

http://www.symbolengine.com/rlyeh/files/internal_use/readme-c.html

I'll search others utils tools for you...

[SplinterGU]

well, here you have a good post with all stuffs of this...

http://www.gp32x.com/board/index.php?showtopic=27433&st=90#

from startup 2nd CPU, to "LOCKING" mechanism and shared IPC area between CPUs.

good post!

you must read all post from here... some others posts can be useful...

EDIT: ogg940 is good sample too, and have sources.

[Drumpi]

Ok, thanks, i'll take a look... when i have time: between FNTEdit, crap-compo4, "V days" and other university projects i'm TOO busy ;)

[blostec]

Congratulations Sandman, it's a great port. karma++

[Sandman]

Well, I think we may have to check the source of the Fenix port and what optimizations have been done there because these results speak for themselves:

Bennu:

Code Select Expand

Time: 10000ms
Frames: 325
FPS: 32


Fenix:

Code Select Expand

Time: 10000ms
Frames: 588
FPS: 58

To show you that the problem really is that Bennu doesn't use the hardware, I also ran the test with MODE_HARDWARE enabled. This means the final blit from Bennu's screen to the real screen is in fact accelerated. Results:

Code Select Expand

Time: 10000ms
Frames: 344
FPS: 34

Slight speedup there.

So this means there is a lot left to optimize. This is not a problem at this stage though, because the rendering modules are planned to be rewritten anyway, which will allow these kind of optimizations to be implemented more easily. It's an interesting task, but I don't have all the time in the world, so we'll see what comes of it. :)

And you're all anxious to see the test code, I know, so:

Code Select Expand

#ifdef COMPILER_VERSION
import "mod_grproc"
import "mod_video"
import "mod_key"
// import "mod_gp2x"
import "mod_map"
import "mod_rand"
import "mod_proc"
import "mod_say"
import "mod_time"
#endif

#define PROCS 100
#define DEPTH 16
#define RUNTIME 10000

Process Main()
Private
int i;
int g;
int t;
int e;
int f;
Begin

set_mode(320,240,16);
set_fps(0,0);

g = new_map(20,20,DEPTH);
map_clear(0,g,rgb(100,150,200));

for(i=0; i<100; i++)
box(rand(15,305),rand(15,225),0,g);
end

t = get_timer();
e = get_timer()+RUNTIME;

f = 0;
repeat
f++;
frame;
until(get_timer()>e)//key(_esc)||gp2x_getbutton(_GP2X_L))

say("Time: " + (e-t) + "ms");
say("Frames: " + f);
say("FPS: " + f*1000/(e-t));

OnExit

let_me_alone();

End

Process box(int x, int y, int dangle, int graph)
Begin
loop
angle+=dangle;
x=rand(15,305);
y=rand(15,225);
frame;
end
End

[SplinterGU]

please, can you do test without render?

well, this sample don't have nothing important to test....

[Sandman]

Well I certainly wouldn't call blitting unimportant, especially if optimized it can be almost twice as fast. I made a new test, which does... nothing. So let's see.

The test

Code Select Expand

#ifdef COMPILER_VERSION
import "mod_time"
import "mod_video" // enable/disable mod_video
import "mod_say"
import "mod_proc"
#endif

#define RUNTIME 10000

Process Main()
Private
int t;
int e;
int f;
Begin
restore_type = complete_restore; // enable/disable complete_restore
set_mode(320,240,16,MODE_HARDWARE); // enable/disable mode_hardware
set_fps(0,0);

t = get_timer();
e = get_timer()+RUNTIME;

f = 0;
repeat
f++;
frame;
until(get_timer()>e)//key(_esc)||gp2x_getbutton(_GP2X_L))

say("Time: " + (e-t) + "ms");
say("Frames: " + f);
say("FPS: " + f*1000/(e-t));

End

Results

Bennu:

Code Select Expand

Time: 10000ms
Frames: 1154853
FPS: 115485

Bennu +mod_video:

Code Select Expand

Time: 10000ms
Frames: 250053
FPS: 25005

Fenix:

Code Select Expand

Time: 10000ms
Frames: 2047
FPS: 204

Bennu +mod_video +complete_restore:

Code Select Expand

Time: 10000ms
Frames: 1538
FPS: 153

Fenix +complete_restore:

Code Select Expand

Time: 10000ms
Frames: 886
FPS: 88

Bennu +mod_video +complete_restore +mode_hardware:

Code Select Expand

Time: 10000ms
Frames: 5044
FPS: 504

Fenix +complete_restore +mode_hardware:

Code Select Expand

Time: 10000ms
Frames: 5243
FPS: 524

So Bennu beats Fenix until the hardware is kicked in. Bennu's VM is certainly a lot faster than Fenix'. I don't know about the performance of other modules, like mod_sound; they could differ as well. Float operations should be slower in Bennu too, because it's compiled using hardware floats (and there is no FPU, so it gets emulated at runtime) and Fenix with software floats. If it's useful I can test it.

[splinter_work]

I mean, don't have nothing important to test if we cutoff blitting...

begin
frame
end

not really good sample...

but, the core is more faster... indeed...

[Drumpi]

Just if you want to know, the Puck's web page is http://www.gp32wip.com/, in "proyectos" section have the lastest source code (i think it's the same as you get) and more from him. be carefull not to mistake between Fenix and UFenix :D

If you can get a HW acceleration, i think Bennu will get lots of programmers there... and a easy WIZ port (people are porting gp2x libraries to WIZ)

[Sandman]

@SplinterGU:
Ah, I see. :)

@Drumpi:
Aye, I'm using uFenix v0.2, the one I linked earlier. Is there another Fenix GP2X port then?

We'll get HW acceleration eventually, but it would help a lot more if someone with experience with the GP2X would help. One of the problems is that all those guys use static linking and so there are no dynamic version of the libraries we want.

[Drumpi]

No, i said that you get the lastest (i didn't know what version you had).

And maybe you only can get static libraries, sceners preferr static linking.
You can ask in gp32x forum, maybe you'll have more luck than me in gp32spain.

People ignore me, i'm like a ghost :( I will be a ninja.