940t Is Not A Video Coprocessor


judge0

Member
Joined
Oct 3, 2005
Messages
172
Location
Sault Ste Marie, Ontario, Canada
Website
Visit site
Hi, I'm new hear and just want to clarify something. Seems a lot of places including the basic info FAQ here, keep referring to the 940T as a video processor.

If I'm reading the MagicEyes PDF and web based specs correctly the 940T is stripped down 920T ARM processor with 4kb of instruction cache and 4 kb of data cache, with NO MMU. The video processor is an entirely separate entity from the two processors.

The reason I'm posting this is to see if anyone in the know(ie the devrs), happen to know if the linux kernel being used will stay resident in such a small space??

If so, it's possible inclusion of Linux as OS will not impede performance as some posts imply.

If not, then is 940T a good place to hold Floating Point hash tables instead?

thanx
 
I think I read that gph developed the sdk so that all the video instructions are being sent to the 940 processor which essentially makes it a video coprocessor
 
A general purpose processor, but from what i've seen, is used for video processing, not video decoding, but for blitting, rotations, zoom and such.
 
judge0 is closest to the truth, but a bit confused about cache :)

If you're talking about the raw CPU, then there are two general-purpose ARM cores, a 920T and a 940T. The difference between these is indeed in the cache size (920T: 16k + 16k, 940T: 4k + 4k) and the fact that the 940T doesn't have a MMU. Also the 920T is the 940T's master in that the 920T can set a flag to reset the 940T, and it can set the area of main memory that the 940T can access.

The chip also has a "2D graphic processor", an "image signal processor", a "video processor" and other bits and pieces. These are independent units which can (by the look of it) be controlled by either ARM core. They are the units that provide video processing and decoding, blitting, rotations etc.

Now, add MagicEyes' Linux port. Having multiple CPUs in Linux is a bit a pain when the CPUs are not the same type. So rather than making a 2-CPU Linux kernel, MagicEyes have designated that the 940T core will be used for driving the video processing hardware, while the 920T core is the main CPU.

Homebrew software does not need to maintain this distinction if it does not run in Linux. That is, if (when :)) a bootloader is created which enables software to be run without booting Linux, the people developing the software will be able to use the 2 CPU cores and the various extra modules in any way they like. You can certainly use the 940T as a floating-point coprocessor, although I don't think it would speed things up all that much once you sort out the handshaking between the CPUs.

You could put a MMU-less Linux kernel (eg. uclinux) on the second CPU if you like, but that's not how MagicEyes have done it so you'll basically be doing your own Linux port.

Also remember that both cores share one block of RAM. That means that if both are doing heavy memory access, then the system will slow down.
 
Yup, by default the 940 does all the graphics, including mpeg parsing, etc, whilst the 920 is the "main" processor. Linux provides a device called "dualcpu" to talk to the second processor from user applications, but don't expect much more than graphics stuff (it supports sending pointers to mpeg frames, for example).

However, like Robster says, without Linux, the second processor can be used for whatever you like, but the 64MB RAM has to have it's bandwidth shared between them, so the second processor should run code as cache friendly as possible.
 
judge0 posted on Oct 2 2005 at 11:34 PM said:
Hi, I'm new hear and just want to clarify something. Seems a lot of places including the basic info FAQ here, keep referring to the 940T as a video processor.

You're mistaken on the FAQ. I wrote it, and I can tell you I even purposely altered the GPH specs when copying them over to NOT refer to the 940T as just a "video co-processor."

I'm sure you read it someplace else, but not in the basic info FAQ here. Perhaps via a link in the FAQ to GPH's specs (where they list the 940T as a video co-proc).
 
Last edited by a moderator:
He possibly read the GP2X wiki page which someone keeps changing to say that CPU is for graphics even though I keep changing it to read correctly.

Sigh.

-Craig
 
Thanx for the info, Robster & squidge

Apologies to Prophet, I went back and read the FAQ again, I was mistaken or read an earlier version. gp32z.com calls it a video coprocessor, /. calls it a video coprocessor and the wiki as well. I probably jumped the gun on your FAQ, again apologies.

Back in the day when we programmed for CP/M and the v20, v30 etc , we would try to keep a copy of the interrupt vector table in cache memory, by any chance would that be a good use for the second processor? I'm starting to wonder if the overhead of aligning the cycle count for the two processors is as efficient as simply running one processor at say 400 mhz.

Now all I need to do is get my grubby paws on the GP2X and the SDK......
paging Dr Craigix..........soon please?????
 
The Wiki thing is quite frustrating (its correct at the time of speaking!)

As soon as the bug testing is done they will ship out, but we don't want loads of media player errors cropping up, so better to make sure its working 100%.
 
jlebrech posted on Oct 3 2005 at 06:46 AM said:
Mode 7 anyone :p


AFAIK the hardware only supports 90 degree rotation so no hardware "mode 7". It will be quite useful for MAME when playing vertical oriented games to flip 90 deg though. That doesn't mean that it could not be done in software on that second CPU. I am sure some coder will code up one. I would think it would be possible to write a custom tile engine for the second CPU as well that would work like the tile engines in SNES, GBA, MegaDrive etc.
 
Last edited by a moderator:
craigix posted on Oct 3 2005 at 11:14 AM said:
He possibly read the GP2X wiki page which someone keeps changing to say that CPU is for graphics even though I keep changing it to read correctly.

Sigh.

-Craig
Craig, maybe the next time you change it you could specifically state that it is NOT a video co-processor? As in "it is a common misconception that the 2nd CPU is a video co-processor, but it is in fact only used as such by Linux - programs that do not go through Linux can use it in whatever way they wish" or something like that.
 
Last edited by a moderator:
Back
Top