2nd Processor Possible To Use In Emulation?

[Brash]

I heard some speculation about using the 2nd processor by authors of emulators for the gp2x.. however i am sceptical if this can be touched.

it says in the specs that this is a video processor. so doesn't that mean it's only allowed to be used for films? would using this be going against it's grain and cause problems.
also, how is it possible that they can actually tell the processor when to be used if it's not automatically being used now? I wasn't aware that a program running on a computer can actually tell specific parts how to act. i thought you just make a general code and let the computer figure out what to do with it.

is it actually possible to say to the 2nd cpu "hey, wake up! i know you normally dont do this, but i want you to handle this part of the graphics " and say to the first cpu, "and you handle this other portion and work together"?

 

[BradN]

You may consider reading the ARM940T technical reference manual (ie, for the 2nd processor). It is an (almost) fully capable ARM9 core just like the main processor, the two key differences being a smaller cache size (4K+4K vs 16K+16K code and data), and the lack of an MMU.

http://www.arm.com/pdfs/DDI0144B_940T_TRM.pdf

You're somewhat right in your assumption that tasks aren't usually assigned to specific processors in multiprocessor systems - in fact normally linux will pick which CPU to execute a process on, but in the GP2X, the 940 processor has no MMU, so it can't perform the virtual -> physical address mapping required to execute normal linux processes, and therefore it must be explicitly managed by whatever program wishes to utilize it. That program must load whatever code and data it needs into the upper 32MB of memory, and then it can take the 940 out of reset and it'll just start running whatever's there.

Communication between the two processors is accomplished via the upper 32MB of memory, which is easily accessible to both, and there's an interprocessor interrupt system (which currently I don't think is usable in linux because it would require a driver or hack of sorts to handle it) to signal events.

 

[Dzz]

The second processor is not a video processor. It is very similar to the first processor. If used carefully, a complicated program like an emulator should be able to make some sort of use of it. The problems are:

1) The second processor cannot easily talk to linux, so it is not as easy to program all tasks on it. The programmer has to feed it carefully coded work to do.

2) Even though it is a similar processor we probably won't expect a doubling of performance because they share the same memory and sometimes they will fight each other for access to it

3) Most gp2x emulators are ports of emulators written for other platforms, usually by somebody different than the guy doing the port. Changing it to use two processors may be a significant architectural change to the code which could go well beyond the rest of the porting effort in complexity.

4) Emulating a single-processor target is largely a "one thread" sort of task, which makes it hard to split into two parallal pieces.

 

[Ando]

the one guy on the yak-yak forums working on tempest is using both i think

 

[Brash]

okay. so it is possible. just tough.
since the two may not cooperate fully with the emu.. maybe they could keep the standard emu as is with the 1st processor and turn off the sound directions with it and then work on a seperate add-on somehow that would work solely with the 2nd processor to handle just sound.

would you say it is a disadvantage to have that 2nd processor vs them just upping the speed of the first? sounds to me that's what they should have done. One 400mhz cpu.

 

[greven]

I know nothing in coding, but is it possible that the 2nd processor can hanble such tasks as sound (or is there a particular hardware in the gp2x which can handle the sound)?
Squidge made some benchmark if i am correct.
For pure calcul, using both is quicker (2x) but if you have to write a file, it is slower (2x), because they can not access the memory bus (or just the memory ?) in the same time....

 

[bacteria]

Ok, if the PG2x can't use the second processor, why have it? Surely a way for extended battery life would be to not provide power the the second CPU?

Old posts said that the GP2x has 3 processors - 2x CPU's and the third for the tv output option. Disable (as an option) the second CPU and tv CPU and thereby only have the main CPU with power and this should double the battery life!

 

[FluffyPanda]

The second processor is already disabled by default in more recent firmwares. If you don't turn it on in code it doesn't soak up the juice.

The first and second processors have to share the memory bandwidth which can be a limiting factor, but the first processor has quite a lot of cache (16k + 16k) which it can access while the second processor is accessing main memory. Some very clever code could let both processors work at maximum efficiency (loading a 16k sound bank into cache and offloading the entire sound chip emulator to the 920T for example)

They will be used where necessary, I'm sure of that. The second is already essential if you want fluid video decoding.

 

[Radek]

The second processor is already disabled by default in more recent firmwares. If you don't turn it on in code it doesn't soak up the juice.

The first and second processors have to share the memory bandwidth which can be a limiting factor, but the first processor has quite a lot of cache (16k + 16k) which it can access while the second processor is accessing main memory. Some very clever code could let both processors work at maximum efficiency (loading a 16k sound bank into cache and offloading the entire sound chip emulator to the 920T for example)

If a task is cpu cycle limited then bandwith should not be that big issue. For an example using the second cpu for 3d transforms should be quite effective. For bandwitch intensive tasks normal code will not give good results obviously. However there are some tricks what can make it possible nevertheless. So called "tiling" can work and works well thought it needs very rethinking of aplication.

For an example I was using one such scheme in my competition entry to good results (it reduced needed bandwitch to write to the framebuffer drastically - only one write per frame was needed).

They will be used where necessary, I'm sure of that. The second is already essential if you want fluid video decoding.

​

The Arm based cpus are inexpensive in gate counts so including the 940T didn't actually increased the cost of chipset by much. And for the videoplayback the second core is used as the data parser - a task what could be performed by first core as well. The newe chipsets from MagicEyes (manufacturer of current MMSP2) have only one cpu so... it's really puzzling why we have the second cpu. Not that I complain (but it'd be far nicer to have two 920T instead of one 920T and 940T).

 

[Reesy]

I was wondering if the second processor could be used to get around the "interrupts in linux" problem. There could be a small process running that monitors when the LCD moves between HBLANK and VBLANK, this could then be used to provide information about the line currently being rendered. We could also use it to schedule palette updates for partiulcar LCD lines.

 

[nickspoon]

The second processor is used by the first to interface the video processing hardware in GPH's mplayer. This is the only thing it's officially used for at the moment. Some people are beginning to use it for other things. It's quite difficult to use the 940T from within Linux because Linux can't interface it properly (in any other way than an MPEG-4 video decoder).

 

[Julius]

would you say it is a disadvantage to have that 2nd processor vs them just upping the speed of the first? sounds to me that's what they should have done. One 400mhz cpu.

​

It is cheaper, probably drains less power and is better suited for movie playback
But 400mhz would have been nicer for development.

 

[Dzz]

I was wondering if the second processor could be used to get around the "interrupts in linux" problem. There could be a small process running that monitors when the LCD moves between HBLANK and VBLANK, this could then be used to provide information about the line currently being rendered. We could also use it to schedule palette updates for partiulcar LCD lines.

​

This is a nifty idea. The simplest application -- just polling the VBLANK every 0.1ms or so to make sure we don't miss it in the main app -- would be very easy to do and introduce very little memory bandwidth load.

In case people don't know what this issue is: after a screen gets drawn, it's fairly typical to sit in a little loop waiting for the VBLANK to occur so that the screen can be "flipped" to the newly drawn data. If this isn't done, the screen can look jagged because the frame is updated in the middle of drawing one screen. The VBLANK pulse is pretty narrow though -- about 0.3ms by default though I think you can increase it somewhat. So the thread that is looking for the VBLANK needs to be running during that 0.3ms. However, if your app has another thread (for example, to do sound processing), that thread might happen to have the CPU during that time. Or, since linux is a multiprocessing system, some other process might happen to have the CPU during that time. Which means that we might miss the VBLANK and wait for the next one instead, causing a little glitch in the video.


The fancier ideas you mention about using HBLANK are pretty interesting too!

 

[Squidge]

I've been discussing the idea of using the 940 to handle interrupts with some other people, and there doesn't seem to be a way of directing interrupts to a particular processor or both processors.

Was hoping that by disassembling the code that runs by default on the 940, we would find this out, but all the interrupt code does in that is reset the processor :s

My own attempts at playing with interrupts on the 940 has been pretty empty (I've never got an 'interesting' interrupt, such as GPIO-based, to fire)

So I'm assuming the 940 only gets the mailbox interrupts and nothing else, unless someone else can prove otherwise?

 

[Epicenter]

This has been asked for a long time; I had the same idea a while ago as a means to improve MAME performance on more stressful games on machines with multiple processors (back in the Athlon MP days.) But, as it turns out, in an emulator, it's pretty tough to keep 2 different threads for different CPU Cores going and stay synchronized decently. It's the sort of program that really needs to run on its own thread, much like the vast majority of game engines, since in the original hardware everything had instant access to everything else on the PCB-- there was no operating system or thread management to get in the way.

 

[paeryn]

I've been discussing the idea of using the 940 to handle interrupts with some other people, and there doesn't seem to be a way of directing interrupts to a particular processor or both processors.

Was hoping that by disassembling the code that runs by default on the 940, we would find this out, but all the interrupt code does in that is reset the processor :s

My own attempts at playing with interrupts on the 940 has been pretty empty (I've never got an 'interesting' interrupt, such as GPIO-based, to fire)

So I'm assuming the 940 only gets the mailbox interrupts and nothing else, unless someone else can prove otherwise?

​

From how I read the docs, the MMSP2 has a dedicated interrupt block that routes all but the 940 dualprocessor interrupt(s) to the 920. So unless there's some hidden registers that can be set to flip which interrupts go to which CPU, we're stuck.

BTW, if anyone plans on using both CPUs to access the blitter, be careful. There's a HW bug that can cause data corruption if both CPUs try accessing the FastIO registers at the same time. (Read about it in a doc for the WindowsCE drivers)