...teach students everything there is to know about the Amazon rain forest's endangered species...
I read this and thought "Man, I didn't know Amazon bought a rain forest! Good ol' Bezos."
Seriously though, if this is a grave enough concern that you need to ask current-directory, you should move to Seattle immediately. Or Vancouver. Or Portland.
We have mountains, and beaches (heh), and bike trails galore. No one fears the West Nile. We drive Subarus to take our dogs to the dog parks. When friends visit, we go see REI and picnic in the park at the southern end of Pike's market. We eschew the space needle.
There is more acreage of elaborate gardens tended by homeowners in 10 square blocks of Wallingford than most cities have in all their parks combined.
Remember that this speech was given to students graduating Stanford... not high school. Whether a degree is worthwhile, in the context of the audience, is moot.
The point of the speech is to encourage students to "ACCOMPLISH SOMETHING". Graduating isn't the top of the mountain, it's base camp. It's not an accomplishment unless they use it to propel themselves. blah blah blah. Potential is for losers.
You want to really stand out? Try not having a degree.
It's been really freaking hard finding a well-paying job in my field even with 3 years experience and a degree... I'd hate to think where I'd be if I'd followed my instincts and left school early. (during the boom)
While the hardware on consoles is locked, you see constantly improving technology on consoles as developers figure out how to use it to its fullest. This is especially true on the PS2, where the quality of technology has resembled the years-long learning curve.
The next-generation will be even more dramatic, both in the disappointing launch titles, and in the shocking improvement over the next 5 years.
PCs will always be anchored by widespread adoption of legacy systems, but this can be an advantage for them. The next-generation of console games will cost so much money to develop and cost so much to the consumer, that this opens up a big market in low-cost not-bleeding-edge PC gaming. That's the direction I see their future going.
After all, there are many more PCs than consoles in the world.
but are not so good at algorithmic or complex flow operations.... they are going to be at a strict disadvantage in data retrieval and pushing operations
Data retrieval? You have to remember that there's a 25.6 GByte/s bandwidth to main mem! And they each have 256k of single-cycle access memory (i.e. take your 32k L1 and shove it).
It's not like the SPEs are only capable of SIMD vector operations... they are real CPUs with the memory limitation and single-thread limitation. It's just that they do have SIMD capability, and they'll tend to excel most when there is a high computation/(data consumption + branching) ratio.
So what kind of servers are these? They even have a 76.8 GByte/sec bus between SPEs... sounds like they're really freaking high memory bandwidth servers!
Right it's not new. The big difference now is the memory bandwidth between where the geometry is generated and where it is transformed and lit.
On a PC, you have that puny little AGP 8x bus running at just 2 GB/s on a high-end system. Next-Gen consoles both have > 20 GB/s bandwidth to the video card. As an added bonus, there are additional processors that can be devoted to the geometry generation, but that hasn't really been the bottleneck in the past.
The golden rule of "Put it on video card once, don't read it back" no longer applies, so this is the first consequence. Other things that have suffered from this memory bottleneck, such as framebuffer computations will be next. After that, you'll see the GPGPU crowd release some monster computation demos... And the Real-Time Raytracing community as well.
None of these are new ideas, they're just useful ideas finally.
Sony loves linux. Why? Because Microsoft hates linux, and Sony loves to support anything that Microsoft hates.
Even before the XBox. When PS2 dev tools were released it was all Linux-based. If you wanted to develop for the PS2 on Windows, you had to either go with 3rd party tools or according to Sony "If you're a big dumb idiot, then you can use Cygwin. But you shouldn't." Then, just for kicks, they released PS2 Linux.
Unfortunately, Sony's linux dev tools weren't up to snuff, but I doubt they'll make the same mistake with the PS3. Remember that IBM has a hand in this now, and a vested interest in making this Cell fly with more than just game developers.
Cell is a good place for Linux. Don't get me wrong, they're definitely going to milk the Us vs Them theme against Microsoft for all the money it's worth.
Regarding the VMX and multicores: VMX-128 means that there's a ton of vector registers. It means the key will be to keeping memory pumping to registers always, and that working on 10 different datasets is possible (with 12 registers/dataset) and necessary (to interleave operations so that they fill each other's latencies).
The PS3 has more of these, but it has roughly the same memory bandwidth... so it should run faster for algorithms that have a high FLOP/memory consumption (such as cloth simulation), but run the same for low ratios (such as skinning). The key for PS3 programmers is to do a lot on the data they pump in and out. The key for XBox 2 programmers is to not abuse their caches, and end up stalling waiting for data.
As far as the memory is concerned: XDR is high bandwidth (25 GB/s) BUT it uses the same bus to fill SPEs as it uses to feed the video card. The GDDR3 is low bandwidth (relatively speaking), but it's off the SPE/PPE/Main Mem bus. So the GDDR3 can be pumping the video card with models and textures, and it won't effect the SPEs retrieving data from XDR at all.
As far as I can tell, the GDDR3 is kind of a hedge from Sony. 256MB XDR is the hardware limit for the Cell processor, but it might easily not be enough for the game. Also, the XDR is super high bandwidth, but filling 7 SPEs, the PPE and running the video card might over-tax it (this was what happened with the PS2).
So, if a game is bus-bound, it can generate display lists that get output to GDDR3, so that when a frame is rendered, none of that massive geometry transfer has to interrupt the SPE/XDR bus. OTOH, if a game is cpu-bound, there's bus left-over to do the geometry/texture transfer from XDR, that's an option also. If the PS2 is any indication... virtually no game will have the latter problem.
It means that game developers programming in assembly language will only have to learn one. Too bad there aren't many left who do. (A fact of life when the bottlenecks move to memory/art/game-logic).
It's not the assembly language of the processor that's the trick... it's the instruction set of the vector processor. So, you're right in one sense-- The PS2's VU and XBox's SSE are radically different, and the PSP's VFU is a bizarre creation unlike anything I've ever seen. Learning the intricacies of each is very involved and painstaking work.
So you might think that now they're all using VMX, it will be easier... except that they will each tack on their own extensions, and the devil is always in the details. It's much the same problem as Web browsers reading and rendering HTML.
I don't believe they could emulate the PS2. They might just throw the whole chip in, since they're so cheap to produce now, but I don't believe emulation would be possible.
As to 'Too bad there aren't many left who do'... Actually there are plenty left, they're just almost all PS2 programmers. I haven't seen PS3 specs, but I believe it will be very difficult for any developer to write for the PS3 if they didn't write for the PS2.
No way. XBox2 (and PS3) developers will have a guaranteed 20-25 GB/s memory bandwidth, while the highest end PCs today only get about 8 GB/s... and it's not getting better very quickly.
The poor 300 Mhz processor that shipped with PS2 isn't even the bottleneck for that platform. You think that suddenly the processing power of PCs are going to trump the next-gen multi-cores?
And the majority of those that deal with the renderer don't need the book...
There are 3 things that could make the things you could do with a GPU much, much cooler:
1) Spawning vertices from within in GPU program.
2) Vertices interacting with each other (cloth, eg)
3) Persisting the results of vertex ops without the horrible memory bottleneck.
Now, all of those you'll be able to do with the next-gen of consoles... not on the GPU, but with the multi-core processors.
I'm not saying that current GPU programming is as far as it goes or anything... But without those 3 things, improvements in GPU technology won't correspond to any improvement in games. Not even in how they look.
I am also baffled. But the SPE has a memory size of only 256kb and 25 GByte/s bandwidth to main memory, so it's not like a context switch is out of the question. Also I'm pretty sure that each SPE can run 2 threads SMP (or is that just the Power chip?)
It probably is a combination of the method you describe (where a SPE is dedicated to a thread) and traditional pre-emptive... And it probably boils down to the more processor-intensive threads get their own SPE, while a couple SPEs are dedicated to context-switching threads.
To me, that part is not as baffling as how programs are going to be written in the first place. A thread will have to communicate all the memory accesses it will need to make to prefetch all that data. On the PS2, we use environments like this, where that memory would be double- or triple-buffered so we can simultaneously stream, process, and write-back... but that's hand-written individually for the hardest-core processing pieces, where memory accesses are predictable and sequential. How to do this in a general way to make the process easier on application developers?
I'm not a huge Nintendo fan, and I'll even cut them a break. The fact is they're happy to leave Microsoft alone to get the marketing beat-down from Sony.
Remember last year when Nintendo released pre-E3 images of the DS as a white and purple toy? Then Sony put out the PSP shots and everyone looked at the two side-by-side. By the time E3 arrived, Nintendo had scrambled to get a shiny-silver and black version out... but people had already made their comparisons.
Now, Nintendo is in a good spot. They're the overlooked underdog, so they really get to choose their battles. Microsoft has already played their card-- Fall 2005. Sony is the champ with everything to lose, and now Nintendo can afford to bide their time as long as behind the scenes they're getting their 3rd party support in line.
Unfortunately, and in my opinion, this follow-the-leader approach has lead to stagnation in CPU development.
What's amazing is how many professional game developers aren't even aware of subjects covered in such books as the "Game Programming Gems" series. Many game developers are confronted with the exact same problems, in slightly varying forms, in virtually every game. At conferences like GDC and through books, many experts are trying to shout their solutions from the rooftops.... yet many don't bother to listen.
It's not 'follow-the-leader'. That's precisely why gameplay programmers are not standing on the shoulders of giants.
The HPC Challenge benchmark is especially interesting and I think sheds some light on the design goals IBM had in coming up with the Cell.
1) Solving linear equations. SIMD Matrix math, check.
2) DP Matrix-Matrix multiplies. IBM added DP support to their VMX set for Cell (though at 10% the execution rate), check.
3) Processor/Memory bandwidth. XDR interface at 25.6 GB/s, check.
4) Processor/Processor bandwidth. FlexIO interface at 76.8 GB/s, check.
5) "measures rate of integer random updates of memory", hmmmm... not sure.
6) Complex, DP FFT. Again, DP support at a price. check.
7) Communication latency & bandwidth. 100 GB/s total memory bandwidth, check (though this could be heavily influenced on how IBM handles its SPE threading interface)
Obviously, I'm not saying they used the HPC Challenge as a design document, but clearly Cell is meant as a supercomputer first and a PS3 second.
Mr Spector, over a decade ago, hired a team and moved them all down to Texas for a project that was cancelled within the first week. He was in a position where he could either take a stand and invest in the project personally, or he could just fire the whole team... so he fired the team.
Since then, he's seen the same machinery that put him in that position take over the entire industry and I think he still burns from his decision long ago. Now, he's decrying the industry and lamenting his own helplessness now that he feels he has some power. However, as the saying goes, 'talk is cheap'. When he says distribution, he's talking PC games which represent a tiny sliver of the industry... and console games have no alternative distribution, nor will they ever. That's the end of that.
Greg and Chris's talks were very interesting. Greg said, "they tell us things will get better because poly-counts will be through the roof" and Chris said "they tell us things will get better because we'll have 256 GFlops". The common thread here is not that no one cares about gameplay... it's that because of the expectations the industry is pushing the baseline to have enough art at high enough resolution being rendered on a fast enough engine is SO HIGH and costs SO MUCH MONEY, that there are no left-over resources for tuning gameplay. Thus, content-rich fun-poor.
EA is different in one basic way, I think. Other developers look at the schedule, then the deadline, then start cutting features one-by-one to make the two line up.
EA holds the same meeting, except they keep assigning more and more resources to the project until requirements and deadlines line up. (Please, spare me blahblah about the Mythical Man Month)
Word is, EA released NFSU2 three months early because of anticipated competition with GT4 (this was a long time ago). I sure didn't notice that it was a 'rushed' title... EA releases the game they planned to make in the first place, the whole thing.
Sure the latest Goldeneye got panned, but they've used slave-hours to produce far too many very good games to start saying they're doing it wrong. It's not just marketing, they really are good.
PS3 will have BluRay, so that will be many people's first BluRay player. Then, the masses will gently migrate as the question is no longer to buy the player but rather which format disc to purchase.
So, it'd probably be more accurate to say that Blu-Ray will kill off DVD Players, but not DVDs themselves.
Why does no one ever talk about Sony's VU assembly in their SIMD comparisons? The parent's linked article even cites the PS2 in its very first sentence, but then ignores it completely!
The VUs have the sweetest SIMD instruction set I've seen. 32 registers (like altivec), but you can do component swizzling within an instruction, it has MADD and also a sweet Accumulate register that can be re-written to on successive cycles (throughput is worse if you accumulate results in a normal vector register, like you have to on all other SIMDs). So you can do a 4x4 matrix/vector multiply in just 4 instructions!
The big problem was that you didn't get any of the nice instruction scheduling/re-ordering that you get on PPC or x86 platforms, so the onus was on the programmer to NOP through latency issues (huge pain!)... They finally came out with the VCL that would process chunks of VU assembly and reschedule everything at compile time.
The really sad thing is that Sony/IBM/Toshiba opted for AltiVec in the Cell. I guess it probably has better tools and IBM is highly leveraged into VMX, but VU was very, very clever considering that it pre-dates all these other SIMD instruction sets.
the fact that SSE optimised code usually runs slower on an Athlon than 'unoptimised' code has severely limited its applications.
What does this even mean? I've written a great deal of optimized SSE code, and I can promise you that it works just as well on AMD. In fact, if you look at Athlon's pipeline, it does some really amazing things rescheduling and executing operations out-of-order. Fiddling around with ordering individual instructions is basically pointless because the scheduler has gotten so good at doing it on-the-fly.
Can you cite a specific example, because I've never run into this.
And 50 years ago, when folks fought against something they hated it was Hollywood Jew Communists. Oh, and it was 50 years ago that Rosa Parks finally decided not to give up her seat.
Don't lie to yourself about what America Was.
(And the rest of the world had your own shit too, so spare me the insensitive clod jokes.)
Not trolling (not my intent at least), but the 'majority of games that define the "gaming world"' don't run on PC Windows either... They run on GC, PS2, X-Box, DC, PSP, GBA.
Go get one and enjoy the world of games, online and offline, that exist. Appreciate linux for whatever reason you decided to install it, but bickering about Respect Aw Communitay is not worth the effort when you can get a console for half the price of a year-old video card!
It's hard enough for publishers to make money off PC games already without having to worry about linux. And if it makes you feel better, I'm positive that Linux games will flourish when the Cell gets a foothold.
But there are some tasks that can be done by both CPU and GPU but are generally assigned to the GPU. For instance, you can generate a stencil shadow volume in a vertex shader... it's just very wasteful of the GPU. You can also animate characters on the GPU, but they have to be retransformed to do multi-pass effects. So if the game is GPU-bound, a good idea is moving these tasks to the CPU.
Honestly, working on a dual-core CPU, you could create 2 threads-- 1 that just does character animation and silhouette/shadow volume generation, and another that does physics/AI. And you'd have very well balanced processor usage and better GPU efficiency (depending on the game of course).
Slashdot Mirror
Size of the entire internet man,
Usually kind to smaller man,
Google Man.
Yahoo Man, Yahoo Man,
Hit on the head with a frying pan,
lives his life in a garbage can.
Yahoo man.
Google Man and Yahoo Man,
Meet on the street in internet land,
They have a fight,
Google wins.
Google Man.
I read this and thought "Man, I didn't know Amazon bought a rain forest! Good ol' Bezos."
Seriously though, if this is a grave enough concern that you need to ask current-directory, you should move to Seattle immediately. Or Vancouver. Or Portland.
We have mountains, and beaches (heh), and bike trails galore. No one fears the West Nile. We drive Subarus to take our dogs to the dog parks. When friends visit, we go see REI and picnic in the park at the southern end of Pike's market. We eschew the space needle.
There is more acreage of elaborate gardens tended by homeowners in 10 square blocks of Wallingford than most cities have in all their parks combined.
Anyway, good luck. I have a steak to grill.
The point of the speech is to encourage students to "ACCOMPLISH SOMETHING". Graduating isn't the top of the mountain, it's base camp. It's not an accomplishment unless they use it to propel themselves. blah blah blah. Potential is for losers.
It's been really freaking hard finding a well-paying job in my field even with 3 years experience and a degree... I'd hate to think where I'd be if I'd followed my instincts and left school early. (during the boom)
The next-generation will be even more dramatic, both in the disappointing launch titles, and in the shocking improvement over the next 5 years.
PCs will always be anchored by widespread adoption of legacy systems, but this can be an advantage for them. The next-generation of console games will cost so much money to develop and cost so much to the consumer, that this opens up a big market in low-cost not-bleeding-edge PC gaming. That's the direction I see their future going.
After all, there are many more PCs than consoles in the world.
Data retrieval? You have to remember that there's a 25.6 GByte/s bandwidth to main mem! And they each have 256k of single-cycle access memory (i.e. take your 32k L1 and shove it).
It's not like the SPEs are only capable of SIMD vector operations... they are real CPUs with the memory limitation and single-thread limitation. It's just that they do have SIMD capability, and they'll tend to excel most when there is a high computation/(data consumption + branching) ratio.
So what kind of servers are these? They even have a 76.8 GByte/sec bus between SPEs... sounds like they're really freaking high memory bandwidth servers!
On a PC, you have that puny little AGP 8x bus running at just 2 GB/s on a high-end system. Next-Gen consoles both have > 20 GB/s bandwidth to the video card. As an added bonus, there are additional processors that can be devoted to the geometry generation, but that hasn't really been the bottleneck in the past.
The golden rule of "Put it on video card once, don't read it back" no longer applies, so this is the first consequence. Other things that have suffered from this memory bottleneck, such as framebuffer computations will be next. After that, you'll see the GPGPU crowd release some monster computation demos... And the Real-Time Raytracing community as well.
None of these are new ideas, they're just useful ideas finally.
Sony loves linux. Why? Because Microsoft hates linux, and Sony loves to support anything that Microsoft hates.
Even before the XBox. When PS2 dev tools were released it was all Linux-based. If you wanted to develop for the PS2 on Windows, you had to either go with 3rd party tools or according to Sony "If you're a big dumb idiot, then you can use Cygwin. But you shouldn't." Then, just for kicks, they released PS2 Linux.
Unfortunately, Sony's linux dev tools weren't up to snuff, but I doubt they'll make the same mistake with the PS3. Remember that IBM has a hand in this now, and a vested interest in making this Cell fly with more than just game developers.
Cell is a good place for Linux. Don't get me wrong, they're definitely going to milk the Us vs Them theme against Microsoft for all the money it's worth.
That's just business.
The PS3 has more of these, but it has roughly the same memory bandwidth... so it should run faster for algorithms that have a high FLOP/memory consumption (such as cloth simulation), but run the same for low ratios (such as skinning). The key for PS3 programmers is to do a lot on the data they pump in and out. The key for XBox 2 programmers is to not abuse their caches, and end up stalling waiting for data.
As far as the memory is concerned: XDR is high bandwidth (25 GB/s) BUT it uses the same bus to fill SPEs as it uses to feed the video card. The GDDR3 is low bandwidth (relatively speaking), but it's off the SPE/PPE/Main Mem bus. So the GDDR3 can be pumping the video card with models and textures, and it won't effect the SPEs retrieving data from XDR at all.
As far as I can tell, the GDDR3 is kind of a hedge from Sony. 256MB XDR is the hardware limit for the Cell processor, but it might easily not be enough for the game. Also, the XDR is super high bandwidth, but filling 7 SPEs, the PPE and running the video card might over-tax it (this was what happened with the PS2).
So, if a game is bus-bound, it can generate display lists that get output to GDDR3, so that when a frame is rendered, none of that massive geometry transfer has to interrupt the SPE/XDR bus. OTOH, if a game is cpu-bound, there's bus left-over to do the geometry/texture transfer from XDR, that's an option also. If the PS2 is any indication... virtually no game will have the latter problem.
It's not the assembly language of the processor that's the trick... it's the instruction set of the vector processor. So, you're right in one sense-- The PS2's VU and XBox's SSE are radically different, and the PSP's VFU is a bizarre creation unlike anything I've ever seen. Learning the intricacies of each is very involved and painstaking work.
So you might think that now they're all using VMX, it will be easier... except that they will each tack on their own extensions, and the devil is always in the details. It's much the same problem as Web browsers reading and rendering HTML.
I don't believe they could emulate the PS2. They might just throw the whole chip in, since they're so cheap to produce now, but I don't believe emulation would be possible. As to 'Too bad there aren't many left who do'... Actually there are plenty left, they're just almost all PS2 programmers. I haven't seen PS3 specs, but I believe it will be very difficult for any developer to write for the PS3 if they didn't write for the PS2.
The poor 300 Mhz processor that shipped with PS2 isn't even the bottleneck for that platform. You think that suddenly the processing power of PCs are going to trump the next-gen multi-cores?
It's the memory-bandwidth baby.
There are 3 things that could make the things you could do with a GPU much, much cooler:
1) Spawning vertices from within in GPU program.
2) Vertices interacting with each other (cloth, eg)
3) Persisting the results of vertex ops without the horrible memory bottleneck.
Now, all of those you'll be able to do with the next-gen of consoles... not on the GPU, but with the multi-core processors.
I'm not saying that current GPU programming is as far as it goes or anything... But without those 3 things, improvements in GPU technology won't correspond to any improvement in games. Not even in how they look.
It probably is a combination of the method you describe (where a SPE is dedicated to a thread) and traditional pre-emptive... And it probably boils down to the more processor-intensive threads get their own SPE, while a couple SPEs are dedicated to context-switching threads.
To me, that part is not as baffling as how programs are going to be written in the first place. A thread will have to communicate all the memory accesses it will need to make to prefetch all that data. On the PS2, we use environments like this, where that memory would be double- or triple-buffered so we can simultaneously stream, process, and write-back... but that's hand-written individually for the hardest-core processing pieces, where memory accesses are predictable and sequential. How to do this in a general way to make the process easier on application developers?
That's never really been a concern for Sony...
Remember last year when Nintendo released pre-E3 images of the DS as a white and purple toy? Then Sony put out the PSP shots and everyone looked at the two side-by-side. By the time E3 arrived, Nintendo had scrambled to get a shiny-silver and black version out... but people had already made their comparisons.
Now, Nintendo is in a good spot. They're the overlooked underdog, so they really get to choose their battles. Microsoft has already played their card-- Fall 2005. Sony is the champ with everything to lose, and now Nintendo can afford to bide their time as long as behind the scenes they're getting their 3rd party support in line.
What's amazing is how many professional game developers aren't even aware of subjects covered in such books as the "Game Programming Gems" series. Many game developers are confronted with the exact same problems, in slightly varying forms, in virtually every game. At conferences like GDC and through books, many experts are trying to shout their solutions from the rooftops.... yet many don't bother to listen.
It's not 'follow-the-leader'. That's precisely why gameplay programmers are not standing on the shoulders of giants.
With references like 'open sores software
Oh man, first they ignore us.
Now they're mocking and attacking in the same article... what's next?
1) Solving linear equations. SIMD Matrix math, check.
2) DP Matrix-Matrix multiplies. IBM added DP support to their VMX set for Cell (though at 10% the execution rate), check.
3) Processor/Memory bandwidth. XDR interface at 25.6 GB/s, check.
4) Processor/Processor bandwidth. FlexIO interface at 76.8 GB/s, check.
5) "measures rate of integer random updates of memory", hmmmm... not sure.
6) Complex, DP FFT. Again, DP support at a price. check.
7) Communication latency & bandwidth. 100 GB/s total memory bandwidth, check (though this could be heavily influenced on how IBM handles its SPE threading interface)
Obviously, I'm not saying they used the HPC Challenge as a design document, but clearly Cell is meant as a supercomputer first and a PS3 second.
Mr Spector, over a decade ago, hired a team and moved them all down to Texas for a project that was cancelled within the first week. He was in a position where he could either take a stand and invest in the project personally, or he could just fire the whole team... so he fired the team.
Since then, he's seen the same machinery that put him in that position take over the entire industry and I think he still burns from his decision long ago. Now, he's decrying the industry and lamenting his own helplessness now that he feels he has some power. However, as the saying goes, 'talk is cheap'. When he says distribution, he's talking PC games which represent a tiny sliver of the industry... and console games have no alternative distribution, nor will they ever. That's the end of that.
Greg and Chris's talks were very interesting. Greg said, "they tell us things will get better because poly-counts will be through the roof" and Chris said "they tell us things will get better because we'll have 256 GFlops". The common thread here is not that no one cares about gameplay... it's that because of the expectations the industry is pushing the baseline to have enough art at high enough resolution being rendered on a fast enough engine is SO HIGH and costs SO MUCH MONEY, that there are no left-over resources for tuning gameplay. Thus, content-rich fun-poor.
EA holds the same meeting, except they keep assigning more and more resources to the project until requirements and deadlines line up. (Please, spare me blahblah about the Mythical Man Month)
Word is, EA released NFSU2 three months early because of anticipated competition with GT4 (this was a long time ago). I sure didn't notice that it was a 'rushed' title... EA releases the game they planned to make in the first place, the whole thing.
Sure the latest Goldeneye got panned, but they've used slave-hours to produce far too many very good games to start saying they're doing it wrong. It's not just marketing, they really are good.
So, it'd probably be more accurate to say that Blu-Ray will kill off DVD Players, but not DVDs themselves.
The VUs have the sweetest SIMD instruction set I've seen. 32 registers (like altivec), but you can do component swizzling within an instruction, it has MADD and also a sweet Accumulate register that can be re-written to on successive cycles (throughput is worse if you accumulate results in a normal vector register, like you have to on all other SIMDs). So you can do a 4x4 matrix/vector multiply in just 4 instructions!
The big problem was that you didn't get any of the nice instruction scheduling/re-ordering that you get on PPC or x86 platforms, so the onus was on the programmer to NOP through latency issues (huge pain!)... They finally came out with the VCL that would process chunks of VU assembly and reschedule everything at compile time.
The really sad thing is that Sony/IBM/Toshiba opted for AltiVec in the Cell. I guess it probably has better tools and IBM is highly leveraged into VMX, but VU was very, very clever considering that it pre-dates all these other SIMD instruction sets.
What does this even mean? I've written a great deal of optimized SSE code, and I can promise you that it works just as well on AMD. In fact, if you look at Athlon's pipeline, it does some really amazing things rescheduling and executing operations out-of-order. Fiddling around with ordering individual instructions is basically pointless because the scheduler has gotten so good at doing it on-the-fly.
Can you cite a specific example, because I've never run into this.
Don't lie to yourself about what America Was.
(And the rest of the world had your own shit too, so spare me the insensitive clod jokes.)
Go get one and enjoy the world of games, online and offline, that exist. Appreciate linux for whatever reason you decided to install it, but bickering about Respect Aw Communitay is not worth the effort when you can get a console for half the price of a year-old video card!
It's hard enough for publishers to make money off PC games already without having to worry about linux.
And if it makes you feel better, I'm positive that Linux games will flourish when the Cell gets a foothold.
Honestly, working on a dual-core CPU, you could create 2 threads-- 1 that just does character animation and silhouette/shadow volume generation, and another that does physics/AI. And you'd have very well balanced processor usage and better GPU efficiency (depending on the game of course).