Funny, I can do the same thing on an iPod, by just reducing or increasing the bitrate of the songs I store on there. Exactly the same principle. Tape is just lossy magnetic samples of an analog waveform after all - faster speed is simply more samples/sec.
Read this post (also here). I quote: "Apple will no longer be selling maintenance for Shake and no further software updates are planned".
Apple will not be making the base product more stable, they're dropping it completely, in favour of some future product (apparently due around 2008). While the price drop will doubtless expand the market into the low end in the short term, the high-end users started their move away from Shake the moment Apple bought it (at least, those that wanted to keep running Linux and not Mac OS). Perhaps I didn't stress enough how important support is to high-end customers. Now the end of the road is clear, nobody is going to want to invest significantly in the Shake platform - including major plugin vendors.
I don't doubt Shake's technology will live on, but whatever Apple is working on will be a new product, and will not be released for Linux. Since something like 90% of Shake licences were Linux (which isn't even getting the price drop), most users will not see this as a good thing.
I'm all for lowering barriers to entry, and decent software at cheap prices is a great thing for the masses (many of whom learn on pirate copies anyway). But I doubt this move will be welcomed by the major studios.
It costs a lot of programmer time to develop decent software, especially complex apps like this. And the smaller your target market, the higher the cost per copy, simple as that. Basic economies of scale.
Now add to that the cost of in-depth technical support for each of your customers - not just installation problems or bug fixes, but answering usage questions, suggested techniques, basic training, occasional specialised plugin development, timely response to feature requests, rapid response to critical bugs, and the assurance that if the studio (who has committed their workflow to your product) ever has a show-stopping issue, you'll do whatever it takes to help them through it. THAT's what the high prices are for, and in my experience, most professional studios are more than happy to pay it.
Thus, we see Apple dropping all of that, as $500/copy simply can't cover the cost of supporting a complex and mission-critical app like that. The biggest studios may find it necessary to drop $50K on the source code to be able to fix bugs themselves, but not many would be willing to continue full development (not their business), and will doubtless be looking at phasing out Shake in favour of more actively-developed alternatives (most have been doing this for some time).
GP was referring to 2nd gen games, not another model of the hardware. As for your other comments:
A) The base model is for low-budget buyers who just want to play the new games. If they wanted all the add-ons, they wouldn't buy the base model, would they?
B) I assume you're claiming the developers won't take advantage of the HDD. They already are, plus many others use it for pre-caching etc if it's there. There are a lot more HDD-equipped 360s out there than base models, so developers have little to lose in supporting it.
C) The HD-DVD won't be used for games, MS have confirmed that. Movies are the point. Yes, it will bring the cost up to PS3-levels, but only if you want to pay for that feature. Unlike the PS3, the extra cost is optional.
HDR textures can take up something around 4x the space
Only when uncompressed, and even then they need take no more than 2x. There are numerous fast and efficent representation method for stored HDR images that take up little more than non-HDR. This is something I have a lot of experience in. Oh, and less texture compression usually means slower loading, as there is more data to fetch from disc. Better to encode it tighter, get it off the disc quicker, then decompress it in the background with a spare CPU core.
And 640k is enough for anyone, right?
A common misconception. A better quote from our mate Bill: "Understand that this is the last physical format there will ever be. Everything's going to be streamed directly or on a hard disk."
Developers may or may not be happy with DVD9, but even if MS changes their minds, few developers would ever consider releasing a 360 game on HD-DVD. Especially if the HD-DVD add-on penetration rate is only 10% as you suggest.
All of which involve compromise of one form or another
Everything's a compromise. Sony's is to charge more.
CD - developed primarily by Philips, as I recall. Firewire - Apple. Sony developed DVCAM, less sure about MiniDV, though they certainly pushed it in the early days. You're right, Sony has had its many successes too, but although it's way too early to say for Blu-Ray, UMD's recent and public failure didn't exactly endear Sony movie formats to the studios.
You may have forgotten what 360's were going for on ebay.
Sure, but how many people actually bought them at those prices? 500? There will always be people prepared to pay whatever it takes, and Sony will have its fair share. Selling a million probably won't be hard, as you say. Selling ten million at $500 will be a lot harder, I predict.
As for myself, I was indeed considering a PS3. There's a couple of games that drew my eye, but mostly it was the prospect of a cheap Linux HTPC with Blu-Ray, HDMI etc. That idea kinda fell through when it turned out not to be cheap after all. Maybe in a few years when it's under $300, but who knows what else will be available then.
As other people have pointed out, unlike all other console add-ons, this one doesn't require support from game developers to be useful. It's much more comparable to buying a 1/3-price standalone player, except that its market is limited to Xbox 360 owners. And, unlike Sony, MS don't care if they sell to a mere 10%, they don't have a vested interest in pushing the format on us no matter what.
As for the "fifteen discs of content", come on, you can do better than that:-) Right now it's an infinite multiple of available Blu-Ray and PS3 media put together. Let's ask that question again in November, when it's more meaningful.
Cool, that's one at least. Good news for the Samsung HL-S5687W owner(s) out there. I assume it's out of pre-order by now.
The TV Authority page actually seems to contradict the Samsung specs page (it says "two smart component video (Y/Pb/Pr) inputs that accept 480p/720p/1 080i signals."), but I think we can accept Samsung's word here.
Now all we need is some real evidence that the PS3's component output can also do 1080p, on the low-end model.
It's for playing movies, nothing else. It will be bought only by people who want to play HD movies (because it's cheaper than a standalone player), and being an optional add-on, it has the not-inconsiderable advantage of saving money for everyone else.
It's quite possible to transmit a 1080p signal over component. The spec allows for it - take a look sometime.
However, finding a consumer display device that will accept a 1080p component signal is another matter entirely. I'm not aware of any (and no, the Westinghouse LVM-42W2 won't do it).
The PS2 has already seen a number of two-disc games
Early PS2s could only read 4.7GB from a DVD. Are there any dual-layer gamediscs for the PS2? Are there any two-disc games for the Xbox? Besides, there are many more possibilities today for keeping content size down than there used to be, especially if the game design is at stake.
But what if [Sony] are right? That's a possibility that people seem to not understand
Betmax. Minidisc. UMD. Memory Stick. The fact that it's Sony makes it less of a possibility that Blu-Ray will succeed than it otherwise would be.
Blu-Ray being included in a console that will sell in the millions and tens of millions
You may not have noticed, but Blu-Ray being included in the PS3 is the single biggest factor working against it selling in the tens of millions. Gamers are being turned off by the price of a component they don't particularly care about. HD movie freaks have the option of a same-priced player, today, that will undoubtedly get cheaper faster than the PS3. Sony have successfully reduced their market to die-hard fanbois and compulsive early-adopters. The rest of us will wait a year or or two for things to settle down, by which time player prices will be low enough that the "bonus" Blu-Ray player will hardly be a factor.
People like to think that Microsoft will not deliver games on HD-DVD, because it would anger current owners.
Microsoft have repeatedly confirmed that they will not ship games on HD-DVD.
No-one wants multi-disc games, publishers as well as gamers, but they simply won't be necessary, even on DVD, for the vast majority of games.
What takes up the most space on a disc? Not gameplay code, or even textures. It's cut-scene video - and there's many ways of reducing that. Faster, multicore CPUs can use better compression algorithms (lower bitrates or resolutions are also possible, in a pinch). Game-rendered cutscenes take a fraction the space, are already popular, and getting more practical all the time. Even HD textures aren't a big deal - they can be compressed on disc with better algorithms too, and similarly, procedural (or procedurally-modified) textures are fast, popular and ever more practical with today's GPUs.
In the PS2's day, MPEG2 cutscenes were all the rage (and early PS2s couldn't even read dual-layer discs), but we've moved beyond that now. When faced with long cutscenes, a PS3 developer may have the space to be lazy, but a 360 developer has the devkit tools to be efficient.
Memory latency is typically far lower for sequential accesses, and that is what its rated bandwidth is dependant on, not random accesses (which are obviously slower). Given ideal conditions (helped by prefetch buffers), an OoO CPU can queue up contiguous requests direct from memory at a rate not that far off the memory's rated bandwidth. Don't forget, a CPU can process numerous instructions in one memory bus cycle, and (code permitting) can certainly queue up more requests before the queue empties. So long as the queue does not empty, the memory does not need to miss a beat. Lots of apps do this, including memory benchmarks and the image processing app I develop. AGP memory is no exception, unless the graphics card is contending for access.
An in-order CPU can still get very good results in most cases by doing sequential accesses (it would likely still have prefetch buffers), and doubtless this is how the PS3 is able to quote its 25GB/s to system RAM. It can probably achieve most of that, with careful coding. Cell access to RSX memory is a completely different matter; clearly requests follow a more roundabout path, which adds further latency. I find it interesting that, as with the AGP port, write requests are apparently so much faster than read requests (since avoiding dependancy isn't a factor with an in-order CPU), but as write access would be much more commonly used, clearly it's been optimised a lot further (at the hardware and/or software level, I can't say).
Sure the CPU has to stall, that's expected, but are you claiming that the CPU simply can't saturate the memory?
If the CPU issues issues a series of sequential reads to memory that is either flagged as uncached or simply not in the cache right now, it stalls for a time while that memory is fetched (OoO CPUs may queue up more requests), then the memory starts satisfying those read requests as quickly as it can, up to more or less the rated bandwidth of the system (naturally different instructions affect the efficiency of this). Non-sequential requests are of course a lot slower, but even those will be much faster than 16 MB/s.
For AGP memory to be significantly slower than system memory that isn't in the cache (MMU/TLB/etc differences aside), there'd have to be contention - the AGP card accessing it, or some such.
Those are very old results, and the slowdown there was due mostly to drivers that were completely unoptimised for readback (try it these days, it's quite a bit faster). Uncached memory reads should in theory be at roughly the speed of the memory itself, hundreds of MB/s at least, discounting contention.
in any case [interpolators] cannot be retasked to do things like running physics code
Depends on the specific problem, of course. I've often found the fixed-function hardware to be handy for e.g. interpolating between entries in a LUT (bilinear samplers), accumulating weighted results (blend units), threshold rejection (alpha test)... work that otherwise the CPU would have to do. It all adds up. I'd be surprised if HavokFX et al didn't make significant use of them.
You're certainly right about them being hard to compare on paper, but as I said, the best choice for the game will more likely depend upon what CPU & GPU time/bandwidth is still available for use (which may well end up being the CPU, Cell being hard to fully utilise).
Oh, and while you're right about AGP, you're wrong about physics on the PS3, as a sibling poster points out. GPU physics does not necessarily require CPU readback. Both platforms will have impressive physics middleware, PS3's RSX is quite capable of physics calculation, and Cell is in many ways more suited to it than the 360's CPU.
That's why reading from AGP memory on a PC is slow, even though AGP memory is actually just a buffer in regular system memory.
Reading from "AGP memory" is uncached & slow, but not that slow. Readback from the GPU's local texture memory across the AGP port is what's really slow, because it's effectively a 33 MHz PCI bus in that direction. Though even that isn't anything like as slow as 16MB/s (once GPU vendors bothered to optimise that driver path at least).
it can just instruct the GPU to write the results to system memory
Quite true, and it's the obvious solution.
when does it make sense to run physics on the GPU? Well, when the GPU has more vector gigaflops than the CPU.
Try 1.8 TFLOPS vs 150 GFLOPS. Cell is great for doing vector crunching of physics transformations, but RSX has way more vector hardware (think 48 pipes instead of 7, plus assorted bilinear interpolation units at each end, comparison units etc etc). This is offset by RSX's lower clock and less-optimal architecture, but the GPU is still a very powerful cruncher.
RSX has its own 22 GB/sec bus seperate from Cell's 25 GB/sec bus
Except, of course, if it wrote to its local memory the Cell wouldn't be able to read it faster than 16 MB/s. Fine for non-gameplay physics, as with HavokFX, but if it wants to do physics that affects the player or AI, it has to use the CPU's main memory. Perhaps it could do some on each?
Of course the PS3 will be able to do physics, as least as well as the 360. Where it ends up processing that physics will likely depend on the game - if the game already uses the CPU heavily, the RSX may well be the better choice, at least for eye-candy effects. The differences in the programming model between CPU & GPU physics will (hopefully) be mostly hidden by evolving middleware physics libraries anyway.
Nintendo have already boasted that the Wii will continue to download stuff even when you turn it off. You'd have to physically pull the plug (power or network).
Local mirrors can be free - but that's beside the point. If I want to keep the line clear (for gaming or VoIP or just because), then I'd rather not be forced to unplug the Wii every time because it thinks it knows better than I do.
Slashdot Mirror
Someone tell Pixar! :-)
Though, geez, a network crash could be pretty nasty...
Funny, I can do the same thing on an iPod, by just reducing or increasing the bitrate of the songs I store on there. Exactly the same principle. Tape is just lossy magnetic samples of an analog waveform after all - faster speed is simply more samples/sec.
Of course, tape sucks in so many other ways...
Read this post (also here). I quote: "Apple will no longer be selling maintenance for Shake and no further software updates are planned".
Apple will not be making the base product more stable, they're dropping it completely, in favour of some future product (apparently due around 2008). While the price drop will doubtless expand the market into the low end in the short term, the high-end users started their move away from Shake the moment Apple bought it (at least, those that wanted to keep running Linux and not Mac OS). Perhaps I didn't stress enough how important support is to high-end customers. Now the end of the road is clear, nobody is going to want to invest significantly in the Shake platform - including major plugin vendors.
I don't doubt Shake's technology will live on, but whatever Apple is working on will be a new product, and will not be released for Linux. Since something like 90% of Shake licences were Linux (which isn't even getting the price drop), most users will not see this as a good thing.
Try actually doing a real job in each. You'll quickly see why people pay for the commercial packages.
I'm all for lowering barriers to entry, and decent software at cheap prices is a great thing for the masses (many of whom learn on pirate copies anyway). But I doubt this move will be welcomed by the major studios.
It costs a lot of programmer time to develop decent software, especially complex apps like this. And the smaller your target market, the higher the cost per copy, simple as that. Basic economies of scale.
Now add to that the cost of in-depth technical support for each of your customers - not just installation problems or bug fixes, but answering usage questions, suggested techniques, basic training, occasional specialised plugin development, timely response to feature requests, rapid response to critical bugs, and the assurance that if the studio (who has committed their workflow to your product) ever has a show-stopping issue, you'll do whatever it takes to help them through it. THAT's what the high prices are for, and in my experience, most professional studios are more than happy to pay it.
Thus, we see Apple dropping all of that, as $500/copy simply can't cover the cost of supporting a complex and mission-critical app like that. The biggest studios may find it necessary to drop $50K on the source code to be able to fix bugs themselves, but not many would be willing to continue full development (not their business), and will doubtless be looking at phasing out Shake in favour of more actively-developed alternatives (most have been doing this for some time).
Ironically enough, Dragon's Lair was one of the very few original Xbox games to support full 1080i.
a THIRD version with HD-DVD support.
GP was referring to 2nd gen games, not another model of the hardware. As for your other comments:
A) The base model is for low-budget buyers who just want to play the new games. If they wanted all the add-ons, they wouldn't buy the base model, would they?B) I assume you're claiming the developers won't take advantage of the HDD. They already are, plus many others use it for pre-caching etc if it's there. There are a lot more HDD-equipped 360s out there than base models, so developers have little to lose in supporting it.
C) The HD-DVD won't be used for games, MS have confirmed that. Movies are the point. Yes, it will bring the cost up to PS3-levels, but only if you want to pay for that feature. Unlike the PS3, the extra cost is optional.
I've spent the last 10 years writing commercial software for cinematic effects, actually.
And you? You don't have even the credibility of a name. Come back when you've got something more than unimaginative insults to offer.
Wow, you have been busy here, haven't you? All those attempted trolls, and not one of them good enough to get a decent reaction.
HDR textures can take up something around 4x the space
Only when uncompressed, and even then they need take no more than 2x. There are numerous fast and efficent representation method for stored HDR images that take up little more than non-HDR. This is something I have a lot of experience in. Oh, and less texture compression usually means slower loading, as there is more data to fetch from disc. Better to encode it tighter, get it off the disc quicker, then decompress it in the background with a spare CPU core.
And 640k is enough for anyone, right?
A common misconception. A better quote from our mate Bill: "Understand that this is the last physical format there will ever be. Everything's going to be streamed directly or on a hard disk."
Developers may or may not be happy with DVD9, but even if MS changes their minds, few developers would ever consider releasing a 360 game on HD-DVD. Especially if the HD-DVD add-on penetration rate is only 10% as you suggest.
All of which involve compromise of one form or another
Everything's a compromise. Sony's is to charge more.
CD - developed primarily by Philips, as I recall. Firewire - Apple. Sony developed DVCAM, less sure about MiniDV, though they certainly pushed it in the early days. You're right, Sony has had its many successes too, but although it's way too early to say for Blu-Ray, UMD's recent and public failure didn't exactly endear Sony movie formats to the studios.
You may have forgotten what 360's were going for on ebay.
Sure, but how many people actually bought them at those prices? 500? There will always be people prepared to pay whatever it takes, and Sony will have its fair share. Selling a million probably won't be hard, as you say. Selling ten million at $500 will be a lot harder, I predict.
As for myself, I was indeed considering a PS3. There's a couple of games that drew my eye, but mostly it was the prospect of a cheap Linux HTPC with Blu-Ray, HDMI etc. That idea kinda fell through when it turned out not to be cheap after all. Maybe in a few years when it's under $300, but who knows what else will be available then.
As other people have pointed out, unlike all other console add-ons, this one doesn't require support from game developers to be useful. It's much more comparable to buying a 1/3-price standalone player, except that its market is limited to Xbox 360 owners. And, unlike Sony, MS don't care if they sell to a mere 10%, they don't have a vested interest in pushing the format on us no matter what.
As for the "fifteen discs of content", come on, you can do better than that :-) Right now it's an infinite multiple of available Blu-Ray and PS3 media put together. Let's ask that question again in November, when it's more meaningful.
Cool, that's one at least. Good news for the Samsung HL-S5687W owner(s) out there. I assume it's out of pre-order by now.
The TV Authority page actually seems to contradict the Samsung specs page (it says "two smart component video (Y/Pb/Pr) inputs that accept 480p/720p/1 080i signals."), but I think we can accept Samsung's word here.
Now all we need is some real evidence that the PS3's component output can also do 1080p, on the low-end model.
... it's not going to be used for games?
It's for playing movies, nothing else. It will be bought only by people who want to play HD movies (because it's cheaper than a standalone player), and being an optional add-on, it has the not-inconsiderable advantage of saving money for everyone else.
it's imperitive that people who are buying the PS3 buy the $500 model without HDMI. You can still play games at 1080P.
Sure you can, but without any consumer-level display devices that will accept 1080p over component, how are you going to see them while you play?
HDMI is the future, with or without HDCP.
It's quite possible to transmit a 1080p signal over component. The spec allows for it - take a look sometime.
However, finding a consumer display device that will accept a 1080p component signal is another matter entirely. I'm not aware of any (and no, the Westinghouse LVM-42W2 won't do it).
The PS2 has already seen a number of two-disc games
Early PS2s could only read 4.7GB from a DVD. Are there any dual-layer gamediscs for the PS2? Are there any two-disc games for the Xbox? Besides, there are many more possibilities today for keeping content size down than there used to be, especially if the game design is at stake.
But what if [Sony] are right? That's a possibility that people seem to not understand
Betmax. Minidisc. UMD. Memory Stick. The fact that it's Sony makes it less of a possibility that Blu-Ray will succeed than it otherwise would be.
Blu-Ray being included in a console that will sell in the millions and tens of millions
You may not have noticed, but Blu-Ray being included in the PS3 is the single biggest factor working against it selling in the tens of millions. Gamers are being turned off by the price of a component they don't particularly care about. HD movie freaks have the option of a same-priced player, today, that will undoubtedly get cheaper faster than the PS3. Sony have successfully reduced their market to die-hard fanbois and compulsive early-adopters. The rest of us will wait a year or or two for things to settle down, by which time player prices will be low enough that the "bonus" Blu-Ray player will hardly be a factor.
Hello again.
People like to think that Microsoft will not deliver games on HD-DVD, because it would anger current owners.
Microsoft have repeatedly confirmed that they will not ship games on HD-DVD.
No-one wants multi-disc games, publishers as well as gamers, but they simply won't be necessary, even on DVD, for the vast majority of games.
What takes up the most space on a disc? Not gameplay code, or even textures. It's cut-scene video - and there's many ways of reducing that. Faster, multicore CPUs can use better compression algorithms (lower bitrates or resolutions are also possible, in a pinch). Game-rendered cutscenes take a fraction the space, are already popular, and getting more practical all the time. Even HD textures aren't a big deal - they can be compressed on disc with better algorithms too, and similarly, procedural (or procedurally-modified) textures are fast, popular and ever more practical with today's GPUs.
In the PS2's day, MPEG2 cutscenes were all the rage (and early PS2s couldn't even read dual-layer discs), but we've moved beyond that now. When faced with long cutscenes, a PS3 developer may have the space to be lazy, but a 360 developer has the devkit tools to be efficient.
Memory latency is typically far lower for sequential accesses, and that is what its rated bandwidth is dependant on, not random accesses (which are obviously slower). Given ideal conditions (helped by prefetch buffers), an OoO CPU can queue up contiguous requests direct from memory at a rate not that far off the memory's rated bandwidth. Don't forget, a CPU can process numerous instructions in one memory bus cycle, and (code permitting) can certainly queue up more requests before the queue empties. So long as the queue does not empty, the memory does not need to miss a beat. Lots of apps do this, including memory benchmarks and the image processing app I develop. AGP memory is no exception, unless the graphics card is contending for access.
An in-order CPU can still get very good results in most cases by doing sequential accesses (it would likely still have prefetch buffers), and doubtless this is how the PS3 is able to quote its 25GB/s to system RAM. It can probably achieve most of that, with careful coding. Cell access to RSX memory is a completely different matter; clearly requests follow a more roundabout path, which adds further latency. I find it interesting that, as with the AGP port, write requests are apparently so much faster than read requests (since avoiding dependancy isn't a factor with an in-order CPU), but as write access would be much more commonly used, clearly it's been optimised a lot further (at the hardware and/or software level, I can't say).
Sure the CPU has to stall, that's expected, but are you claiming that the CPU simply can't saturate the memory?
If the CPU issues issues a series of sequential reads to memory that is either flagged as uncached or simply not in the cache right now, it stalls for a time while that memory is fetched (OoO CPUs may queue up more requests), then the memory starts satisfying those read requests as quickly as it can, up to more or less the rated bandwidth of the system (naturally different instructions affect the efficiency of this). Non-sequential requests are of course a lot slower, but even those will be much faster than 16 MB/s.
For AGP memory to be significantly slower than system memory that isn't in the cache (MMU/TLB/etc differences aside), there'd have to be contention - the AGP card accessing it, or some such.
See this article from a DRI developer
Those are very old results, and the slowdown there was due mostly to drivers that were completely unoptimised for readback (try it these days, it's quite a bit faster). Uncached memory reads should in theory be at roughly the speed of the memory itself, hundreds of MB/s at least, discounting contention.
in any case [interpolators] cannot be retasked to do things like running physics code
Depends on the specific problem, of course. I've often found the fixed-function hardware to be handy for e.g. interpolating between entries in a LUT (bilinear samplers), accumulating weighted results (blend units), threshold rejection (alpha test)... work that otherwise the CPU would have to do. It all adds up. I'd be surprised if HavokFX et al didn't make significant use of them.
You're certainly right about them being hard to compare on paper, but as I said, the best choice for the game will more likely depend upon what CPU & GPU time/bandwidth is still available for use (which may well end up being the CPU, Cell being hard to fully utilise).
Ironically called "Cell Factor".
Oh, and while you're right about AGP, you're wrong about physics on the PS3, as a sibling poster points out. GPU physics does not necessarily require CPU readback. Both platforms will have impressive physics middleware, PS3's RSX is quite capable of physics calculation, and Cell is in many ways more suited to it than the 360's CPU.
That's why reading from AGP memory on a PC is slow, even though AGP memory is actually just a buffer in regular system memory.
Reading from "AGP memory" is uncached & slow, but not that slow. Readback from the GPU's local texture memory across the AGP port is what's really slow, because it's effectively a 33 MHz PCI bus in that direction. Though even that isn't anything like as slow as 16MB/s (once GPU vendors bothered to optimise that driver path at least).
it can just instruct the GPU to write the results to system memory
Quite true, and it's the obvious solution.
when does it make sense to run physics on the GPU? Well, when the GPU has more vector gigaflops than the CPU.
Try 1.8 TFLOPS vs 150 GFLOPS. Cell is great for doing vector crunching of physics transformations, but RSX has way more vector hardware (think 48 pipes instead of 7, plus assorted bilinear interpolation units at each end, comparison units etc etc). This is offset by RSX's lower clock and less-optimal architecture, but the GPU is still a very powerful cruncher.
RSX has its own 22 GB/sec bus seperate from Cell's 25 GB/sec bus
Except, of course, if it wrote to its local memory the Cell wouldn't be able to read it faster than 16 MB/s. Fine for non-gameplay physics, as with HavokFX, but if it wants to do physics that affects the player or AI, it has to use the CPU's main memory. Perhaps it could do some on each?
Of course the PS3 will be able to do physics, as least as well as the 360. Where it ends up processing that physics will likely depend on the game - if the game already uses the CPU heavily, the RSX may well be the better choice, at least for eye-candy effects. The differences in the programming model between CPU & GPU physics will (hopefully) be mostly hidden by evolving middleware physics libraries anyway.
Nintendo have already boasted that the Wii will continue to download stuff even when you turn it off. You'd have to physically pull the plug (power or network).
Local mirrors can be free - but that's beside the point. If I want to keep the line clear (for gaming or VoIP or just because), then I'd rather not be forced to unplug the Wii every time because it thinks it knows better than I do.