I think the last I heard was late 2004 for the Cell "supercomputer on a chip" for the Gamecube. But who knows.
That would be for the PS3, not the Gamecube. And it'll probably end up being mostly hype, just like the current PS2's "emotion engine" was unimpressive.
That would be for the PS3, not the Gamecube. And it'll probably end up being mostly hype, just like the current PS2's "emotion engine" was unimpressive.
I don't think it'll be mostly hype this time around. There is nothing that says it'll be PowerPC, however, and based on the interview with the IBM architect I suspect that it is not.
I was told that the Ps2 was going to use 3 emotion chips, one for sound, one for graphics, and the other for AI etc. My source works in the game industry, mainly for developing on Xbox, however he does do business with the othe platforms as well..
I was told that the Ps2 was going to use 3 emotion chips, one for sound, one for graphics, and the other for AI etc. My source works in the game industry, mainly for developing on Xbox, however he does do business with the othe platforms as well..
I assume you meant PS3, and I'd say he doesn't know anything about it.
If you mean the iMac would be updated to a cpu w/out Altivec/Velocity Engine/VMX, I doubt that. Maybe the iBook and/or eMac, but not the iMac. I think going to a cpu w/out SIMD could very well be the death of that line. But then again in the immortal words of Rosanne Rosanna Danna,"you just never know Mr. Fader".
I'm referring to mojave which is rumored to get altivec. That would give the entire line altivec, make X look faster and give an overall power boost to the entire line. The 970 would be in the POWERmacs and pbooks only for a while.
I would never suggest taking altivec away from the iMac or eMac, you're already committed to it.
I'm not sure how Apple would implement their robust DMA (direct memory access, so that hard drives, optical drives, external devices, PCI and AGP cards can read and write directly to RAM without bugging the CPU with every request or clogging its bus with their data) on a Gobi board.
Check out the Opteron -- built-in memory controller, smokin' DMA performance.
IBM will probably use RapidIO which ought to be plenty fast for the I/O requirements of the Apple systems.
That's actually not what I was wondering; I'm assuming that a RapidIO fabric will open up motherboard design possibilities that will astonish us.
I was wondering about the problem more from a logistical perspective, and I will admit upfront that the problem almost certainly lies with my own lack of understanding of the hardware involved: Essentially, my question to those who know is, given an on-die memory controller that only implements as much as the CPU requires, how do you add a more general DMA engine? Is it just as simple as designing one, and sticking it between RAM and the CPU (but then, don't you have to have a sort of memory controller to determine what goes to the CPU?!). Am I missing the point entirely?
That's actually not what I was wondering; I'm assuming that a RapidIO fabric will open up motherboard design possibilities that will astonish us.
I was wondering about the problem more from a logistical perspective, and I will admit upfront that the problem almost certainly lies with my own lack of understanding of the hardware involved: Essentially, my question to those who know is, given an on-die memory controller that only implements as much as the CPU requires, how do you add a more general DMA engine? Is it just as simple as designing one, and sticking it between RAM and the CPU (but then, don't you have to have a sort of memory controller to determine what goes to the CPU?!). Am I missing the point entirely?
Please enlighten a poor applications programmer.
Well, it is really very simple. At the moment we have a memory bus that connects the RAM chips to the front side bus of the CPU (I know you know this, I'm not being condescending). The connection is managed by the memory controller (lets call it the System Controler) that has all sorts of other functions hooked up to a secondary bus (PCI at the moment I think).
One option to put the memory controller on chip is to split the memory controller portion of the SC out and put it onto the die of the CPU. So all memory requests (DMA included) comes from the RAM, onto the chip and then the memory controller on the die splits the results into those destined for the CPU (which has a really fast/wide connection into the cache hierarchy) or send it to the SC via a second bus built into the CPU. So you still have two buses (existing CPU's often have frontside and backside, but this time they both hook into an on die memory controller not an off-die memory controller and external cache.
"But all the memory traffic is using the precious frontside bus bandwidth!" I hear peple say. Well, no. The frontside bus bandwidth is now entirely on die, and the bus between CPU and memory is now the one that used to exist between the SC and the RAM. The on die frontside bus is still exclusively used for data between the CPU and the memory controller. The interface between the RAM and the on-die memory controller can now be made much faster because traces on the motherboard can be shortened and you remove the latency of the trip through the SC. The interface between the on-die memory controller and the SC can be sped up for the same reasons, and the SC can still use the various busses out of the other end at a variety of speeds.
Could you please explain each bus you refer to. I'm having trouble understanding exactly what busses between what components in your system exist.
Write down the components involved without any boxes (processor core, memory controller, DMA engine, AGP bus, etc). Draw lines between parts that need to exchange data. Make 2 copies. Now on one copy draw boxes around the things you know are gathered onto a single chip. Now on the other copy draw the same thing except this time keep the memory controller in the processor box, not the chipset box. Voila.
Logically an on-chip memory controller is no different than the current scheme. Physically it has moved from the chipset silicon to the processor silicon. The bus connecting it to other chips is just a detail. They could use MPX if they wanted other processors, including the DMA engine, to access it. RapidIO just replaces MPX and happens to be faster, cheaper, and have a more flexible addressing scheme. The same goes for the 970's FSB. Rather than the processor sending memory requests across the FSB the DMA engine (and anybody else) sends requests across the FSB.
Internally to the processor die the chip is probably still divided into core and memory controller, connected by some kind of high speed on-chip bus. Since that is internal to the chip it doesn't really matter to anyone except the chip designer, aside from how it performs.
Things get more complicated in the face of multiple memory controllers. In this situation different chips are assigned different physical address ranges and something like RapidIO is needed to route requests to the right chip based on the address. The scheme extends easily to large numbers of memory controllers which don't necessarily have to be the same type or speed. Consider the GPU, for example. A processor can issue a read/write request to an address in the GPU's address range, it is carried across the AGP bus to the GPU's memory controller which responds with the correct data and sends it back to the requesting chip.
I'm referring to mojave which is rumored to get altivec. That would give the entire line altivec, make X look faster and give an overall power boost to the entire line. The 970 would be in the POWERmacs and pbooks only for a while.
I would never suggest taking altivec away from the iMac or eMac, you're already committed to it.
Over in the "970 die photo" discussion, there is a posting that shows what all the components are. I was amazed to see how small the VPU (vector processing unit?) is compared with other parts of the CPU. It strikes me that adding AltiVec to a G3 really wouldn't involve much real estate on the die.
Over in the "970 die photo" discussion, there is a posting that shows what all the components are. I was amazed to see how small the VPU (vector processing unit?) is compared with other parts of the CPU. It strikes me that adding AltiVec to a G3 really wouldn't involve much real estate on the die.
Keep in mind that the G3 is much smaller than the 970 -- around 1/8th the transistor count. This means the AltiVec unit would roughly double the size of the G3.
Presuming that IBM and Apple are really interested in further G3 development, and they plan to enhance it with AltiVec, DDR support, RapidIO and, hopefully, one more FPU, how well, do you think, it can scale with its 5-stage pipeline? If I see the thing right, the enhanced G3 should perform better than the current G4 at the same clock rate. This might give G3 more life than many expect. Does anyone know anything for sure about G3 development beyond PPC750FX?
Presuming that IBM and Apple are really interested in further G3 development, and they plan to enhance it with AltiVec, DDR support, RapidIO and, hopefully, one more FPU, how well, do you think, it can scale with its 5-stage pipeline? If I see the thing right, the enhanced G3 should perform better than the current G4 at the same clock rate. This might give G3 more life than many expect. Does anyone know anything for sure about G3 development beyond PPC750FX?
I think the G4 or any G4-ish processors may not have much of a life left in Apples computers. Not much more than a year or a year and a half. by the time the 980 is ready for production I think most of Apples products will sport the 64-bit breed, maybe except from the iBooks for some time. So even if the ppc970 proves to be better than the current G4, I think the only reason Apple wants this processor right now is to become independant from Motorola. Or maybe Apple fears that the 7457 are never going to see the light of day, and is afraid to be stuck at 1.2-1.4 ghz in the iBooks and eMacs for some time if developement of the G4 halts.
Speaking of scaling. I really don't see the 750 go much further than 2ghz. But that will be sufficient for some time to come.
Comments
Originally posted by Rhumgod
I think the last I heard was late 2004 for the Cell "supercomputer on a chip" for the Gamecube. But who knows.
That would be for the PS3, not the Gamecube. And it'll probably end up being mostly hype, just like the current PS2's "emotion engine" was unimpressive.
Originally posted by Gizzmonic
That would be for the PS3, not the Gamecube. And it'll probably end up being mostly hype, just like the current PS2's "emotion engine" was unimpressive.
I don't think it'll be mostly hype this time around. There is nothing that says it'll be PowerPC, however, and based on the interview with the IBM architect I suspect that it is not.
Originally posted by mattyj
I was told that the Ps2 was going to use 3 emotion chips, one for sound, one for graphics, and the other for AI etc. My source works in the game industry, mainly for developing on Xbox, however he does do business with the othe platforms as well..
I assume you meant PS3, and I'd say he doesn't know anything about it.
g
Originally posted by rickag
If you mean the iMac would be updated to a cpu w/out Altivec/Velocity Engine/VMX, I doubt that. Maybe the iBook and/or eMac, but not the iMac. I think going to a cpu w/out SIMD could very well be the death of that line. But then again in the immortal words of Rosanne Rosanna Danna,"you just never know Mr. Fader".
I'm referring to mojave which is rumored to get altivec. That would give the entire line altivec, make X look faster and give an overall power boost to the entire line. The 970 would be in the POWERmacs and pbooks only for a while.
I would never suggest taking altivec away from the iMac or eMac, you're already committed to it.
Originally posted by thegelding
and for the gringos out there...it is pronounced mo-ha-vee
g
Actually, that's the spanish literate way to pronounce it, the red-neck gringo way is mo-ja-vey.
Originally posted by Amorph
I'm not sure how Apple would implement their robust DMA (direct memory access, so that hard drives, optical drives, external devices, PCI and AGP cards can read and write directly to RAM without bugging the CPU with every request or clogging its bus with their data) on a Gobi board.
Check out the Opteron -- built-in memory controller, smokin' DMA performance.
Originally posted by wmf
Check out the Opteron -- built-in memory controller, smokin' DMA performance.
IBM will probably use RapidIO which ought to be plenty fast for the I/O requirements of the Apple systems.
Originally posted by thegelding
and for the gringos out there...it is pronounced mo-ha-vee
g
"I am a gringo. I have no bunghole."
Originally posted by Programmer
IBM will probably use RapidIO which ought to be plenty fast for the I/O requirements of the Apple systems.
That's actually not what I was wondering; I'm assuming that a RapidIO fabric will open up motherboard design possibilities that will astonish us.
I was wondering about the problem more from a logistical perspective, and I will admit upfront that the problem almost certainly lies with my own lack of understanding of the hardware involved: Essentially, my question to those who know is, given an on-die memory controller that only implements as much as the CPU requires, how do you add a more general DMA engine? Is it just as simple as designing one, and sticking it between RAM and the CPU (but then, don't you have to have a sort of memory controller to determine what goes to the CPU?!). Am I missing the point entirely?
Please enlighten a poor applications programmer.
Originally posted by Amorph
That's actually not what I was wondering; I'm assuming that a RapidIO fabric will open up motherboard design possibilities that will astonish us.
I was wondering about the problem more from a logistical perspective, and I will admit upfront that the problem almost certainly lies with my own lack of understanding of the hardware involved: Essentially, my question to those who know is, given an on-die memory controller that only implements as much as the CPU requires, how do you add a more general DMA engine? Is it just as simple as designing one, and sticking it between RAM and the CPU (but then, don't you have to have a sort of memory controller to determine what goes to the CPU?!). Am I missing the point entirely?
Please enlighten a poor applications programmer.
Well, it is really very simple. At the moment we have a memory bus that connects the RAM chips to the front side bus of the CPU (I know you know this, I'm not being condescending). The connection is managed by the memory controller (lets call it the System Controler) that has all sorts of other functions hooked up to a secondary bus (PCI at the moment I think).
One option to put the memory controller on chip is to split the memory controller portion of the SC out and put it onto the die of the CPU. So all memory requests (DMA included) comes from the RAM, onto the chip and then the memory controller on the die splits the results into those destined for the CPU (which has a really fast/wide connection into the cache hierarchy) or send it to the SC via a second bus built into the CPU. So you still have two buses (existing CPU's often have frontside and backside, but this time they both hook into an on die memory controller not an off-die memory controller and external cache.
"But all the memory traffic is using the precious frontside bus bandwidth!" I hear peple say. Well, no. The frontside bus bandwidth is now entirely on die, and the bus between CPU and memory is now the one that used to exist between the SC and the RAM. The on die frontside bus is still exclusively used for data between the CPU and the memory controller. The interface between the RAM and the on-die memory controller can now be made much faster because traces on the motherboard can be shortened and you remove the latency of the trip through the SC. The interface between the on-die memory controller and the SC can be sped up for the same reasons, and the SC can still use the various busses out of the other end at a variety of speeds.
Hope this helps
Could you please explain each bus you refer to. I'm having trouble understanding exactly what busses between what components in your system exist.
Barto
Originally posted by Barto
*head hurting*
Could you please explain each bus you refer to. I'm having trouble understanding exactly what busses between what components in your system exist.
Write down the components involved without any boxes (processor core, memory controller, DMA engine, AGP bus, etc). Draw lines between parts that need to exchange data. Make 2 copies. Now on one copy draw boxes around the things you know are gathered onto a single chip. Now on the other copy draw the same thing except this time keep the memory controller in the processor box, not the chipset box. Voila.
Logically an on-chip memory controller is no different than the current scheme. Physically it has moved from the chipset silicon to the processor silicon. The bus connecting it to other chips is just a detail. They could use MPX if they wanted other processors, including the DMA engine, to access it. RapidIO just replaces MPX and happens to be faster, cheaper, and have a more flexible addressing scheme. The same goes for the 970's FSB. Rather than the processor sending memory requests across the FSB the DMA engine (and anybody else) sends requests across the FSB.
Internally to the processor die the chip is probably still divided into core and memory controller, connected by some kind of high speed on-chip bus. Since that is internal to the chip it doesn't really matter to anyone except the chip designer, aside from how it performs.
Things get more complicated in the face of multiple memory controllers. In this situation different chips are assigned different physical address ranges and something like RapidIO is needed to route requests to the right chip based on the address. The scheme extends easily to large numbers of memory controllers which don't necessarily have to be the same type or speed. Consider the GPU, for example. A processor can issue a read/write request to an address in the GPU's address range, it is carried across the AGP bus to the GPU's memory controller which responds with the correct data and sends it back to the requesting chip.
Originally posted by KidRed
I'm referring to mojave which is rumored to get altivec. That would give the entire line altivec, make X look faster and give an overall power boost to the entire line. The 970 would be in the POWERmacs and pbooks only for a while.
I would never suggest taking altivec away from the iMac or eMac, you're already committed to it.
Opps, sorry.
Originally posted by snoopy
Over in the "970 die photo" discussion, there is a posting that shows what all the components are. I was amazed to see how small the VPU (vector processing unit?) is compared with other parts of the CPU. It strikes me that adding AltiVec to a G3 really wouldn't involve much real estate on the die.
Keep in mind that the G3 is much smaller than the 970 -- around 1/8th the transistor count. This means the AltiVec unit would roughly double the size of the G3.
Originally posted by costique
Presuming that IBM and Apple are really interested in further G3 development, and they plan to enhance it with AltiVec, DDR support, RapidIO and, hopefully, one more FPU, how well, do you think, it can scale with its 5-stage pipeline? If I see the thing right, the enhanced G3 should perform better than the current G4 at the same clock rate. This might give G3 more life than many expect. Does anyone know anything for sure about G3 development beyond PPC750FX?
I think the G4 or any G4-ish processors may not have much of a life left in Apples computers. Not much more than a year or a year and a half. by the time the 980 is ready for production I think most of Apples products will sport the 64-bit breed, maybe except from the iBooks for some time. So even if the ppc970 proves to be better than the current G4, I think the only reason Apple wants this processor right now is to become independant from Motorola. Or maybe Apple fears that the 7457 are never going to see the light of day, and is afraid to be stuck at 1.2-1.4 ghz in the iBooks and eMacs for some time if developement of the G4 halts.
Speaking of scaling. I really don't see the 750 go much further than 2ghz. But that will be sufficient for some time to come.