The AC parent nailed it dead on. I've been in the industry for nearly seven years now, and I have some very close friends who work at Nintendo HQ. They have flat out told me that many of the game publishing companies expect Nintendo to come along with a dumptruck of money, and basically pay them in order to make GC games. Why? Because that's what Microsoft does in order to get XBox support. MS has had to bribe everyone in the industry in order to get the amount of third party games onto the shelves that they have. (And, well, it seems to have worked!) But as a result, the XBox division has posted alot of losses since it was started. Yeah, a good portion of it is hardware costs, but don't underestimate the bribery factor. Microsoft is the only company in the world with enough money to buy their way into anything... and they sure bought their way into the video game biz. Sony apparently does some incentives for the big players, but because PS2 games sell tons of units due to the installed base, there's already quite a compelling business case for develpoing PS2 games.
Anyways, back to Nintendo. Rumor has it that the 'cube was making $$$ the first day it was on sale. No one can say that about PS2 or XBox. I was rather impressed. I wouldn't be suprised if the DS and Revolution follow the same path. Nintendo plays by a different set of rules than their competitors, and it looks to me like they will keep the money coming in.. with or without the support of the rest of the industry. Guess we'll see.
Correct. I read the patent ages ago when it came out, and basically it said that within each Cell would be 1 "system" cpu and muliple PS2-style vector units. The vector units would be running the user-level code (all game code, tv decoder / tivo code, etc) and the system cpu would be in charge of divvying out some of the onboard resources to each of the VUs, ensuring security permissions, and stuff like that. Oh, and the system CPU was, IIRC, a PPC core.
------------ begin quote ----------- I'm probably not very interested in this unless I can hack the hardware a bit: add a hard drive, add a second network port, etc.
A GameCube would make a sweet firewall/router box if you could get two network ports on it and Linux. The price would be right too.
Note that the optical drive is fairly useless... ------------- end quote ------------
Here's a little factoid that will make it even less interesting: The broad band adapter (BBA) on the 'cube is only accessable through an 8bit bus that runs... um, shall we say... rather slowly. So slow, in fact, that the adapter is configured (by software) to *NOT communicate at 100base-T* since there's not enough bandwidth to the CPU on that particular bus to support data rates that high. So the OS Libraries put the BBA into 10base-T mode as soon as they come online after bootup.
Apparently, if one watches the lights on the hub / switch that the BBA is connected to, it'll start out at 100base-T when the power is thrown, then downgrade to 10base-T once the game comes up. Disclaimer: I don't have a BBA on my cube, so I've never seen it happen.
Which is fine by me, since I don't play online console games anyways. I'd rather have 3 friends over that stare at the TV by myself. Once again, we see that Nintendo designs hardware to suit their needs (which mesh nicely with mine as a gamer); not to suit others. Enjoy having your DNS server be the slowest box on the LAN.:P
So long as you aren't stalled waiting for memory access, your average PPC chip (regardless of native bit depth) can kick much booty.
In-depth version:
There's little to worry about with porting of apps. Unless you've got some seriously processor dependent assembly in your PPC binary there's little that will stop it from running on a POWER chip.
Well, drat. So much for porting my gamecube engine.:-) No, trolling aside, he brings up a valid point with the following (with which I totally agree) :
Please people, 64-bits does not equal performance, instructions per second is the important factor... It's performance problems come from the low clock speed and the lack of multiple floating point pipelines [that slow down the G4].
Dude, that is _so_ true. PPC64 applications simply have 64-bit data registers / pointers. That's it. All instructions are 32-bit. There is no major speed difference in execution of most instructions (as far as I'm aware, anyways). If you load a 32-bit integer and do some addition on it, the addition is preformed at 64-bit precision. Then you go and store it back as a 32-bit number.
The real key to performance is the memory architecture and the number of instructions that can realistically get dispatched per second (assuming that there are no cache misses). The PPC that I use everyday on the Gamecube is really quite a nice little powerhouse. That tiny machine can run circles around by workstation. Of course, it dosen't have to multitask, and it's severely limited by RAM. But, still, the point is that PPC chips are actually really _good_.
As far as PPC performance is concerned, I think that mostly the limiting factor is memory bandwidth, like on most other machines. I've seen the effect firsthand on the Gamecube. It's got stupid-fast (TM) MoSys memory onboard, which basically has constant access time to _any_ (random) byte onchip. So you can go striding through mem all over the place and the memory system dosen't flinch. Now, the machines' performance is good when I'm writing to memory in the usual fashion, but when I use the onboard write-gather pipe (WGP), you get ~1.3GB/s out to memory. That's better than AGP 4x, right? Anyways, the WGP bypasses all the caches and blasts 32bytes out to memory in 1 bus transaction. Now, observe the effect:
My CPU time to render a certain scene from this one angle went from 3/4 of a frame to 1/4, simply by using the write-gather pipe instead of the usual path out to mem. The computations didn't change at all.. just the writing out to mem. 1 frame is 1/60th of a second, for reference. The scene was composed of geometry that was generated procedurally from some spline data, so it was pretty cpu intensive.
Moral of the story: so long as you aren't stalled waiting for memory access, your average PPC chip (regardless of native bit depth) can kick much booty.
I totally agree. I program GameCube games, and the PPC chip that IBM has supplied in it is just a wonderful little powerhouse. It's a modified 750 core running at 486 Mhz and has got incredible FP performance and ~ 1.6 GB/s out to memory through a special write-gather pipe. The FP can handle paired-singles (anyone see the altivec connection here?), and the machine as a whole is just stupid fast. (Yes, the memory architecture has someting to do with this too...)
Anyways, it totally makes sense for apple to go with a desktop version of the POWER4 core. The PPC specification is such that any program written that targets the UISA (think it stands for something like user instruction set architecture -- ie, non-privelidged instructions) will move right over to any other PPC core w/o a recompile. And the PPC64 spec is such that all instructions are still 32bit; it's just the data / registers that're 64bit. So binary compatibility is a no-brainer.
Couple in the fact that power4 has multiple cores on a die... and, damn. I'll buy my first Apple machine if they actually do this.
Slashdot Mirror
The AC parent nailed it dead on. I've been in the industry for nearly seven years now, and I have some very close friends who work at Nintendo HQ. They have flat out told me that many of the game publishing companies expect Nintendo to come along with a dumptruck of money, and basically pay them in order to make GC games. Why? Because that's what Microsoft does in order to get XBox support. MS has had to bribe everyone in the industry in order to get the amount of third party games onto the shelves that they have. (And, well, it seems to have worked!) But as a result, the XBox division has posted alot of losses since it was started. Yeah, a good portion of it is hardware costs, but don't underestimate the bribery factor. Microsoft is the only company in the world with enough money to buy their way into anything... and they sure bought their way into the video game biz. Sony apparently does some incentives for the big players, but because PS2 games sell tons of units due to the installed base, there's already quite a compelling business case for develpoing PS2 games.
Anyways, back to Nintendo. Rumor has it that the 'cube was making $$$ the first day it was on sale. No one can say that about PS2 or XBox. I was rather impressed. I wouldn't be suprised if the DS and Revolution follow the same path. Nintendo plays by a different set of rules than their competitors, and it looks to me like they will keep the money coming in.. with or without the support of the rest of the industry. Guess we'll see.
Correct. I read the patent ages ago when it came out, and basically it said that within each Cell would be 1 "system" cpu and muliple PS2-style vector units. The vector units would be running the user-level code (all game code, tv decoder / tivo code, etc) and the system cpu would be in charge of divvying out some of the onboard resources to each of the VUs, ensuring security permissions, and stuff like that. Oh, and the system CPU was, IIRC, a PPC core.
It's cool stuff, really.
------------ begin quote -----------
...
:P
I'm probably not very interested in this unless I can hack the hardware a bit: add a hard drive, add a second network port, etc.
A GameCube would make a sweet firewall/router box if you could get two network ports on it and Linux. The price would be right too.
Note that the optical drive is fairly useless
------------- end quote ------------
Here's a little factoid that will make it even less interesting: The broad band adapter (BBA) on the 'cube is only accessable through an 8bit bus that runs... um, shall we say... rather slowly. So slow, in fact, that the adapter is configured (by software) to *NOT communicate at 100base-T* since there's not enough bandwidth to the CPU on that particular bus to support data rates that high. So the OS Libraries put the BBA into 10base-T mode as soon as they come online after bootup.
Apparently, if one watches the lights on the hub / switch that the BBA is connected to, it'll start out at 100base-T when the power is thrown, then downgrade to 10base-T once the game comes up. Disclaimer: I don't have a BBA on my cube, so I've never seen it happen.
Which is fine by me, since I don't play online console games anyways. I'd rather have 3 friends over that stare at the TV by myself. Once again, we see that Nintendo designs hardware to suit their needs (which mesh nicely with mine as a gamer); not to suit others. Enjoy having your DNS server be the slowest box on the LAN.
So long as you aren't stalled waiting for memory access, your average PPC chip (regardless of native bit depth) can kick much booty.
In-depth version:
There's little to worry about with porting of apps. Unless you've got some seriously processor dependent assembly in your PPC binary there's little that will stop it from running on a POWER chip.
Well, drat. So much for porting my gamecube engine.Please people, 64-bits does not equal performance, instructions per second is the important factor... It's performance problems come from the low clock speed and the lack of multiple floating point pipelines [that slow down the G4].
Dude, that is _so_ true. PPC64 applications simply have 64-bit data registers / pointers. That's it. All instructions are 32-bit. There is no major speed difference in execution of most instructions (as far as I'm aware, anyways). If you load a 32-bit integer and do some addition on it, the addition is preformed at 64-bit precision. Then you go and store it back as a 32-bit number.
The real key to performance is the memory architecture and the number of instructions that can realistically get dispatched per second (assuming that there are no cache misses). The PPC that I use everyday on the Gamecube is really quite a nice little powerhouse. That tiny machine can run circles around by workstation. Of course, it dosen't have to multitask, and it's severely limited by RAM. But, still, the point is that PPC chips are actually really _good_.
As far as PPC performance is concerned, I think that mostly the limiting factor is memory bandwidth, like on most other machines. I've seen the effect firsthand on the Gamecube. It's got stupid-fast (TM) MoSys memory onboard, which basically has constant access time to _any_ (random) byte onchip. So you can go striding through mem all over the place and the memory system dosen't flinch. Now, the machines' performance is good when I'm writing to memory in the usual fashion, but when I use the onboard write-gather pipe (WGP), you get ~1.3GB/s out to memory. That's better than AGP 4x, right? Anyways, the WGP bypasses all the caches and blasts 32bytes out to memory in 1 bus transaction. Now, observe the effect:
My CPU time to render a certain scene from this one angle went from 3/4 of a frame to 1/4, simply by using the write-gather pipe instead of the usual path out to mem. The computations didn't change at all.. just the writing out to mem. 1 frame is 1/60th of a second, for reference. The scene was composed of geometry that was generated procedurally from some spline data, so it was pretty cpu intensive.
Moral of the story: so long as you aren't stalled waiting for memory access, your average PPC chip (regardless of native bit depth) can kick much booty.
Try the user manuals found here:
p ro ducts/PowerPC_750CX_and_750CXe_Microprocessor
http://www-3.ibm.com/chips/techlib/techlib.nsf/
I totally agree. I program GameCube games, and the PPC chip that IBM has supplied in it is just a wonderful little powerhouse. It's a modified 750 core running at 486 Mhz and has got incredible FP performance and ~ 1.6 GB/s out to memory through a special write-gather pipe. The FP can handle paired-singles (anyone see the altivec connection here?), and the machine as a whole is just stupid fast. (Yes, the memory architecture has someting to do with this too...)
Anyways, it totally makes sense for apple to go with a desktop version of the POWER4 core. The PPC specification is such that any program written that targets the UISA (think it stands for something like user instruction set architecture -- ie, non-privelidged instructions) will move right over to any other PPC core w/o a recompile. And the PPC64 spec is such that all instructions are still 32bit; it's just the data / registers that're 64bit. So binary compatibility is a no-brainer.
Couple in the fact that power4 has multiple cores on a die... and, damn. I'll buy my first Apple machine if they actually do this.