Who Actually Plans To Use The Second Cpu??

[Radek]

I've been reading up on ARM assembly recently so I know a little about the way a single ARM runs, but I still have limited knowledge especially on dual CPUs (in any configuration), but it seems to me that one would have to use the primary processor to pass instructions into RAM for the secondary processor to execute? Or is there a way to have part of the binary passed automatically to the second processor?

​

The 940 core (second cpu in gp2x) doesn't have a MMU. Except that it's fully functional but there are memory mapping issues because of it. There will be workarounds of course as it's used for videoplaying function already.

Once all this gets figured out it will not big deal.

Lets have some patience... results surely will show.

 

[urielka]

a nice way to use the 2nd core will be using it as a 3D chip just running a mesa3D port in the 2nd core so it will be like a openGL(not ES!) 3d chip waiting to be used in 3D games(the problem is to run mesa3d without a X11 just from SDL,which is slow).
i think in emulators it can used as second chip emulation(GPU,Sound chip and etc).
it is realy petty that it doesn`t have a MMU coz then it will be a SMP machine meaning that linux will see the two processors and make a load control to the two cpus.
maybe it will posible to run on the second core uclinux(http://www.uclinux.org/) which doesn`t need a MMU.

 

[Squidge]

The main problem we have with the second processor is that it is excellent for a pure processing engine, but can be quite poor with general purpose code due to the fact that the address bus is shared between the two processors, so if your data doesn't fit in the cache, using both processors will actually be slightly slower than using one.

I found this on my snes emu - I tried to use the second processor as part of the snes's PPU - passing it a display list of what needed doing for each frame (eg. build the screen using these tiles), but the result was a 1 fps increase, which I found I also got by moving the the 940 code into the 920. I then ripped out all that code and slightly optimized it in place for version .2 and got a 10 - 15fps increase.

So, the 940 is a good workhorse, but if it's constantly accessing the address bus, then it'll just slow down the 920 to the point that you may as well just use the one processor.

It'll probably be quite decent for a 3D engine, as you wouldn't be passing much information to the processor, and it would be doing lots of calculations whilst the 920 could be doing other things.

 

[Ferentix]

So as long as you keep the 940 from accessing RAM memory too much, that's best? So anything that can be done using the 940s registers alone with only ocasional memory access is best? Or am I reading this wrong?

 

[abigsmurf]

The main problem we have with the second processor is that it is excellent for a pure processing engine, but can be quite poor with general purpose code due to the fact that the address bus is shared between the two processors, so if your data doesn't fit in the cache, using both processors will actually be slightly slower than using one.

I found this on my snes emu - I tried to use the second processor as part of the snes's PPU - passing it a display list of what needed doing for each frame (eg. build the screen using these tiles), but the result was a 1 fps increase, which I found I also got by moving the the 940 code into the 920. I then ripped out all that code and slightly optimized it in place for version .2 and got a 10 - 15fps increase.

So, the 940 is a good workhorse, but if it's constantly accessing the address bus, then it'll just slow down the 920 to the point that you may as well just use the one processor.

It'll probably be quite decent for a 3D engine, as you wouldn't be passing much information to the processor, and it would be doing lots of calculations whilst the 920 could be doing other things.

​

how fast is the 1st CPU able to pass info to the second CPU? If you've got the first CPU handling lots of threads taking up it's runtime, would it be faster to pass the most intensive commands to the second CPU? Rather than have it eat up runtime with square roots, trig functions, large floating point division etc. it could pass the values to the second CPU strait away to calculate. As the 2nd CPU could devote 100% of it's runtime to this, thoeretically if there's enough bandwidth it could complete this far quicker than the first CPU which already has a heavy load.

Could be talking rubbish mind ;^^

 

[urielka]

so the best is to run cpu-bound code on the 2nd CPU?
like all the pyshics of the game in the 2nd cpu?

 

[Firefox]

I've got the second CPU running nicely in my port of the Jaguar emulator now, and it does provide quite a nice speedup.

However, I think it only works as well as it does for me because the part of the emulator (part of the emulated graphics processor to be precise) that I've moved into it just about fits into the 940T's 4kB instruction cache, and all of the routine's frequently-accessed data fits into the data cache. So basically the only memory accesses it makes are infrequent reads and writes to the shared memory that holds the emulated Jaguar's RAM, and one write per pixel per frame to the GP2X's framebuffer.

I think there's a big future for the GP2X's second CPU, but I think it will be for things like polygon rendering and sound synthesis rather than running large application programs.

 

[Squidge]

So as long as you keep the 940 from accessing RAM memory too much, that's best? So anything that can be done using the 940s registers alone with only ocasional memory access is best? Or am I reading this wrong?

​

Mostly correct, youve got 4KB of data and instruction cache, so you can freely use these are much as you like, but as soon as you get cache misses, your hitting the address bus, which is bad.

You can pass stuff to and from the second cpu pretty damn quickly, but under linux your really restricted to use shared memory (>32MB) in an uncached/unbuffered mode.

 

[Radek]

The main problem we have with the second processor is that it is excellent for a pure processing engine, but can be quite poor with general purpose code due to the fact that the address bus is shared between the two processors, so if your data doesn't fit in the cache, using both processors will actually be slightly slower than using one.

When a task is bandwidth limited then it's normal. All multicore systems will show similiar phenomenon.

I found this on my snes emu - I tried to use the second processor as part of the snes's PPU - passing it a display list of what needed doing for each frame (eg. build the screen using these tiles), but the result was a 1 fps increase, which I found I also got by moving the the 940 code into the 920. I then ripped out all that code and slightly optimized it in place for version .2 and got a 10 - 15fps increase.

So, the 940 is a good workhorse, but if it's constantly accessing the address bus, then it'll just slow down the 920 to the point that you may as well just use the one processor.

Can the 940 caches be locked and then flushed by programmer? Or perhaps use a reverse approach - use 920 as coprocessor with locked caches (it has much bigger ones) and 940 for general purpose computing?
(I'm assuming the mmu issue would be solved)

 

[Firefox]

You can pass stuff to and from the second cpu pretty damn quickly, but under linux your really restricted to use shared memory (>32MB) in an uncached/unbuffered mode.

I've been having a bit of a think about that... You could have your shared memory area in the 920T's / Linux's cached memory, *if* you went and read enough data from somewhere else that the 920T's data cache would be flushed before it was time for the 940T to access it. I think there's even a Linux API for flushing the caches somewhere...

The main problem I thought of was finding the physical address of your block of shared memory... But if the worst comes to the worst I suppose you could just write a signature to the start of the shared memory from the 920T and then get the 940T to scan for it.

 

[vic20-ian]

I've got the second CPU running nicely in my port of the Jaguar emulator now, and it does provide quite a nice speedup.

However, I think it only works as well as it does for me because the part of the emulator (part of the emulated graphics processor to be precise) that I've moved into it just about fits into the 940T's 4kB instruction cache, and all of the routine's frequently-accessed data fits into the data cache. So basically the only memory accesses it makes are infrequent reads and writes to the shared memory that holds the emulated Jaguar's RAM, and one write per pixel per frame to the GP2X's framebuffer.

I think there's a big future for the GP2X's second CPU, but I think it will be for things like polygon rendering and sound synthesis rather than running large application programs.

​

Is it ready for a Firefox techdemo ?

 

[Firefox]

Is it ready for a Firefox techdemo ?

​

There's a mini update over here:

http://www.gp32x.de/board/index.php?showtopic=23844&st=30