GP2X Any Update On 2nd Cpu?

[dwelch]

Okay, so I made a fuss over something I already had.

http://www.dwelch.com/gp2x/simple940t20060710a.zip

Is a simple 940T example that does something (blinks the battery led).

Basically rlyeh's library already has a function for loading and starting the second cpu, I just had to get hit over the head with it....(his library is included here, VERY slightly modified).

The simple led example is mine. Now that I am at this point I just need to borrow/re-invent the video library so that I can print text to the screen, then I can have some fun...

David

 

[aapje89]

I don't know what this exactly means but hopefully it will be something usefull
cheers

 

[STTrife]

hope you can invent some nice stuff for the coprocessor

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

 

[yaustar]

Yes and I believe it is already being done by someone.

 

[Radek]

hope you can invent some nice stuff for the coprocessor

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

Yes.

There is a problem of memory bandwith what must be shared between both cores. But with some carefull thinking... it should provide an improvement.

 

[MadDog]

hope you can invent some nice stuff for the coprocessor

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

This is exactly what i'm doing in my 3D engine. As with the first gen HW cards i'm using the 940 as a poly pusher. Remeber, it was only when the GForce256 came along did these cards render 3d in HW, before they were just 2d poly monsters. I'm not doing the 3d math on the 940 as I wanted to balance the load a bit better but i'm finding the 940 is still max'd out. But then my test apps have no game logic so its looking good. I'm sure what i've done others are doing to, things have gone a bit silent but then thats because we've been beavering away. I've had to get clipping working and write some model conversion apps.

 

[Dzz]

This is exactly what i'm doing in my 3D engine. As with the first gen HW cards i'm using the 940 as a poly pusher. Remeber, it was only when the GForce256 came along did these cards render 3d in HW, before they were just 2d poly monsters. I'm not doing the 3d math on the 940 as I wanted to balance the load a bit better but i'm finding the 940 is still max'd out. But then my test apps have no game logic so its looking good. I'm sure what i've done others are doing to, things have gone a bit silent but then thats because we've been beavering away. I've had to get clipping working and write some model conversion apps.

And I'm doing something similar with the 3D engine that I work on occasionally, except I'm doing geometry and triangle setup on the 940 but doing rasterization on the 920. It's not really working yet, but it's a plan at least.

 

[dwelch]

hope you can invent some nice stuff for the coprocessor

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

I dont think it is as simple as a fork(), remember this is an embedded platform (or should be treated as such), not a desktop (there is more to programming it than just calling apis). This is not an SMP, but two separate processors. Basically that means you have to (IMO) do your system engineering, do two completely independent software developments and have the two communicate through the registers and interrupts between these cores.

Yes unfortunately it is a shared memory AFAIK, but both sides have caches. As I learn more I can post more, the kind of things I like to do are related to knowing what the hardware does and watching it in action. Start with dhrystone tests to see just how much of a difference the cache makes, etc. (The thing I most enjoy about benchmarking is showing that the compiler has more to do with performance than the hardware, same platform, same lines of code, same or different compilers give dramatically different results) Eventually, hopefully, do some tests to see how well the caches prevent the two cores from fighting over system memory. Unfortunately this is mostly application specific. What I can do, perhaps, is provide some examples so that other developers can separate a module from their program, see how it performs when run linearly on a single cpu. then see what it does if run parallel on the second cpu. I guess one test would be to have the 920 beat up on the 940s memory while the 940 is trying to run, have both of them turn off their caches, see just how much performance you lose, if you do. Will the two, running parallel, competing for memory, run slower than one running linearly? Anyone know if this is zero wait state memory, I assume it is a 32 bit memory bus? If not, then all hope is lost, its back to the crippled GBA days. Since I dont hear _any_ talk of thumb mode on this platform then I have to assume it is 32 bit zero wait state. (I will know soon enough, as soon as I get text on the screen I can run some arm vs thumb tests).

David

 

[BradN]

I think the memory clock runs half as fast as the processor clock, since it was mentioned that running above 266MHz would overclock the memory as well. I'm sure it has a 32 bit memory bus; it would be insane not to.

 

[MadDog]

I think the memory clock runs half as fast as the processor clock, since it was mentioned that running above 266MHz would overclock the memory as well. I'm sure it has a 32 bit memory bus; it would be insane not to.

Does feel like quick ram, I had a pocketPC with a 200meg arm9 and that was very slow if you did a lot of ram access. The gp2x in my experiance does not get bogged down in ram access that much, although as one would expect when the ram is cached its a lot quicker.

Would be good to know the cost of a cache miss, bit of reading maybe, if its in one of the docs.

( 360 and ps3 are at between 450 and 550 cycle stall if they miss thier level2 cache!!! )

 

[rixed]

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

Another example of this idea working here :

https://gna.org/projects/gpu940/

Please don't steal the demo code in sample dir, for this is my upcoming contribution to DZZ demo compo

 

[dwelch]

My idea (I don't know very much about hardware) was to create a two thread library where you would specify the 3d output of your program and the thread on the second processor would read it and render it to the screen (like openGL + 3d hardware does)

That way we have some kind of 3d acceleration in a library and still have the first processor free for compiling the 3d scene and doing the game logic.

Would this be possible?

Another example of this idea working here :

https://gna.org/projects/gpu940/

Please don't steal the demo code in sample dir, for this is my upcoming contribution to DZZ demo compo

Can I at least look at it? I am struggling between the sdk2x and rlyehs to get a pixel on the display from the 940. I can blink the battery led, no problem, just cant figure out how to get anything else to show life.

Magic Eyes also advertises that of the nine resources attached to the memory, four can operate in parallel. Now certainly not the same blocks or physical memory chips, but, I assume that means you could have say one doing i/o, another ram, another maybe the nand nvram. So if one core is designed to be i/o bound and the other processor bound you should be able to get more than one processors worth of performance. I think the trick is understanding the design and working with it...Clearly GPH thought it was a good idea to put some video decoding over there...

Anyway, so I am stuck trying to figure out how to get some pixels on the screen, or at least get some text out of the thing (without linux). I bought one of those samsung cell phone serial port adapters as I had seen a page around here somewhere describing how to modify it to be a uart cable for a gp2x. But the connector doesnt quite fit in the hole and I dont want to force it. Maybe I have to shave it down or something (RTFM), not sure. Oh, so anyway, I assume that linux has already setup most of the hardware, certainly all of the programming of the clock system and things like that. Just before bringing the 940 up, I have text on the screen from rlyehs library, I am not doing anything in the 940 to the display, why does it turn off?

This is probably another dumb question, is there an emulator out that will at least boot rev 2 of the firmware? That has open source? That would make it REAL EASY to simply capture all activity in the 0xC0000000 and other register spaces to understand how they brought the hardware up. I dont expect a dual core emulator, not where I am headed on this, just want to understand what order to program things, what is or should already be setup and what isnt...I know there are at least a half a dozen or more people on this site that have done this, and there is example code, I just cannot get the (ahh I get it) lightbulb to go off...

David

 

[Dzz]

I am struggling between the sdk2x and rlyehs to get a pixel on the display from the 940.

You know (or can easily find out) the physical address of the frame buffers. Assuming you haven't changed to a funky video mode, the format of that memory is just a 320x240 array of 16-bit color values. Simply write the colors you want to see to this array.

If you like, you can use whatever section of physical memory that you want to as your frame buffer, so you don't even have to find the memory being currently used for that purpose. Then when you're done "drawing" into that memory, just tell the MMSP2 to make it the current display by setting registers (rlyeh's code has the registers to set to do this).

What part of the process are you having difficulty with or not getting the lightbulb on?

 

[Squidge]

Don't forget that the 940 has an offset applied to all addresses, so the frame buffer address (and all io registers/etc) will be at a different address on the 940 to what they are on the 920.

That being said, something simple like...

volatile unsigned short *fbaddr = (unsigned short *)0x00101000;

while (1)
{
		for (c = 0; c < 153600; c ++)
		{
			fbaddr[c] ^= 0xFFFF;
		}
}

Should work as a simple frame buffer manipulator when the code is placed at 0x03000000. If placed at any other address, modify the address of the frame buffer appropriately.

 

[dwelch]

Don't forget that the 940 has an offset applied to all addresses, so the frame buffer address (and all io registers/etc) will be at a different address on the 940 to what they are on the 920.

That being said, something simple like...

volatile unsigned short *fbaddr = (unsigned short *)0x00101000;

while (1)
{
		for (c = 0; c < 153600; c ++)
		{
			fbaddr[c] ^= 0xFFFF;
		}
}

Should work as a simple frame buffer manipulator when the code is placed at 0x03000000. If placed at any other address, modify the address of the frame buffer appropriately.

That is what I tried, or thought I tried, I will try again. Basically the backlight goes on. The 0x4 bit in GPIOH (H2) does not turn it back on. not sure what turned it off in the first place. Basically I am using rlyeh's code to load the 940 and start it. With the exception that I removed the shared memory code (well then later I changed it to use file i/o (different than what he had www.dwelch.com/gp2x).

Basically if I did everything right, or rlyeh did everything right. shutting down the 940, disabling interrupts on the shared registers. Setting the base address of the 940 to 0x03, copying the 940 code to 0x03000000. and brining the 940 back up. both rlyeh's and demo6b did this pretty much the same way. Anyway, I print Hello World! on the display before loading and starting the 940, shouldnt that stay on the display after I start the 940?

This isnt brain surgery, I must have some subtle dumb thing going on here...Even just blinking the led, you would think that the 0x0a00 register, that had just worked on the 920 before would work on the 940, but I had to re-write/initialize a couple of registers. The last two items in the sdk2x timer init. I re-installed linux just in case I had hosed it.

It seems as if when I start the 940 I am doing something to the 920, perhaps causing an interrupt or fault perhaps. I am trying to avoid setting up the MPU or anything on the 940, as, again, the system should already be operating and setup with the exception of 940 specific stuff like the MPU, and even there the 940 should run without the MPU being setup, its just slow right?

Sorry, rambling. Thanks for the help, will try all of this again from scratch, assembler only test program on the 940 to avoid any issues there...

David

 

[dwelch]

That is what I tried, or thought I tried, I will try again.

It works now. 940 starts up, can write to 0x00101000, changes the pixels on the screen.

Okay I was the idiot (obviously) I had left code in to toggle H2, probably shouldnt be messing with that bit anyway...

Thanks,
David

 

[dwelch]

http://www.dwelch.com/gp2x/

Two problems still. The 940 is not performing as well as the 920, perhaps that is all cache. Second problem, I am assuming that by default this is running 200mhz. The timer count is based on 7372800 if I remember right, so there should be 27 cpu clocks to timer clocks, if the 940 has no interruptions, the same program/benchmark should run in the same amount of time each time, not vary by more than a single clock tick. And it is. Which I assume means there is either a 920 event or conflict delaying the 940 or something in the hardware causing the randomnmess in execution time. It didnt seem to matter if the 920 was left in an infinite loop (in theory completely bound within the cache and cpu). Or if I left it in a while(1) loop waiting for a key to be hit (I/O and cache bound).

 

[rixed]

The 940 by defaults start with no cache whatsoever.

This is *very* slow.

You should at least enable protection unit with a single big segment of cacheable/write-bufferable memory.

There are some code samples here and there (in gpu940, that's located in bin/crt0.S IIRC).

 

[dwelch]

Same site as above, I added thumb mode tests. Thumb is a bit slower than arm, as it should be...

 

[dwelch]

The 940 by defaults start with no cache whatsoever.

This is *very* slow.

You should at least enable protection unit with a single big segment of cacheable/write-bufferable memory.

There are some code samples here and there (in gpu940, that's located in bin/crt0.S IIRC).

This demonstrates 1) compiler differences (the single most important factor if you are interested in performance, most developers assume all compilers are created equal, one is as good as another) 2) that the system is very slow and that the cache and write buffer are band aids there to help.

Two technical questions that I have not studied or asked yet. Is the memory, by default, set for max speed (least wait states)? Is it reliable if there is a way to speed it up?

Am I correct, the cpu(s) run at a default of 200mhz, the memory is at this 7372800hz? A 27 to 1 difference, kind of like running 75mhz memories on a 2ghz desktop.

Has there been a study of cpu clock speed to performance to battery life? For example if you over clock to 250mhz, do you get 25% more performance? Does it use more or less than 25% more battery? Does running at 100mhz give you twice the battery life (assuming you can slow the clock down that much).

Does the timer roll over at 0xFFFFFFFF? I had some funny stuff happen last night and if it rolls over sooner that would explain it.

David