Any Update On 2nd Cpu?


Squidge posted on Dec 3 2005 at 01:40 PM said:
Ok, I'll knock up an example program and post it in this thread.
Oh How I do enjoy these super smart debates!
 
Last edited by a moderator:
Squidge posted on Dec 3 2005 at 03:40 PM said:
Ok, I'll knock up an example program and post it in this thread.
Teaching is the ultimate hack ;)
 
Last edited by a moderator:
mr.mirko posted on Dec 3 2005 at 04:21 AM said:
dioxide posted on Dec 3 2005 at 05:28 AM said:
As it says on the main website:
ARM920T : Host processor
ARM940T : Video Coprocessor

I think the 2nd one is for 2D Video

The second core is only used for DIVX decoding !
Not for displaying the Video to the Screen .

The 2D display unit, is a seperate unit from the two cores.

Even using ARM940T for sound processing like DS does with ARM7 will help relieve main CPU a lot. I still believe creative thinking will get us a lot, whereas naysayers will get us nothing.
 
Last edited by a moderator:
And I don't know why mr.mirko keeps saying "They can't acess the same memory" over and over without completing the sentence with "at the same time". To me, the setup sounds more like cheap PC whereas GPU is using part of main memory for graphics processing, rather than typical DualCPU setup, which is a whole different story.
 
Ok...

Source code here:
http://ibiblio.org/paulc/gp2x-gen/dualcpu.zip

The second core's code just constantly inverts the LCD by reading the contents, XORing with 0xFFFF and writing it back (eg. orange changes to blue and back, black to white and back, etc...) as well as supports simple addition and subtraction through memory used by both processors. (920 provides operands, 940 provides results).

It gives this output to the serial port:

[root@Linux gp2x]$/mnt/sd/squidge
hello world!
/dev/mem opened successfully - fd = 3
mmap(0, 10000, 3, 1, 3, C0000000) ... OK! (40001000)
mmap(0, 100000, 3, 1, 3, 3000000) ... OK! (40011000)
hold 940 in reset
No interrupts please
Old contents (to see if second proc run) -> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0001000C 0000FFF3 0000FFCB 00000060 000001FC 0001000C 00010004 00000000 00010000 00051160 00053BEC 0001000C 00010004 00000000 00010000 00000038 FACE0000 DEADBEEF 00000000 Copy 940 code to 0x03000000

Copy start 656 bytes
Copy complete
Zero arm940 stack
ok
allow 940 to run
ARM940 now supposedly running, check LCD! New contents of arm940control = 3
testing maths functions in second processor to make sure it's running
26 + 42 = 68 !
3456 - 123 = 3333 !
920 program completed. leaving 940 program running.
[root@Linux gp2x]$

If you don't have a serial port, you'll need to rename the output file from "squidge" to "squidge.gpe". If you want to see the output for yourself, write a script to redirect output to sd card.

For the people wondering what FACE0000 and DEADBEEF are doing above - they are placed there at the very beginning of the 940 code, and were used to make sure the 940 was running code before the LCD code was implemented. They are still useful, so I've left them in for this version.
 
mr.mirko posted on Dec 2 2005 at 01:45 PM said:
Have look to the Windows world, and see How mutch more fps you get, changing your Athlon64 to an Athlon64x2, dual core cpu.
It will speed up nothing !
You must rewrite the code... -> its damm hard --> nobody wants to waste 6MONTH in rewriting code. To get ONE Emulator ~5fps faster. (if the emulator is now running with 10fps, the second core could give it 15fps)

Um, the second CPU doesn't have an MMU, which is the real problem. And you're right, adding another CPU core doesn't help with the FPS..... why?

Because the CPU isn't doing that work!

However, if you add another VIDEO CARD (another actual CPU that is WORKING ON THE DRAWING) in a SLI like setup, you can get up to 185% of the speeds of a SINGLE GPU.

Just like a Kernel compile is ALOT faster on that dual CPU setup than it is on a single CPU setup. BECAUSE THE CPU IS DOING THAT WORK.

Using the second CPU WILL help, and lots, don't kid yourselves. And people will rewrite their code to use it.

Anyone who doesn't think that people will utilize every last drop of resources that this device has to offer is insane.
 
Last edited by a moderator:
If the linux OS for the GP2X is open source then surely something can be done to at least let the OS take advantage of the second CPU when running an app?

Or is the OS currently left to manage absolutely nothing when a app starts?
 
mr.mirko posted on Dec 2 2005 at 10:40 PM said:
It was possible to run some basic Homebrew GBA programms on the emulator, but not eaven one commercial one was running.
Completely false, the final versions of it ran suprisingly many and advanced games, including Golden Sun, Wario Wares, Fortress, International Karate, Wario Land and many more. Please do not make stuff up and belittle someone elses emulator just to further your own argument.
 
Last edited by a moderator:
now that there's a tech demo of both CPUs working, why not do a simple benchmark to show the speed of both of the CPUs when working in tandem. Have both CPU's generate a random number then square root it (simple but computationally expensive thing, especially on ARMs) each time outputting the total number calculated to the screen and writing to a file, do this for 10 seconds or so (depending on how quickly it would fill up a file) and see how many calculations it manages. Then do a version using only the main CPU.

It should show how capable the CPUs are when competing for resources and bandwidth
 
If the above "dualcore" program doesn't work on your console, it's most likely because GPH have started disabling things in the kernel startup in current firmwares to lower power consumption.

So, to get it running, simply add the following code somewhere in the file that upload the code. I've placed it after it allows the 940 the run, but you can place it earlier on if you like - just make sure it runs before it tries to do the maths stuff :)

unsigned short sysclken;
sysclken = ReadPhys (0x0904);
if ((sysclken & 1) == 0) WritePhys (0x0904, sysclken | 1);

This enables the clock to the second core.
 
Parkydr posted on Dec 3 2005 at 07:25 PM said:
Part of the problem for seems to be the lack of an MMU.  Could anything be done with ucLinux which doesn't require an MMU?


Sure there could be stuff done with the Arm940t under linux, just start your movie player and you'll see ;) The problem is the second core or call it cpu, wasn't made with programs in mind. It is just there to encode DivX and Xvid content as fast as possible, and does that job pretty well. -I guess it will be pretty hard to use that core for emulation purpose, homebrew programs however could benefit greatly from that second cpu...
 
Last edited by a moderator:
So in a nutshell the GP2x and the GP32 aren't so different power wise.... bar the extra ram, extra few mhz, sd slot, usbs and extra buttons...wait a mo that is quite alot LoL but nothing to really push the GP2x that far out ahead of its old pal the gp32
 
mattyrb posted on Dec 3 2005 at 04:06 PM said:
So in a nutshell the GP2x and the GP32 aren't so different power wise.... bar the extra ram, extra few mhz, sd slot, usbs and extra buttons...wait a mo that is quite alot LoL but nothing to really push the GP2x that far out ahead of its old pal the gp32

dotn forget the Tv-Out :p
 
Last edited by a moderator:
Back
Top