A Quick Blog Entry About Gp2x Performance..

[Oscaruzzo]

So maybe this kernal of linux will be like the super small Windows kernal that the Xbox uses for it's OS?

For most basic purposes, the kernel (not kernal ) can be seen just like an utility library. It provides you functions (system calls) to manage the hardware in a "high level" way. When you read or write a "file", the kernel manages (amongst other things) all the mapping between the file path and the physical structures on the filesystem. When you allocate some memory, the kernel choses where to put that memory area. When you want write something to a device (screen, audio, SD card) you use a uniform programming interface (open/write/close) and the kernel implements different operations depending on the hardware.

Also, a multitasking OS can at regular intervals switch between different tasks. Different tasks can be assigned different priorities (and if you have only one task working, all the cpu time is assigned to that task).

This is an over-semplification, of course, but I hope it clarifies a little...

 

[Oscaruzzo]

It is more bloaty than what was on the GP32. Any speed gains from the slightly faster CPU will be eaten up by linux putting us back at GP32 speeds.

​

I wonder what makes you think that. Going down from 200Mhz to 133Mhz would mean losing 33% of processing "power". No OS is that heavy.

Don't fear the penguins!

Also, remember that you need device drivers, filesystem, and memory management to write any decent software. So if you dump the kernel, you are doomed to reimplement it

 

[joele]

It is more bloaty than what was on the GP32.

I think we are jumping to conclusions here? Is it really any less efficient and resource hungry than what was on the GP32, can any of the developers with the beta units confirm or deny that?

 

[Alpha2]

Prehaps those that fear Linux in the 2X, compared to the GP32, are of the impression that the GPOS just generally "went away" when you booted up free launcher or otherwise ran a file off the SMC? The name Linux itself carries a bit of weight that might make some think it's too egotistical to stand around in the back ground while you have your merry way with the hardware.

I think they need reassurance that it's not standing there looking over your shoulder the whole time.

 

[DaveC]

It is more bloaty than what was on the GP32.  Any speed gains from the slightly faster CPU will be eaten up by linux putting us back at GP32 speeds.

​

I wonder what makes you think that. Going down from 200Mhz to 133Mhz would mean losing 33% of processing "power". No OS is that heavy.

Don't fear the penguins!

Also, remember that you need device drivers, filesystem, and memory management to write any decent software. So if you dump the kernel, you are doomed to reimplement it

​

The following finding seems to be a strong argument for binning linux for emulation purposes:

...
So, to use both processors properly, we need to either write our own device driver (without being able to rebuild the kernel) or chuck linux in the bin and do away with virtual addresses completely. A lot of devvers are all for throwing linux in the bin just to make life easier.

Chucking Linux in the bin also gives us another thing - lots more memory. The linux kernel and mpeg decoding routines and buffers/etc take up a lot of memory that we can't free in linux (as it's allocated at a physical address in memory on kernel bootup when the driver is initialised) but won't even get allocated if we jump in before linux.

​

Sounds like alot of reasons to go to the hardware directly and bypass linux.

 

[oneandoneis2]

If building something directly into the kernel bothers you, you can compile it as a module that can be loaded & unloaded as needed. . .

 

[Cyclops]

...
So, to use both processors properly, we need to either write our own device driver (without being able to rebuild the kernel) or chuck linux in the bin and do away with virtual addresses completely. A lot of devvers are all for throwing linux in the bin just to make life easier.

Chucking Linux in the bin also gives us another thing - lots more memory. The linux kernel and mpeg decoding routines and buffers/etc take up a lot of memory that we can't free in linux (as it's allocated at a physical address in memory on kernel bootup when the driver is initialised) but won't even get allocated if we jump in before linux.

​

Sounds like alot of reasons to go to the hardware directly and bypass linux.

​

Your actually making a case against the PSP there thats not like you. Even will linux loaded the GP2X has heaps more memory.

 

[DaveC]

Your actually making a case against the PSP there thats not like you. Even will linux loaded the GP2X has heaps more memory.

​

How did that happen?

Well yes there are some advantages of the GP2X over the PSP.

The nice thing about the GP2X is that you CAN bin linux if you want. Flexibility is good

 

[skeezix]

Okay, as a rule..

You never pre-optimize, since its wasted time; you always wait to 'see how it goes' in real usage. So this is all silly to begin with

Secondly.. A kernel is a _fricking great thing_, and not something to be fearted or over-reacting about. While some want to make another, thats really just for fun.. there is no real reason to not use a kernel; maybe the one shipped is not stripped enough.. so be it, you recompile it with less options enabled, or do some custom striping. But this certainly won't be a requirement.

There is also the matter of the other processor core; if the kernel is in a multi-processor mode, that other stuff will likely sit on the second core while the main app is on the other. Nil impact.

Theres a lot to consider here, and non-devs aren't suited to the discussion, and its likely moot anyway. If kernels ate up more than a tiny fraction of a %age of the CPU, would they be in use?

Not even the _Windows_ kernel kills that much

But wait until you've got devices before condemning something; or go try a Unix (BSD or Linux or the like) and see how much the OS takes

jeff

 

[abigsmurf]

Not even the _Windows_ kernel kills that much

​

Yeah gotta leave as much CPU as you can for Explorer to then eat as possible ^^

 

[Jengo]

This is a very interesting Discussion,

Although i am no Programmer, and certainly dont know the in's and outs of this hardware. I do know that in the PC world 2 processors are always better then one. Always.

If we were talking about 2 pentium 2s@ 200mhz each vs 1 Pentium 2@400Mhz And the operating system supported Dual CPUs, And the chipset was a fairly Decent one. There is no way in hell the Single P2@ 400mhz could outclass the Dual P2 Setup, NO WAY. ESPECIALLY if the dual setup had MORE Ram. There is no way in hell. I dont know about you guys but i am truly without doubt that the GP2X will walk all over the PSP in 2D performance. Unless.... Unless, the GP2X had a horrible Chipset Architecture, Unless somehow the people designing the chipset screwed up the data flow between Both CPUs AND Ram, this is a very big part of getting great Performance out of the Two CPUs. It is a BIG necessity that the ram be easily Managed between both CPUs, a great example of ram management in Dual Processor setups would be the Athlon X2 Series of Processors, these guys really knew what they were doing when designing this architecture. Although the AX2 line are in many ways 2 processors on one silicon wafer it IS a dual cored SINGLE processor. but its Dual Cores make it in MANY ways just like a Dual CPU Setup.

I think the GPX2 will be very satisfying for Develpers that know how to use both processors in sync. Hopefully the Ram and CPU managment is Decent so we can see pretty games.

 

[Cyclops]

This is a very interesting Discussion,

Although i am no Programmer, and certainly dont know the in's and outs of this hardware. I do know that in the PC world 2 processors are always better then one. Always.

​

Speaking as one with no experience of dual core(sept in servers and that don't count), I was looking forward to having two processers to see how it worked.(or didn't work). The added complication of there being a 920 and a 940 just made my brain hurt. Always wanted to see two penguins.

Nice to see BSD mentioned. I love to see that working, I've never tried that either. Or reactos. Damn I want XEN(I know its x86).

 

[CoinOp]

The added complication of there being a 920 and a 940 just made my brain hurt. Always wanted to see two penguins.

It is my understanding that the 920T is dual core and the 940T is a dedicated video processor. I'm sure it won't take long for devs to get the hang of the system. Lots of nice reports of stuff easily porting to the system. That means less time porting and more time tweaking.

I for one am really excited about the potential of this box. Once things start getting tweaked out it's going to scream! Now the hard part is just hanging in there till mid Nov.

CoinOp

 

[OrR]

Your understanding is wrong. Read the FAQ.

 

[CoinOp]

Your understanding is wrong. Read the FAQ.

FWIW I found the faq to be unclear about the whole cpu thing.

CPU/Memory/Graphics/Audio Chip Overview: According to doumentation the GP2X hardware "incorporates a Dual 32bit CPU Processor, Video Processor, Video Post Processor, 2D Graphic Processor, Image Signal Processor and a variety of I/O peripheral components" including an AC97 based audio chip. Each of the two ARM CPU cores is clocked at 200Mhz, and there is 64MB RAM and 64MB NAND flash memory. The graphics processor can accelerate 2D graphics, and process various video and image formats. There is no 3D acceleration, however software based 3D is entirely possible...

I found this in the datasheet ...

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz,
>220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz,
>220MIPS), 4KB I-Cache + 4KB D-Cache

I'll admit that I am not a tech guru but these specs look to me that the 920T is a dual core cpu and the 940T is doing the video proccessing. If someone wants to explain this in english and tell me what I'm missing that would be great.

CoinOp

 

[junker]

well, latest news says it's a dual core as in a 920 & 940, and the video processor is seperate.
right?

 

[CoinOp]

Dual 32bit CPU 400+ (Main Processor, Coprocessor) Embedded Architecture
- Main Processor used for Operating System & System Control, Audio Processing: ARM 920T CPU (200MHz,
>220MIPS), 16KB I-Cache + 16KB D-Cache + MMU
- Coprocessor used for Video Header Parsing, Video Post Processor Control: ARM 940T CPU (200MHz,
>220MIPS), 4KB I-Cache + 4KB D-Cache

After re-reading this a few times, it occurred to me that the 920T & the 940T is one chip.
With the 940T making calls to the graphics processor (if it is indeed a separate entity).
Sorry for the confusion, just trying to get this sorted out for my own well being.

CoinOp

 

[CoinOp]

well, latest news says it's a dual core as in a 920 & 940, and the video processor is seperate.
right?

Exactly. I get it now. (whew)

CoinOp

 

[Cyclops]

well, latest news says it's a dual core as in a 920 & 940, and the video processor is seperate.
right?

Exactly. I get it now. (whew)

CoinOp

​

Said it was confusing lol

nice pretty picture its posted elsewhere http://www.mesdigital.com/english/Products/product_mmsp2.asp

 

[skeezix]

This is a very interesting Discussion,

Although i am no Programmer, and certainly dont know the in's and outs of this hardware. I do know that in the PC world 2 processors are always better then one. Always.

If we were talking about 2 pentium 2s@ 200mhz each vs 1 Pentium 2@400Mhz And the operating system supported Dual CPUs, And the chipset was a fairly Decent one. There is no way in hell the Single P2@ 400mhz could outclass the Dual P2 Setup, NO WAY. ESPECIALLY if the dual setup had MORE Ram. There is no way in hell. I dont know about you guys but i am truly without doubt that the GP2X will walk all over the PSP in 2D performance. Unless.... Unless, the GP2X had a horrible Chipset Architecture, Unless somehow the people designing the chipset screwed up the data flow between Both CPUs AND Ram, this is a very big part of getting great Performance out of the Two CPUs. It is a BIG necessity that the ram be easily Managed between both CPUs, a great example of ram management in Dual Processor setups would be the Athlon X2 Series of Processors, these guys really knew what they were doing when designing this architecture. Although the AX2 line are in many ways 2 processors on one silicon wafer it IS a dual cored SINGLE processor. but its Dual Cores make it in MANY ways just like a Dual CPU Setup.

I think the GPX2 will be very satisfying for Develpers that know how to use both processors in sync. Hopefully the Ram and CPU managment is Decent so we can see pretty games.

​

Completely wrong of course

Consider..

If a PC had 2 200MHz processors (not hard to find either; I had one such system board years ago.), what if it was running a non-multi-cpu OS.. such as DOS? It'd run as a 200MHz system with the second chip unused entirely. Easy example

Some OSes and applications can 'automagicly' make use of multiple cores/cpus; its not uncommon these days, but not really common either; some OSes will spread _threads_ (lightweight processes) across CPUs, but others will only spread whole processes, while still others will only spread on demand or as requested (by the OS or applications.) Often it depends on configuration.

So, a single thread application like most apps, and most emus for sure, cannot be magicly made to spread out among CPUs, and so it would not gain much benefit at all from a second chip.

Your error is simple - you're thinking in terms of a PC with a complex OS (Windows say), running desktop stuff (Web browsing, email, all at the same time.) In that case we have an OS reasonably aware of things, able to split up whole processes across CPUs - email on one, mail on the other, say.

But for a game handheld, where one app is running and nothing else.. theres nothing to shove to the other side 'automagically' and you can't magicly' split up an app in two. You've got two highways and one car, and so it doesn't help. If you had two cars (two threads or processes), and one going slow .. one road would suck, but two roads would let the seocnd car fly by the first.

The developers need to add the second car.

jeff