Duckhuntdog
Member
Fafalada said:
Bill Gates bank roll?
Official *** CELL processor announements **** Thread
- Thread starter sonycowboy
- Start date
Bill Gates bank roll?
Panajev2001a
GAF's Pleasant Genius
rastex said:
Something tells me SCEA is hard at work on Subversion
.
.soundwave05
Member
So is that it for CELL announcements? No fancy Ridge Racer girl or rubber ducky tech demos?
Panajev2001a said:Something tells me SCEA is hard at work on Subversion
Don't know what that is...
One of the really cool things that SCEA is pushing is collada which is an industry-wide standardized asset solution. Considering how popular it gets, it could really simplify the whole pipeline and asset management schemes, which will really help smaller companies.
rastex said:
Well, it's a while since I've had any involvement with Eclipse as a development environment per se, but I'm sure it supports multiple source management systems - Clear Case at least, and almost certainly others. There are plugins available for Subversion (Subclipse), AccuRev, Stellation and others.
DonasaurusRex said:
I'm sure that's possible. The only problem it will bump up against is oversaturation of the PCI bus. Remember, you've got lot's of other things running on that bus as well. Times, they are a changin' though. If STI is as successful as they're hoping, the x86 crowd will have to pick up the slack.
Lot's of games left to be played though. There's just no way this can NOT be interesting.
DonasaurusRex
Online Ho Champ
Yeah PCIe is point to point not shared bus.
Not really. We still have no idea what the actual specs for the PS3 chipset are. This whole discussion is just a product roadmap for the cell architecture. You're not going to see the same component in DVD player as in a workstation.GhaleonEB said:Okay the bar has been set. Get hopping, MS.
So there isn't much for MS to react to.
Phoenix
Member
Panajev2001a said:Uhm... I disagree, it is much worse to have a good CPU paired with a super-super GPU than the opoosite: rendering is not all you do
No, its not all you do - but there is a ratio such that you have a lot of CPU that's sitting around idle most of the time. Since the CPU isn't apparently not involved in any rendering at all, at most its doing is scene graph management, physics, sound, etc. I wouldn't want cray supercomputer power to do those tasks - it would be wasted. Especially since it would drive my hardware costs up significantly.
PS3 CPU should be doing most if not all of the vertex processing - so that kinda involves it in the rendering
Besides, there's stuff like fancier compression algorithms that eat up massive amounts of computation resources(actually that's one of my primary target areas of research for PS3), and physics simulation can be quite a bottomless pit if you really have power to waste
Well I kinda agree - It both improves and breaks things from 6, so it's really a mixed bag
I wasn't a big fan of 1.52, I hated 4.0, I hated 5.0 a little less, I rather liked 6, and now I like .Net a bit less then 6.
Ghost of Bill Gates
Banned
TAJ
Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that.
>>>And an absurdity in overkill considering that the CELL is secondary to the nVidia hardware for rendering. Having an uber CPU that so overpowers the GPU would just be wasteful IMO. Like putting a P4 in a machine with a Rage128 video card <<<<
With a powerful enough CPU, you wouldn't need 3D acceleration. Software renderers are much, much better than hardware-accelerated ones, anyway.
Ideally, you'd have a CPU (MANY teraflops) capable of rendering complex Mental Ray scenes or RIBs (PRMan) in 1/60th of a second or less, coupled with a 2D graphics chip.
With a powerful enough CPU, you wouldn't need 3D acceleration. Software renderers are much, much better than hardware-accelerated ones, anyway.
Ideally, you'd have a CPU (MANY teraflops) capable of rendering complex Mental Ray scenes or RIBs (PRMan) in 1/60th of a second or less, coupled with a 2D graphics chip.
It will be as OpenGL ES 2.0 would be introduced this year:
http://pc.watch.impress.co.jp/docs/2004/0729/kaigai104.htm
Secondly,SCEI didn't join the Khronos group for no reason
Chittagong
Gold Member
Andrew2 said:It will be as OpenGL ES 2.0 would be introduced this year:
http://pc.watch.impress.co.jp/docs/2004/0729/kaigai104.htm
Secondly,SCEI didn't join the Khronos group for no reason
hmm... what was the purpose of ES again? I recall that it'd be a more limited version of the full set, meant for portables etc.
Duckhuntdog
Member
So no one has traveled over to teamxbox for a reaction? GAF dissappoints.
Phoenix
Member
TAJ said:
Whoa, what? A hardware accelerator is just a specific purpose CPU. Now what are you talking about with software renderers being "much, much better than hardware-accelerated ones". Both a CPU and a hardware accelerator just do the mathematical operations for the graphics pipeline. perhaps you'd like to clarify what you're talking about?
Phoenix
Member
Andrew2 said:It will be as OpenGL ES 2.0 would be introduced this year:
http://pc.watch.impress.co.jp/docs/2004/0729/kaigai104.htm
Secondly,SCEI didn't join the Khronos group for no reason
Yes I know they are supporting OpenGL ES, but is it officially a part of the toolchain? They supported OpenGL for the PS2, but it was actually not a part of the official toolchain.
What are we likely to see in Playstation 3 CPU, which should be a second generation implementation of Cell architecture, compared to this first generation implementation of Cell architecture that we're seeing this week?
just a smaller, slightly faster, tweaked version of the chip we see today, or a new chip with parallel/multipul 2nd generation Cell Processors?
just a smaller, slightly faster, tweaked version of the chip we see today, or a new chip with parallel/multipul 2nd generation Cell Processors?
Pimpwerx said:That's nothing really. The beauty of the architecture lies in its scalability and software hierarchy. The power gains are made to come from stacking PEs. So some of the fud from today is that the PS3 will probably see 2 of these cores (PEs) in its CPU. That would be pretty badass IMO. But we'll see how they solve the powerhandling problems. People wigged out at the 85C temp, but I thought that was without a fan. I assume there was a heatsink, or something like it though. We'll see.
Oh yeah, Rambus gets a lot of stick for a company that's still developing great new products. 100GB/s? :O That's just bananas. External bandwidth is really picking up.
I like your post ^___^ sounds good.
but if it's only one PE, they could stuff an extra 8 APUs (now called SPEs) in there. since Cell is meant to be scalable. not just scalable in that you can add more PEs, but scalable in that you can build PEs with more APUs/SPEs.
Looks like Cell is dual-core plus extra (eDRAM?) in this shot. However, that's one focking big ass die, like 600m^2-700mm^2. This is ridiculously large and I'm guessing it's some sort of developement or testing chip on the wafer and the actual production chip is the separate one on top.
From http://pc.watch.impress.co.jp/docs/2005/0208/kaigai153.htm
The architecture...
And then the slides...
The architecture...
And then the slides...
Ars Technica
http://arstechnica.com/articles/paedia/cpu/cell-1.ars
Introducing the Cell Part I: the SIMD processing units
By Jon "Hannibal" Stokes
Introduction
The Cell processor consists of a general-purpose POWERPC processor core connected to eight special-purpose DSP cores. These DSP cores, which IBM calls "synergistic processing elements" (SPE), but I'm going to call "SIMD processing elements" (SPE) because "synergy" is a dumb word, are really the heart of the entire Cell concept. IBM introduced the basic architecture of the SPE today, and they're going to introduce the overall architecture of the complete Cell system in a session tomorrow morning.
In this brief overview, I'm first going to talk in some general terms about the Cell approach what it is, what it's like, what's behind it, etc. before doing an information dump at the end of the article for more technical readers to chew on and debate. Once the conference is over and I get back to Chicago and get settled in, I'll do some more comprehensive coverage of the Cell.
Back to the future, or, what do IBM and Transmeta have in common?
It seems like aeons ago that I first covered Transmeta's unvieling of their VLIW Crusoe processor. The idea that David Ditzel and the other Transmeta cofounders had was to try and re-do the "RISC revolution" by simplifying processor microarchitecture and moving complexity into software. Ditzel thought that out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream had increased processors' microarchitectural complexity to the point where way too much die real-estate was being spent on control functions and too little was being spent on actual execution hardware. Transmeta wanted to move register renaming, instruction reordering and the like into software, thereby simplifying the hardware and making it run faster.
I have no doubt that Ditzel and Co. intended to produce a high-performance processor based on these principles. However, moving core processor functionality into software meant moving it into main memory, and this move put Transmeta's designs on the wrong side of the ever-widening latency gap between the execution units and RAM. TM was notoriously unable to deliver on the intitial performance expectations, but a look at IBM's CELL design shows that Ditzel had the right idea, even if TM's execution was off.
IBM's Cell embodies many of the "RISC redivivus" principles outlined above, but it comes at these concepts from a completely different angle. Like TM, IBM started out with the intention of increasing microprocessor performance, but unlike TM, simplifying processor control logic wasn't the magic ingredient that would make this happen. Instead, IBM attacked from the very outset the problem that TM ran headlong into: the memory latency gap. IBM's solution to the memory latency problem is at once both simple and complex. In its most basic form IBM's Cell does what computer architects have been doing since the first cache was invented Cell moves a small bit of memory closer to the execution units, and lets the processor store frequently-used code and data in that local memory. The actual implementation of this idea is a bit more complicated, but it's still fairly easy to grasp.
Eliminating the Instruction Window
If you've read my series on the Pentium and the PowerPC line or my introduction to basic computer architecture fundamentals, then you're familiar with the concept of an instruction window. I don't want to recap that concept here, so check out this page if you're not familiar with it before moving on.
The diagram above shows the development of the microprocessor divided into three phases. The first phase is characterized by static execution, where instructions are issued to the execution units in the exact order in which they're fed into the processor. With dual-issue machines like the original Pentium, two instructions that meet certain criteria can execute in parallel, and it takes a minimal amount of logic to implement this very simple form of out-of-order execution.
In the second phase, computer designers included an instruction window, increased the number of execution units in the execution core, and increased the cache size. So more code and data would fit into the caching subsystem (either L1 or L1 + L2), and the code would flow into the instruction window where it would be spread out and rescheduled to execute in parallel on a large number of execution units.
The third phase is characterized by a massive increase in the sizes of the caches and the instruction window, with some modest increases in execution core width. In this third phase, memory is much farther away from the execution core, so more cache is needed to keep performance from suffering. Also, the execution core has been widened slightly and its units have been more deeply pipelined, with the result that there are more execution slots per cycle to fill.
This increased number of execution slots per cycle means that the processor has to find yet more instruction-level parallelism in the code stream, a necessity that gives rise to a massively-increased instruction window (i.e., rename registers, reorder buffer entries, and reservation stations). Now take a look at the diagram below. Notice how the all of that control logic that is associated with the instruction window makes up a huge proportion of the logic in the processor.
Such control logic took up a vanishingly small amount of space in the early static-issue RISC designs like the PPC 601. Of course, back when RISC was first introduced, "control logic" meant "decode logic," since there was no instruction window on those early designs. So RISC reduced the amount of control logic by simplifying the instruction decoding process; this left more room for execution hardware and storage logic in the form of on-die L1 cache.
The end result is that there is this massive amount of control logic that now sits between the processor's cache and its execution core, just as therei s a massive amount of latency that sits between the cache and main memory. This control logic eats up a lot of die space and adds pipeline latency, in return for extracting extra parallelism from the code stream.
Now let's switch gears a moment and look at the issues I raised in my recent Moore's Spring post. The diagram below represents fundamentally the same phenomenon as the diagram in that post, but from a perspective that should look familiar to you.
The evolution charted above shows how memory moves further and further away from the execution hardware, while the amount of execution hardware increases (in the form of added processors). What I've tried to illustrate with this diagram and the preceding ones is that there is a homology between the growth of on-die control logic that intervenes between the cache and the execution core and the growth of memory latency. The result is that a trend at the system level is somewhat replicated at the level of the microprocessor. Now let's take a look at a single Cell SPE.
As you can see, IBM has eliminated the instruction window and its attendant control logic, in favor of adding more storage space and more execution hardware. A Cell SPE doesn't do register renaming or instruction reording, so it needs neither a rename register file or a reorder buffer. The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.
The main differences between an individual SPE and an early RISC machine are twfold. First, and most obvious, is the fact that the Cell SPE is geared for single-precision SIMD computation. Most of its arithmetic instructions operate on 128-bit vectors of four 32-bit elements. So the execution core is packed with vector ALUs, instead of the traditional fixed-point ALUs. The second difference, and this is perhaps the most important, is that the L1 cache has been replaced by 256K of locally addressable memory. The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.
This RAM functions in the role of the L1 cache, but the fact that it is under the explicit control of the programmer means that it can be simpler than an L1 cache. The burden of managing the cache has been moved into software, with the result that the cache design has been greatly simplified. There is no tag RAM to search on each access, no prefetch, and none of the other overhead that accompanies a normal L1 cache. The SPEs also move the burden of branch prediction and code scheduling into software, much like a VLIW design.
The SPE's very simple front end can take in two instructions at a time, check to see if they can operate in parallel, and then issue them either in parallel or in program order. These two instructions then travel down one of two pipes, "even" or "odd," to be executed. After execution, they're put back in sequence (if necessary) by the very simple commit unit and their results are written back to local memory. The individual SPUs can throw a lot overboard, because they rely on a regular, general-purpose POWERPC processor core to do all the normal kinds of computation that it takes to run regular code. The Cell system features eight of these SPUs all hanging off a central bus, with one 64-bit POWERPC core handling all of the regular computational chores. Thus all of the Cell 's "smarts" can reside either on the PPC core, while the SPUs just do the work that's assigned to them.
To sum up, IBM has sort of reapplied the RISC approach of throwing control logic overboard in exchange for a wider execution core and a larger storage area that's situated closer to the execution core. The difference is that instead of the compiler taking up the slack (as in RISC), a combination of the compiler, the programmer, some very smart scheduling software, and a general-purpose CPU doing the kind of scheduling and resource allocation work that the control logic used to do.
The technical dirt
Now that the big picture is out of the way, here's the raw technical info for those who care. (Note that I'm following the order of the abstract from the program, which will hopefully become accessible on the web sometime soon.) The 256K LS on the SPUs is just a very simple, flat address space with no multiuser support built in. So there's no way to segregate out pages for use by users with different levels of access. This helps simplify the LS design by keeping complexity to a minimum. The LS is accessed in 16-byte or 128-byte lines, and instructions are fetched from it in 32, 4-byte groups.
The various clients for the LS use a cycle by cycle arbitration scheme, where the DMA takes first priority, loads and stores take second priority, and instruction fetch is third. The instruction format is a 32-bit fixed-length format, with up to three sources and one target. Here's a sample opcode for a floating-point multiply-add
OP | RT | RB | RA | RC
Once the instructions are in the SPE, the SPE's control unit can issue up to two instructions per cycle, in-order. The SPE has a 128-entry register file (128-bytes per entry) that stores both floating-point and integer vectors. As stated above, there are no rename registers. All loop unrolling is done by the programmer/compiler using this very large register file.
Note also that the register file has six read ports and two write ports. The SPEs can do forwarding and bypass the register file when necessary. The SPE has a DMA engine that handles moving data between main memory and the register file. This engine is under the control of the programmer as mentioned above. Each SPE is made of 21 million transistors: 14 million SRAM and 7 million logic. Finally, the instruction set for the SPEs is not VMX compatible or derivative, because its execution hardware doesn't support the range of instructions and instruction types that VMX/Altivec does.
Conclusion
There's a whole lot more to say about Cell, but that will have to wait until later. Tomorrow, after the next CELL session, I'll cover more of the Cell's basic architecture, including the mysterious 64-bit POWERPC core that forms the "brains" of this design.
http://arstechnica.com/articles/paedia/cpu/cell-1.ars
Introducing the Cell Part I: the SIMD processing units
By Jon "Hannibal" Stokes
Introduction
The Cell processor consists of a general-purpose POWERPC processor core connected to eight special-purpose DSP cores. These DSP cores, which IBM calls "synergistic processing elements" (SPE), but I'm going to call "SIMD processing elements" (SPE) because "synergy" is a dumb word, are really the heart of the entire Cell concept. IBM introduced the basic architecture of the SPE today, and they're going to introduce the overall architecture of the complete Cell system in a session tomorrow morning.
In this brief overview, I'm first going to talk in some general terms about the Cell approach what it is, what it's like, what's behind it, etc. before doing an information dump at the end of the article for more technical readers to chew on and debate. Once the conference is over and I get back to Chicago and get settled in, I'll do some more comprehensive coverage of the Cell.
Back to the future, or, what do IBM and Transmeta have in common?
It seems like aeons ago that I first covered Transmeta's unvieling of their VLIW Crusoe processor. The idea that David Ditzel and the other Transmeta cofounders had was to try and re-do the "RISC revolution" by simplifying processor microarchitecture and moving complexity into software. Ditzel thought that out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream had increased processors' microarchitectural complexity to the point where way too much die real-estate was being spent on control functions and too little was being spent on actual execution hardware. Transmeta wanted to move register renaming, instruction reordering and the like into software, thereby simplifying the hardware and making it run faster.
I have no doubt that Ditzel and Co. intended to produce a high-performance processor based on these principles. However, moving core processor functionality into software meant moving it into main memory, and this move put Transmeta's designs on the wrong side of the ever-widening latency gap between the execution units and RAM. TM was notoriously unable to deliver on the intitial performance expectations, but a look at IBM's CELL design shows that Ditzel had the right idea, even if TM's execution was off.
IBM's Cell embodies many of the "RISC redivivus" principles outlined above, but it comes at these concepts from a completely different angle. Like TM, IBM started out with the intention of increasing microprocessor performance, but unlike TM, simplifying processor control logic wasn't the magic ingredient that would make this happen. Instead, IBM attacked from the very outset the problem that TM ran headlong into: the memory latency gap. IBM's solution to the memory latency problem is at once both simple and complex. In its most basic form IBM's Cell does what computer architects have been doing since the first cache was invented Cell moves a small bit of memory closer to the execution units, and lets the processor store frequently-used code and data in that local memory. The actual implementation of this idea is a bit more complicated, but it's still fairly easy to grasp.
Eliminating the Instruction Window
If you've read my series on the Pentium and the PowerPC line or my introduction to basic computer architecture fundamentals, then you're familiar with the concept of an instruction window. I don't want to recap that concept here, so check out this page if you're not familiar with it before moving on.
The diagram above shows the development of the microprocessor divided into three phases. The first phase is characterized by static execution, where instructions are issued to the execution units in the exact order in which they're fed into the processor. With dual-issue machines like the original Pentium, two instructions that meet certain criteria can execute in parallel, and it takes a minimal amount of logic to implement this very simple form of out-of-order execution.
In the second phase, computer designers included an instruction window, increased the number of execution units in the execution core, and increased the cache size. So more code and data would fit into the caching subsystem (either L1 or L1 + L2), and the code would flow into the instruction window where it would be spread out and rescheduled to execute in parallel on a large number of execution units.
The third phase is characterized by a massive increase in the sizes of the caches and the instruction window, with some modest increases in execution core width. In this third phase, memory is much farther away from the execution core, so more cache is needed to keep performance from suffering. Also, the execution core has been widened slightly and its units have been more deeply pipelined, with the result that there are more execution slots per cycle to fill.
This increased number of execution slots per cycle means that the processor has to find yet more instruction-level parallelism in the code stream, a necessity that gives rise to a massively-increased instruction window (i.e., rename registers, reorder buffer entries, and reservation stations). Now take a look at the diagram below. Notice how the all of that control logic that is associated with the instruction window makes up a huge proportion of the logic in the processor.
Such control logic took up a vanishingly small amount of space in the early static-issue RISC designs like the PPC 601. Of course, back when RISC was first introduced, "control logic" meant "decode logic," since there was no instruction window on those early designs. So RISC reduced the amount of control logic by simplifying the instruction decoding process; this left more room for execution hardware and storage logic in the form of on-die L1 cache.
The end result is that there is this massive amount of control logic that now sits between the processor's cache and its execution core, just as therei s a massive amount of latency that sits between the cache and main memory. This control logic eats up a lot of die space and adds pipeline latency, in return for extracting extra parallelism from the code stream.
Now let's switch gears a moment and look at the issues I raised in my recent Moore's Spring post. The diagram below represents fundamentally the same phenomenon as the diagram in that post, but from a perspective that should look familiar to you.
The evolution charted above shows how memory moves further and further away from the execution hardware, while the amount of execution hardware increases (in the form of added processors). What I've tried to illustrate with this diagram and the preceding ones is that there is a homology between the growth of on-die control logic that intervenes between the cache and the execution core and the growth of memory latency. The result is that a trend at the system level is somewhat replicated at the level of the microprocessor. Now let's take a look at a single Cell SPE.
As you can see, IBM has eliminated the instruction window and its attendant control logic, in favor of adding more storage space and more execution hardware. A Cell SPE doesn't do register renaming or instruction reording, so it needs neither a rename register file or a reorder buffer. The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.
The main differences between an individual SPE and an early RISC machine are twfold. First, and most obvious, is the fact that the Cell SPE is geared for single-precision SIMD computation. Most of its arithmetic instructions operate on 128-bit vectors of four 32-bit elements. So the execution core is packed with vector ALUs, instead of the traditional fixed-point ALUs. The second difference, and this is perhaps the most important, is that the L1 cache has been replaced by 256K of locally addressable memory. The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage. The end result is that each SPE is like a very small vector computer, with its own "CPU" and RAM.
This RAM functions in the role of the L1 cache, but the fact that it is under the explicit control of the programmer means that it can be simpler than an L1 cache. The burden of managing the cache has been moved into software, with the result that the cache design has been greatly simplified. There is no tag RAM to search on each access, no prefetch, and none of the other overhead that accompanies a normal L1 cache. The SPEs also move the burden of branch prediction and code scheduling into software, much like a VLIW design.
The SPE's very simple front end can take in two instructions at a time, check to see if they can operate in parallel, and then issue them either in parallel or in program order. These two instructions then travel down one of two pipes, "even" or "odd," to be executed. After execution, they're put back in sequence (if necessary) by the very simple commit unit and their results are written back to local memory. The individual SPUs can throw a lot overboard, because they rely on a regular, general-purpose POWERPC processor core to do all the normal kinds of computation that it takes to run regular code. The Cell system features eight of these SPUs all hanging off a central bus, with one 64-bit POWERPC core handling all of the regular computational chores. Thus all of the Cell 's "smarts" can reside either on the PPC core, while the SPUs just do the work that's assigned to them.
To sum up, IBM has sort of reapplied the RISC approach of throwing control logic overboard in exchange for a wider execution core and a larger storage area that's situated closer to the execution core. The difference is that instead of the compiler taking up the slack (as in RISC), a combination of the compiler, the programmer, some very smart scheduling software, and a general-purpose CPU doing the kind of scheduling and resource allocation work that the control logic used to do.
The technical dirt
Now that the big picture is out of the way, here's the raw technical info for those who care. (Note that I'm following the order of the abstract from the program, which will hopefully become accessible on the web sometime soon.) The 256K LS on the SPUs is just a very simple, flat address space with no multiuser support built in. So there's no way to segregate out pages for use by users with different levels of access. This helps simplify the LS design by keeping complexity to a minimum. The LS is accessed in 16-byte or 128-byte lines, and instructions are fetched from it in 32, 4-byte groups.
The various clients for the LS use a cycle by cycle arbitration scheme, where the DMA takes first priority, loads and stores take second priority, and instruction fetch is third. The instruction format is a 32-bit fixed-length format, with up to three sources and one target. Here's a sample opcode for a floating-point multiply-add
OP | RT | RB | RA | RC
Once the instructions are in the SPE, the SPE's control unit can issue up to two instructions per cycle, in-order. The SPE has a 128-entry register file (128-bytes per entry) that stores both floating-point and integer vectors. As stated above, there are no rename registers. All loop unrolling is done by the programmer/compiler using this very large register file.
Note also that the register file has six read ports and two write ports. The SPEs can do forwarding and bypass the register file when necessary. The SPE has a DMA engine that handles moving data between main memory and the register file. This engine is under the control of the programmer as mentioned above. Each SPE is made of 21 million transistors: 14 million SRAM and 7 million logic. Finally, the instruction set for the SPEs is not VMX compatible or derivative, because its execution hardware doesn't support the range of instructions and instruction types that VMX/Altivec does.
Conclusion
There's a whole lot more to say about Cell, but that will have to wait until later. Tomorrow, after the next CELL session, I'll cover more of the Cell's basic architecture, including the mysterious 64-bit POWERPC core that forms the "brains" of this design.
HyperionX said:
Looks like Cell is dual-core plus extra (eDRAM?) in this shot. However, that's one focking big ass die, like 600m^2-700mm^2. This is ridiculously large and I'm guessing it's some sort of developement or testing chip on the wafer and the actual production chip is the separate one on top.
Aren't you the guy who thought there were only 16 possible outputs for the PSP analog nub?
Hmm... also I think they are making the compiler open source so that people can alter it to make it better. I am not sure if that is a good sign.
It sounds like they stripped alot of things out to make it fast but really dumped much of the complexity onto the OS/compiler people which will ultimately push it onto the console programmer.
mike12king
Banned
Hey guys, I just got a free Ipod! One of my freinds told me about this site, and I signed up for it, http://www.freeiPods.com/?r=14754629 and refered a few freinds and did one of their offers. Then about 3 weeks later (due to a backup at their storage facility), I recieved a FREE IPOD! Unbelievable! You guys got to try this.
- Mike
- Mike
Overall, I'm quite excited about Cell in how it relates to scientific computing, but it seems it will be a nightmare to write software for it due to the massive parallelism. As far as PS3 goes, how many GFLOPS it has won't matter either way, since we've been proven again and again that the average consumer doesn't give a shit about how impressive a game is technically. I do hope that the gap won't be as big as it was this gen, though.
Alright, so the biggest part of this unveiling goes as such
1. The chick's got a mustache, fucking gross.
2. PS3's gonna have some major G-FlopS. You know you like that
3. The chip is a shiny multicolored thingy.
4. Lastly, there's a gpu, intersecting with a cpu, creating a shift in the continuum proccessing several particular nuclehydroxytampon rectulytes in the, and this is what really has me splooging, vehectular vagina..
excuse me, that's storage logic. not vagina... I always get them confused.
1. The chick's got a mustache, fucking gross.
2. PS3's gonna have some major G-FlopS. You know you like that
3. The chip is a shiny multicolored thingy.
4. Lastly, there's a gpu, intersecting with a cpu, creating a shift in the continuum proccessing several particular nuclehydroxytampon rectulytes in the, and this is what really has me splooging, vehectular vagina..
excuse me, that's storage logic. not vagina... I always get them confused.