Of course, if high-def FMV really such a bad thing? There are lots of good games that use FMV instead of in-game cut-scenes, because even to this day, machines are not powerful enough to display that kind of detail in real-time. Should such games change their design just for disk issues, or drop to SD for cutscenes?
There are lots of *good* games today for which a straightforward "next-gen" port could not be done within the confines of DVD. Star Ocean is a perfectly good game, FMV or not, and you'd need 3-4 DVDs to do a high-def version.
Launching early though doesn't necessarily help you out, if you're the odd-man that launches early. The dreamcast launching early didn't help Sega, and the XBox 360 launching early hasn't given Microsoft the enormous lead they'd hoped.
It is highly unlikely that the price of the 360 can come down before the PS3 launches. The price won't likely come down until after the first die shrink (unless Microsoft wants to lose even more money on the system), and that's not going to happen until 2007.
I think people (Americans in particular), need to rid themselves of the delusion that everything that is not "fair" must be opposed in full at every turn. Most often, committing the lesser of two evils is a good thing.
Of course its easy to be cynical, but has it ever occurred to anybody that Al Gore is a senior advisor to Google because he's one of the relatively few politicians well-versed in technology? You can hate his policies all you want, but at least have the decency to admit that the man has competencies, and advising a big technology company like Google fits right in with one of those compatencies.
As for 98% of Google employees supporting Democrats --- do you think there is some sort of conspiracy in Google to support that party? Or do you think that Google employees are free to support whomever they want, and just happen to support democrats because they are by and large young professionals working in the technology industry who happen to live in overwhelmingly liberal areas (look at the places where Google offices are located).
Insinuation of bias without being able to offer proof of bias is one of the most basic problems with political discourse in this country, and it has to stop.
Whether the CPU can saturate the memory depends on how many loads the CPU can queue up. On all practical CPUs, the load buffer is too small to saturate the memory with uncached reads. The problem is that the latency of the memory is a lot higher than the throughput of the memory. The memory can return some number of bytes each bus cycle, but the delay between a request arriving and the request being serviced is dozens of bus cycles. The memory is deeply pipelined, so the only way to saturate memory is to submit requests such that the pipeline is full. For every pipeline bubble (ie: each bus cycle during which the CPU did not issue a request), you'll have a bubble in the return stream, and a decrease in the bandwidth.
With an in-order CPU, which has to stall on cache misses, you can only issue a single memory request during the dozens of bus cycles the first one takes to be serviced. Though the memory is capable of sending one word per bus cycle after the first, it won't, since there were no read requests behind the first one to service. The net result is that instead of transferring one word per bus cycle (which is how the memory is rated), it transfers one word for every one or two dozen bus cycles. On the PS3, a single round-trip memory access from the Cell over the Flex I/O to the RSX, over the MIC, to the GDDR3 probably has a latency of 500+ ns. That means the Cell can only request 16 bytes (the width of the bus) every half micro-second. That gives you a figure of 32 MB/sec, which accounting for various inefficiencies explains the 16 MB/sec figure quite well.
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.
I can see them being faster on PCI Express (which does apparently support snooping memory accesses -- I was wrong on this point), but I doubt its much faster on AGP. Uncached reads cannot approach saturation of the underlying memory. When you bypass the cache, you're limited in the number of reads you can queue up before the results from the first one get back. Even in a deeply OOO CPU, this limit is something like 32 reads, then the core has to stall waiting for the first read to finish. That means if your memory latency is 500 cycles, you can only issue 32 reads before stalling for like 450 cycles.
First, I don't think the author of this article really has any credibility. Someone reporting about consoles at a technical level really should know something like this. The video memory read issue on the Cell isn't some sort of bug in the PS3 design. It's a problem endemic to almost all graphics architectures that have a seperate CPU and GPU, connected by a non-coherent link. The only way to "solve" the problem would be to do something like connect the CPU and GPU with coherent Hypertransport, like how multiple Opterons and their local memories are connected together.
As for the RSX being limited to a triangle setup rate of 275 million triangles per second (if it is even true!), that's entirely a function of the write bandwidth from the Cell to the video memory, and the triangle setup engine within the RSX. The slide showed that the achieved write bandwidth from Cell to video memory was 4GB/sec, which is about the same as the total theoretical upload bandwidth of the 16x PCIe link found in PCs. Since the PCIe link doesn't appear to be a bottleneck for triangle rate on the PC, the 4GB/sec of write bandwidth likely isn't the bottleneck. Therefore, the bottleneck must be the triangle setup engine within the RSX itself. Whether this is a problem, I really can't tell you. The only thing I can say is that the RSX is based on the GeForce 7900, while the Xenos in the 360 is related to the Radeon X1900. Since these two cards are comparable in practice, I'd wager the RSX and Xenos will be comparable in practice too. In that case, the 275m triangle limit would be a theoretical limit for the RSX, but not one that's not approached in practice anyway because of bottlenecks elsewhere.
Ok so the video memory has a bandwidth of 16M/s which is slow, very slow.
The video memory has a bandwidth of 20+ GB/sec. However, the video memory isn't connected to the Cell, it's connected to the RSX. The Cell has its own memory, called "main memory" (obviously). The 16MB/sec figure is what happens when the Cell tries to read directly from video memory, through the RSX.
But my understanding of the cell design is that it has 7 co-processors and that it's supposed to split all of it's calculations... especially graphical ones.
Cell doesn't do graphical computations, at least not in the PS3. The RSX handles graphical computations.
This parralel processing is what makes the cell teh awsome since each core is actually pretty slow.
Actually, each core is not slow so much as it is simple. For highly tuned tasks, a single Cell coprocessor (called an SPE) can be very fast. For example, IBM released benchmarks showing that a single SPE could transform vertices twice as fast as a PowerPC 970, which is itself no slouch in vector computations.
Now because the graphics system is tied with the general computing unit it's possible that both will be used concurrently (in fact it seems clear that both will be running through the cell at the same time) now where do these calculations get output to and what are they useful for after they are resolved?
There is no "graphical computing unit". There are just SPEs, which can be used for whatever you want. Any calculations they do will usually be output to main memory, which is connected directly to the Cell processor. If these results are useful for the RSX, say, Cell decompresses a texture the RSX needs to use, or generates some geometry the RSX needs to draw, then the Cell can command the RSX to download these results into video memory and process them there.
Now obviously I'm not a cpu designer but using the graphical subsytems for general calculations seems to imply that you need to be able to access the results, fast.
The graphics subsystem in the PS3 is the RSX. You could use it for general calculations, though it'd be kind of stupid given you have so many FLOPS on the Cell, and if you wanted to do that, you could have the RSX write its results directly to main memory, which the Cell can access at full speed.
Can someone explain why this is wrong? Will the cell be able to write to general memory rather than graphical memory? Will it be able to differentiate between graphical calculations and other calculations?
The Cell will normally not access graphical memory directly, except to send command buffers to the RSX. The RSX will do stuff like download textures to video memory from system memory. Cell has its own main memory that it can use for computations, that it can access at full speed.
It seems like most people's arguements about why this bandwidth thing isn't a big deal hinge on how things were done in the past, meanwhile all the talk about using the cell as a supercomputer outline why it isn't like things that came before.
I don't see how Cell used as a fast vector computer would be affected by this issue. Any Cell system designed for supercomputing won't even have a graphics processor or a dedicated graphics memory. It'll just use the Cell's local 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).
Yes, it really is that slow. See this article from a DRI developer: DRI article. Also, remember the hit for uncached accesses for an in-order CPU like Cell or Xenon is even larger. An out-of-order CPU can keep working after issuing a read, up to the depth of its load buffer. That means it may be able to transfer 32 words (depending on the size of the load buffer) very 500 cycles (or however long the memory latency is). An in-order CPU cannot do even that, and must wait the whole memory latency after every load.
Try 1.8 TFLOPS [wikipedia.org] 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.
Of course, that's why I said "general pupose" gigaflops. The GPU has a lot of its "1.8 teraflops" tied up in non-reprogrammable special-purpose hardware. Each of the 24 pixel shaders and 8 vertex shaders have a pair of 128-bit FPUs. That gives it a 128 gigaflops peak throughput. The rest of the "1.8 teraflops" is tied up in things like interpolators that compute per-pixel parameters like texture coordinates across the triangle. These units are not full FPUs (thus they aren't really a general purpose FLOP), and in any case cannot be retasked to do things like running physics code. That's why things like GPGPU get only 60 usable gigaflops from a top of the line ATI graphics card that's rated at 1+ teraflops.
The entertaining thing is that this particular problem is something quite natural to PCs. Framebuffer accesses on PCs have been slow ever since graphics cards started sporting dedicated coprocessors. You take a brand spanking new PC, and start downloading stuff from the framebuffer, your transfer rate will be abysmal.
The problem here isn't just a lack of embedded hardware knowledge. It's just a lack of knowledge.
1) PCIe versus AGP is irrelevent. The PS3 has an extremely fast (25+ GB/sec) bus between the CPU and GPU. The lack of bandwidth isn't what's causing the slowdown. Rather, it's the lack of cache coherency. You see, in a NUMA system (where each processor has its own local memory), the caches of the CPUs must be synchronized in some way, so that CPUs see a consistent view of whats in the two memories. The synchronization is done through what's called a cache coherency mechanism. In the absence of a cache coherency mechanism, whenever one CPU wants to access the memory of another CPU, it must do so via an uncached access. This isn't so bad for writes, because the processor can just fire off the write into a buffer, and keep computing. For reads, this is a killer, because the processor is stuck waiting hundreds of cycles for the read to complete before issuing the next one. Neither AGP nor PCIe have a built-in coherency protocol. 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. The address range containing the AGP memory must be mapped as uncacheable by the processor.
2) There is no indication that PS3 cannot handle doing physics on the GPU. On the PS3, the GPU can write to system memory. The main CPU doesn't need to read the results of the physics calculations from the GPU --- it can just instruct the GPU to write the results to system memory and read them from there.
3) Don't try to apply PC-gamer thinking to console architectures. Use your head, and think things through. First, why would anybody want to run physics on the GPU? Well, physics calculations are very vector and bandwidth intensive, and the GPU has a lot of vector processing power and bandwidth. Second, when does it make sense to run physics on the GPU? Well, when the GPU has more vector gigaflops than the CPU. On a PC, the CPU can do less than 10 gigaflops, while the GPU can do over (general-purpose, according to gpgpu.org) 60 gigaflops. The CPU has maybe 6GB/sec of memory bandwidth, while the GPU has close to 40 GB/sec. So running physics on the GPU makes sense, in a PC. Now, try to apply this thinking to the PS3 and XBox 360. Do their GPUs have more general-purpose gigaflops than their CPUs? Well, Xenon can do about 80 gigaflops, while Cell can do about 150 gigaflops, so no. Do their GPUs have more memory bandwidth than their CPUs? Well, Xenos shares a 25 GB/sec bus with Xenon, while RSX has its own 22 GB/sec bus seperate from Cell's 25 GB/sec bus. So no on that count too. So now come to the conclusion: does it make sense to do physics processing on the GPU in either the PS3 or the 360?
4) If you're impressed by the potential of physics processing in games, then you should be psyched about the PS3. The whole point of Cell is to have a lot of vector gigaflops that can be programmed more easily than the vector gigaflops available on the GPU. In fact, a PhysX chip is organized very similarly to a Cell chip. It's consists of a bunch of vector coprocessors, each with a local memory, and a central control processor to feed data to the coprocessors. Moreover, if you're going to be doing general-purpose computations on the GPU, you can throw the whole "360 is easier to program" argument out of the water. While the Cell might be more complicated to program than a symmetric multicore processor Xenon, writing code for the SPE is a lot easier than writing code for a GPU's shaders. At least an SPE somewhat resembles a regular CPU, albiet with a weird memory model. A shader in a GPU is an entirely different beast, with an even weirder memory model (though one that is naturally suited to graphics code).
One word of advice. Some of the issues relating to consoles are very technical. Don't spout off about things if you don't really understand the technical details underlying them. We really don't need more FUD on Slashdot.
People use the GPU to do physics on PCs, because PCs don't have 7 vector coprocessors to do physics on. There is no reason to do physics on the GPU in either the XBox 360 or the PS3, because they've got lots of vector processing power on the main CPU.
"I'm sure you'll get a lot of these messages, but hell, you deserve it.
The slow read speed you noted in the slide is for Cell reading from the RSX's local memory. Such accesses are expected to be very slow. If you look at this USENIX article from one of the Linux DRI folks, you can see this quite easily:
He shows how painfully slow it is to read from AGP or framebuffer memory (14 and 5 MB/sec, respectively), on a Rage 128 graphics card. For the CPU to framebuffer read, which is the equivalent to what we're talking about here, the read speed is 1/40th the write speed. At 16MB/sec read and 4GB/sec write, the PS3 is actually right in line with what can be expected of modern GPU architectures.
Reading from the framebuffer is just slow unless you have a unified memory architecture. The CPU and the GPU aren't cache-coherent, which means every access to framebuffer memory (or even AGP memory, which is actually a chunk of system memory allocated to the GPU) must be an uncached access. Uncached accesses are just plain slow, on any architecture.
The way your article is written, it makes it seem like Cell reads its local storage at 16 MB/sec. That is, of course, bollocks, since IBM has shown benchmarks of the Cell local storage achieving 98% efficiency. If you had any journalistic integrity at all, you'd post a retraction on your site, and a clarification of the technical issues involved."
Becuase he's right. If you read the slide carefully, you'd realize this. THere are two CPUs in question here (the Cell and the RSX), and two banks of memory (main, and local). Main memory is obviously the memory associated with the CPU. Local memory, thus, must be the memory associated with the RSX. The matrix shows that the read speed of memory associated with the RSX, when accessed from the Cell, is really slow.
That's not really news. It is a highly assymetric memory, effectively "write only" as you put it (from the perspective of the Cell), but that makes it like another very useful type of memory: a FIFO buffer. From the prospective of the source end of the FIFO, it is effectively a write-only memory. However, FIFOs are very useful in producer-consumer architectures, where you have one end that produces the data, and another end that consumes it.
Which is exactly what we have here. The Cell CPU can produce data and write it into the local memory, and the RSX can use that data to texture the scene. The Cell CPU can produce command buffers and write them into local memory, and the RSX can consume those command packets to figure out what to draw. The fact that the Cell CPU can't read them back very fast is irrelevent, there is really no need to.
Which is, of course, why almost all non-UMA graphics architectures work this way. Reading from the local memory of a PC graphics card is also an extremely slow process. We're talking tens of megabytes per second over a 4GB AGP bus. That really doesn't hurt anything --- because you almost never need to read from GPU memory.
This article takes the statement completely out of context, and the Slashdot reaction to it is just ridiculous.
Anybody who didn't know reads from GPU memory are slow turn in your geek card right now! On a PC, even with a 4GB/sec AGP connection, reading from the framebuffer can be as slow as 75MB/sec. This has been true for a very long time --- GPU's don't like anybody else directly touching their framebuffer. That's why Microsoft took direct framebuffer access out of "DirectX". It's a performance killer on modern systems. Sony's "work around" for the situation, using the GPU to handle texture uploads/downloads, isn't news --- it's common knowledge to anybody who has done any graphics programming on modern hardware.
That really wasn't my point. What I'm trying to get at is that people refer to the $300 360 as crippled, because its missing a fundemental component: the HDD. The $500 PS3 isn't missing any fundemental components, as a gaming system. It is thus unfair to call it "crippled". The $600 PS3 is a justifiable "extras" package. It contains stuff that you'd want if you cared about the PS3 as a media center and HD video player. If you don't care about these things, and the people complaining about the PS3's price say they don't --- they just want a gaming machine, then its dishonest to pretend that the $500 PS3 doesn't exist, because it is "crippled" along some dimension you don't care about anyway.
2) I'm not paying $1600 for a TV. I won't pay that for a computer. Wake me up when they are $300 or less.
Lot's of people pay $1600+ for a TV. Are you living in the same United States I am? I honestly cannot remember the last house I visited that did not have a big-screen TV in it. It's not really a luxury item anymore. $1600 just isn't that much for something someone spends a significant amount of time watching, and will use for four or five years at least.
4) how much of a footprint does a PC game take? Anything that is not on the HD will need to be loaded every time. A 2x BD-ROM reads slower MB per MB than a 12x DVD-ROM. If they really need the 25-GB you will have a hard time putting a significant amount of multiple games on the HD.
Obviously, you don't understand the concept of caching. I mentioned CPU caches for a reason: how does a 1-4MB CPU cache perform effectively when your main memory is 1000x bigger? The answer is because you only need to work with a subset of that data at any given time. That's why a 20GB hard drive can effectively cache lots of BD games. It just needs to store enough data to prevent obvious delays. For example, the core game engine could be stored on the HD, so the game UI pops up immediately without any load time. In an FPS, the system could be loading data for the next area onto HDD while you're playing the current level. In a multiplayer game, a map could be cached on the HDD after the first time its loaded. So once the game got going, the load-times would be very short. And of course, there is no reason to cache things like videos or music tracks, which take up a lot of space but can be streamed in from disc during the game.
Could expand for you... but will not expand for the layman. Will likely come at a steep cost. Wii again has an embedded browser. Truthfully, they will make Linux for all platforms, but honestly no system will have a OS that is so easy, cheap, and useful that John Q Public will bother.
What do you mean "could expand for you"? Sony is a consumer products company. They're not going to hand John Q Public a Linux command line! Linux will be used as a platform on which task-specific software can be built. So for example, if Sony adds DVR capabilities, Linux would be used as the OS, but the UI would be some Tivo-like DRV software. And what makes you assume that extras will come at a steep cost? The PS2 hard drive upgrade is $100 bundled with a game. Was that expensive? The PS2 didn't even have expensive add-ons like keyboards, although Sony could have done that. It just used regular USB keyboards.
When I say "tweeked", I mean slightly modified. All the chips in in this generation are not "tweeked" versions of the PPC601 --- they look more like a PPC601 internally than they do a Pentium 3. On the other hand, it is fair to say, for example, that the Power5 is a "tweeked" Power4, or that a Pentium-3 is a "tweeked" Pentium 2. I should also point out that the Pentium 3 (Katmai) and the Pentium 2 (Klamath), had different codenames.
The most precise reports I've seen thus far indicate that Hollywood and Broadway are "tweeked" versions of Gecko and Flipper, in the "Pentium 2 to Pentium 3" sense of the word. Such reports are consistent with reports of a 2x performance improvement. A 90nm die-shrink, with a little bit of circuit tweeking for the new process, could result in single-chip solution 1/2 the size of just Flipper or Gecko by itself. The resulting chip could also likely run at twice the clockspeed without pushing the thermal envelope. That's be consistent with all the reports, and would be extremely cheap for Nintendo to make.
Of course, those reports could be wrong. Broadway and Hollywood could indeed be genuinely new chips. In that case, I have a very hard time believing the performance improvement is only 2x. The Gamecube's CPU was about 50 mm^2, and its GPU was about 100 mm^2. It had a 162 MHz 128-bit bus to its 1T-SRAM. For reference, the PS3 CPU is 230mm^2, its GPU is close to 200mm^2, and it has 2 128-bit busses, one to VRAM and one to main RAM. If the Wii followed the same development process as the GC, to hit the same size targets, and thus similar costs, Nintendo would get a *lot* more than a 2x improvement in performance. Within the 50mm^2 envelope, you could fit a pair of Gecko cores running at 1+ GHz, with a substantial boost in cache to top it off. Within the 100mm^2 envelope, you could fit one of ATI's RV515 chips, with 4 pixel shaders, 4 vertex shaders, a full palette of 3D effects, running at 500 Mhz. To top it off, you could clock the 1T-SRAM at 700 MHz for over 11GB/sec of memory bandwidth. These are all conservative assumptions, working from tech that is already very cheap today.
The resulting system would be a lot more than 2x more powerful than the GC. It'd be closer to 4-5x more powerful, and could make use of modern features like pixel shaders while maintaining performance. The fact that Nintendo isn't citing bigger numbers points very strongly to the Wii being a "tweeked" Gamecube, not a substantially reworked design.
As for the PS3, hardware does have intrinsic value, in the sense that it has an intrinsic cost. That value may not be worthwhile to a particular consumer, but there is little arguing that the intrinsic cost of the components in the PS3 are not at all out of line with its selling price. It's not like Sony is taking $50 of components and trying to sell them for $500.
The launch prices of the PS1 and PS2 were both 50% more than the launch prices of the N64 and Gamecube. That didn't stop Sony from selling metric assloads of them.
If the initial specs of the Wii are accurate (die-shrunk GC chips), then, yes. Nintendo sells the current GC hardware for $99 at a profit. If the Wii is indeed a tweeked Gamecube like everyone is reporting, then at $200 Nintendo is going to make a nice amount of money on the machine. Their development cost for the console was minimal, and on a modern 90nm or 65nm process, the whole Gamecube chipset can be put on a single chip with a very small die size. Unless the gyros in the controller are super expensive, their manufacturing cost is going to be tiny.
The PS3 is a serious amount of hardware. It's got a big CPU and a big GPU, each connected to some expensive RAM and with some fat busses inbetween. You might argue that this hardware is not necessary, but you can't argue that its cheap. Sony is not overcharging for the PS3, by any reasonable conception.
1) No ICT on BluRay means HD without HDMI. 2) What do you mean "gaddamn expensive"? Good 1080p TVs are down to $1600. That's not cheap, but in the USA anyway, not really that expensive either. 3) Games don't use ICT! Even if movies do start using ICT, locking out 1080p, games won't. 4) Yes, and a 4MB L2 cache couldn't possibly do a good job caching 2GB of system memory. 5) Linux support means the potential of expanding the PS3's capabilities. Consider a PS3 home media server, or web browsing and e-mail, etc. Consider DVR add-ons, or consolidation of a bunch of other gadgets people spend $200-$400 on seperately. 6) The gameboy had tilt sensitivity, really? 7) Good point about the DS connectivity.
The lack of a hard drive in the XBox 360 cripples it, because eliminates a fundemental feature that can be used in games. There are no fundemental gaming elements missing from the low-end PS3. The PS3 will do 1080p over component (like some DVD players already do). Hell, it even has perks like wireless controllers. The only thing the high-end XBox has that the low-end PS3 is missing is a remote, which you don't need if you consider the PS3's media capabilities useless. The two PS3 models are entirely sensical. The $500 PS3 has all the gaming elements, and the $600 PS3 adds all the media extras.
The bottom line is this. If you're in it just for the gaming, its just plain dishonest to claim you need the $600 PS3. That model adds no gaming elements to the console. If you're in it for the video, then $600 is a hell of a deal for a combo gaming machine/Blu Ray player.
It has nothing to do with being a graphics whore. I've been playing video games since the 1980s. I've played all these "simple but fun" games all these Wii fanboys keep talking about. And you know what? They were a ton of fun back in the day, but this is 2006, and I'd rather play a game that looks like it was made in 2006.
People are intensely visual creatures. The visual aspects of products are important, and change with time. Products with out-of-date visual styles are perceived negatively, even if they would not have been at their original time. Arguing that its "whorish" to hold a game's outdated graphics against it is like saying its "whorish" to hold a suit's 1970's style against it. Hell, that polyester number covered you up just great in 1970, are these fancy new suits really that much better?
As for 480p being enough, that's bullshit. Play a first person shooter at 640x480 on a 24" LCD, then play it at 1920x1200. Tell me which one is more playable, in terms of actually being able to see the shit you're shooting at. 480p looks just fine on a small TV, but big-screen TVs aren't exactly a luxury item to most people who have enough money to waste on video games, and 480p on a big screen is insufficient. I've been playing through Wind Waker this week, on a 70 inch TV, and while its great, it'd be a whole lot better if it didn't look like I needed my contacts adjusted.
1) Less than a quarter of US households have PS2s. According to Sony's research, 34% of PS2 owners have HDTVs. That makes HDTV ownership among PS2 owners twice as high as HDTV ownership among the general population. If that trend holds, at current rates of growth, the majority of prospective PS3 owners will have HDTVs in the next few years. If you can expect half of your prospective users to have HDTVs over the lifetime of the console, it makes perfect sense to offer something that lets them take advantage of it.
2) What's with the invectives? Did I call you names? Just because you don't feel a need for better technology, you shouldn't ridicule people who do. For a technology site, there are an incredible number of luddites here...
3) Your argument about the free market would be valid if:
a) If the airwaves weren't a limited public resource. It is entirely consistent, under modern economic theory, for the government to control such resources within a free market system.
b) If the current massive growth in HDTV adoption rates was the result of an impending transition deadline, but the deadline is still many years away.
As much as I'm sure you'd like to believe the current HDTV adoption is the result of "high tech dweebs" (coming from someone browsing Slashdot? Please!) and "rich idiots", you can't rationalize that position. People aren't buying HDTVs now because they're worried about some government transition in 2009 (at which point they'd have to buy a cheap digital conversion box, not a whole new TV), but because HDTVs have dropped dramatically in price, and lots of people have been switching to LCD and plasma displays (which are mostly HD), for asthetic and space reasons. They also buy it because its dead obvious to anybody with eyes how much better an NFL broadcast looks in HD versus SD resolution.
Slashdot Mirror
Of course, if high-def FMV really such a bad thing? There are lots of good games that use FMV instead of in-game cut-scenes, because even to this day, machines are not powerful enough to display that kind of detail in real-time. Should such games change their design just for disk issues, or drop to SD for cutscenes?
There are lots of *good* games today for which a straightforward "next-gen" port could not be done within the confines of DVD. Star Ocean is a perfectly good game, FMV or not, and you'd need 3-4 DVDs to do a high-def version.
Launching early though doesn't necessarily help you out, if you're the odd-man that launches early. The dreamcast launching early didn't help Sega, and the XBox 360 launching early hasn't given Microsoft the enormous lead they'd hoped.
It is highly unlikely that the price of the 360 can come down before the PS3 launches. The price won't likely come down until after the first die shrink (unless Microsoft wants to lose even more money on the system), and that's not going to happen until 2007.
I think people (Americans in particular), need to rid themselves of the delusion that everything that is not "fair" must be opposed in full at every turn. Most often, committing the lesser of two evils is a good thing.
Of course its easy to be cynical, but has it ever occurred to anybody that Al Gore is a senior advisor to Google because he's one of the relatively few politicians well-versed in technology? You can hate his policies all you want, but at least have the decency to admit that the man has competencies, and advising a big technology company like Google fits right in with one of those compatencies.
As for 98% of Google employees supporting Democrats --- do you think there is some sort of conspiracy in Google to support that party? Or do you think that Google employees are free to support whomever they want, and just happen to support democrats because they are by and large young professionals working in the technology industry who happen to live in overwhelmingly liberal areas (look at the places where Google offices are located).
Insinuation of bias without being able to offer proof of bias is one of the most basic problems with political discourse in this country, and it has to stop.
Whether the CPU can saturate the memory depends on how many loads the CPU can queue up. On all practical CPUs, the load buffer is too small to saturate the memory with uncached reads. The problem is that the latency of the memory is a lot higher than the throughput of the memory. The memory can return some number of bytes each bus cycle, but the delay between a request arriving and the request being serviced is dozens of bus cycles. The memory is deeply pipelined, so the only way to saturate memory is to submit requests such that the pipeline is full. For every pipeline bubble (ie: each bus cycle during which the CPU did not issue a request), you'll have a bubble in the return stream, and a decrease in the bandwidth.
With an in-order CPU, which has to stall on cache misses, you can only issue a single memory request during the dozens of bus cycles the first one takes to be serviced. Though the memory is capable of sending one word per bus cycle after the first, it won't, since there were no read requests behind the first one to service. The net result is that instead of transferring one word per bus cycle (which is how the memory is rated), it transfers one word for every one or two dozen bus cycles. On the PS3, a single round-trip memory access from the Cell over the Flex I/O to the RSX, over the MIC, to the GDDR3 probably has a latency of 500+ ns. That means the Cell can only request 16 bytes (the width of the bus) every half micro-second. That gives you a figure of 32 MB/sec, which accounting for various inefficiencies explains the 16 MB/sec figure quite well.
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.
I can see them being faster on PCI Express (which does apparently support snooping memory accesses -- I was wrong on this point), but I doubt its much faster on AGP. Uncached reads cannot approach saturation of the underlying memory. When you bypass the cache, you're limited in the number of reads you can queue up before the results from the first one get back. Even in a deeply OOO CPU, this limit is something like 32 reads, then the core has to stall waiting for the first read to finish. That means if your memory latency is 500 cycles, you can only issue 32 reads before stalling for like 450 cycles.
First, I don't think the author of this article really has any credibility. Someone reporting about consoles at a technical level really should know something like this. The video memory read issue on the Cell isn't some sort of bug in the PS3 design. It's a problem endemic to almost all graphics architectures that have a seperate CPU and GPU, connected by a non-coherent link. The only way to "solve" the problem would be to do something like connect the CPU and GPU with coherent Hypertransport, like how multiple Opterons and their local memories are connected together.
As for the RSX being limited to a triangle setup rate of 275 million triangles per second (if it is even true!), that's entirely a function of the write bandwidth from the Cell to the video memory, and the triangle setup engine within the RSX. The slide showed that the achieved write bandwidth from Cell to video memory was 4GB/sec, which is about the same as the total theoretical upload bandwidth of the 16x PCIe link found in PCs. Since the PCIe link doesn't appear to be a bottleneck for triangle rate on the PC, the 4GB/sec of write bandwidth likely isn't the bottleneck. Therefore, the bottleneck must be the triangle setup engine within the RSX itself. Whether this is a problem, I really can't tell you. The only thing I can say is that the RSX is based on the GeForce 7900, while the Xenos in the 360 is related to the Radeon X1900. Since these two cards are comparable in practice, I'd wager the RSX and Xenos will be comparable in practice too. In that case, the 275m triangle limit would be a theoretical limit for the RSX, but not one that's not approached in practice anyway because of bottlenecks elsewhere.
Ok so the video memory has a bandwidth of 16M/s which is slow, very slow.
The video memory has a bandwidth of 20+ GB/sec. However, the video memory isn't connected to the Cell, it's connected to the RSX. The Cell has its own memory, called "main memory" (obviously). The 16MB/sec figure is what happens when the Cell tries to read directly from video memory, through the RSX.
But my understanding of the cell design is that it has 7 co-processors and that it's supposed to split all of it's calculations... especially graphical ones.
Cell doesn't do graphical computations, at least not in the PS3. The RSX handles graphical computations.
This parralel processing is what makes the cell teh awsome since each core is actually pretty slow.
Actually, each core is not slow so much as it is simple. For highly tuned tasks, a single Cell coprocessor (called an SPE) can be very fast. For example, IBM released benchmarks showing that a single SPE could transform vertices twice as fast as a PowerPC 970, which is itself no slouch in vector computations.
Now because the graphics system is tied with the general computing unit it's possible that both will be used concurrently (in fact it seems clear that both will be running through the cell at the same time) now where do these calculations get output to and what are they useful for after they are resolved?
There is no "graphical computing unit". There are just SPEs, which can be used for whatever you want. Any calculations they do will usually be output to main memory, which is connected directly to the Cell processor. If these results are useful for the RSX, say, Cell decompresses a texture the RSX needs to use, or generates some geometry the RSX needs to draw, then the Cell can command the RSX to download these results into video memory and process them there.
Now obviously I'm not a cpu designer but using the graphical subsytems for general calculations seems to imply that you need to be able to access the results, fast.
The graphics subsystem in the PS3 is the RSX. You could use it for general calculations, though it'd be kind of stupid given you have so many FLOPS on the Cell, and if you wanted to do that, you could have the RSX write its results directly to main memory, which the Cell can access at full speed.
Can someone explain why this is wrong? Will the cell be able to write to general memory rather than graphical memory? Will it be able to differentiate between graphical calculations and other calculations?
The Cell will normally not access graphical memory directly, except to send command buffers to the RSX. The RSX will do stuff like download textures to video memory from system memory. Cell has its own main memory that it can use for computations, that it can access at full speed.
It seems like most people's arguements about why this bandwidth thing isn't a big deal hinge on how things were done in the past, meanwhile all the talk about using the cell as a supercomputer outline why it isn't like things that came before.
I don't see how Cell used as a fast vector computer would be affected by this issue. Any Cell system designed for supercomputing won't even have a graphics processor or a dedicated graphics memory. It'll just use the Cell's local 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).
Yes, it really is that slow. See this article from a DRI developer: DRI article. Also, remember the hit for uncached accesses for an in-order CPU like Cell or Xenon is even larger. An out-of-order CPU can keep working after issuing a read, up to the depth of its load buffer. That means it may be able to transfer 32 words (depending on the size of the load buffer) very 500 cycles (or however long the memory latency is). An in-order CPU cannot do even that, and must wait the whole memory latency after every load.
Try 1.8 TFLOPS [wikipedia.org] 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.
Of course, that's why I said "general pupose" gigaflops. The GPU has a lot of its "1.8 teraflops" tied up in non-reprogrammable special-purpose hardware. Each of the 24 pixel shaders and 8 vertex shaders have a pair of 128-bit FPUs. That gives it a 128 gigaflops peak throughput. The rest of the "1.8 teraflops" is tied up in things like interpolators that compute per-pixel parameters like texture coordinates across the triangle. These units are not full FPUs (thus they aren't really a general purpose FLOP), and in any case cannot be retasked to do things like running physics code. That's why things like GPGPU get only 60 usable gigaflops from a top of the line ATI graphics card that's rated at 1+ teraflops.
The entertaining thing is that this particular problem is something quite natural to PCs. Framebuffer accesses on PCs have been slow ever since graphics cards started sporting dedicated coprocessors. You take a brand spanking new PC, and start downloading stuff from the framebuffer, your transfer rate will be abysmal.
The problem here isn't just a lack of embedded hardware knowledge. It's just a lack of knowledge.
1) PCIe versus AGP is irrelevent. The PS3 has an extremely fast (25+ GB/sec) bus between the CPU and GPU. The lack of bandwidth isn't what's causing the slowdown. Rather, it's the lack of cache coherency. You see, in a NUMA system (where each processor has its own local memory), the caches of the CPUs must be synchronized in some way, so that CPUs see a consistent view of whats in the two memories. The synchronization is done through what's called a cache coherency mechanism. In the absence of a cache coherency mechanism, whenever one CPU wants to access the memory of another CPU, it must do so via an uncached access. This isn't so bad for writes, because the processor can just fire off the write into a buffer, and keep computing. For reads, this is a killer, because the processor is stuck waiting hundreds of cycles for the read to complete before issuing the next one. Neither AGP nor PCIe have a built-in coherency protocol. 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. The address range containing the AGP memory must be mapped as uncacheable by the processor.
2) There is no indication that PS3 cannot handle doing physics on the GPU. On the PS3, the GPU can write to system memory. The main CPU doesn't need to read the results of the physics calculations from the GPU --- it can just instruct the GPU to write the results to system memory and read them from there.
3) Don't try to apply PC-gamer thinking to console architectures. Use your head, and think things through. First, why would anybody want to run physics on the GPU? Well, physics calculations are very vector and bandwidth intensive, and the GPU has a lot of vector processing power and bandwidth. Second, when does it make sense to run physics on the GPU? Well, when the GPU has more vector gigaflops than the CPU. On a PC, the CPU can do less than 10 gigaflops, while the GPU can do over (general-purpose, according to gpgpu.org) 60 gigaflops. The CPU has maybe 6GB/sec of memory bandwidth, while the GPU has close to 40 GB/sec. So running physics on the GPU makes sense, in a PC. Now, try to apply this thinking to the PS3 and XBox 360. Do their GPUs have more general-purpose gigaflops than their CPUs? Well, Xenon can do about 80 gigaflops, while Cell can do about 150 gigaflops, so no. Do their GPUs have more memory bandwidth than their CPUs? Well, Xenos shares a 25 GB/sec bus with Xenon, while RSX has its own 22 GB/sec bus seperate from Cell's 25 GB/sec bus. So no on that count too. So now come to the conclusion: does it make sense to do physics processing on the GPU in either the PS3 or the 360?
4) If you're impressed by the potential of physics processing in games, then you should be psyched about the PS3. The whole point of Cell is to have a lot of vector gigaflops that can be programmed more easily than the vector gigaflops available on the GPU. In fact, a PhysX chip is organized very similarly to a Cell chip. It's consists of a bunch of vector coprocessors, each with a local memory, and a central control processor to feed data to the coprocessors. Moreover, if you're going to be doing general-purpose computations on the GPU, you can throw the whole "360 is easier to program" argument out of the water. While the Cell might be more complicated to program than a symmetric multicore processor Xenon, writing code for the SPE is a lot easier than writing code for a GPU's shaders. At least an SPE somewhat resembles a regular CPU, albiet with a weird memory model. A shader in a GPU is an entirely different beast, with an even weirder memory model (though one that is naturally suited to graphics code).
One word of advice. Some of the issues relating to consoles are very technical. Don't spout off about things if you don't really understand the technical details underlying them. We really don't need more FUD on Slashdot.
People use the GPU to do physics on PCs, because PCs don't have 7 vector coprocessors to do physics on. There is no reason to do physics on the GPU in either the XBox 360 or the PS3, because they've got lots of vector processing power on the main CPU.
It's there for a reason.
My flame:
"I'm sure you'll get a lot of these messages, but hell, you deserve it.
The slow read speed you noted in the slide is for Cell reading from the RSX's local memory. Such accesses are expected to be very slow. If you look at this USENIX article from one of the Linux DRI folks, you can see this quite easily:
DRI article
He shows how painfully slow it is to read from AGP or framebuffer memory (14 and 5 MB/sec, respectively), on a Rage 128 graphics card. For the CPU to framebuffer read, which is the equivalent to what we're talking about here, the read speed is 1/40th the write speed. At 16MB/sec read and 4GB/sec write, the PS3 is actually right in line with what can be expected of modern GPU architectures.
Reading from the framebuffer is just slow unless you have a unified memory architecture. The CPU and the GPU aren't cache-coherent, which means every access to framebuffer memory (or even AGP memory, which is actually a chunk of system memory allocated to the GPU) must be an uncached access. Uncached accesses are just plain slow, on any architecture.
The way your article is written, it makes it seem like Cell reads its local storage at 16 MB/sec. That is, of course, bollocks, since IBM has shown benchmarks of the Cell local storage achieving 98% efficiency. If you had any journalistic integrity at all, you'd post a retraction on your site, and a clarification of the technical issues involved."
Becuase he's right. If you read the slide carefully, you'd realize this. THere are two CPUs in question here (the Cell and the RSX), and two banks of memory (main, and local). Main memory is obviously the memory associated with the CPU. Local memory, thus, must be the memory associated with the RSX. The matrix shows that the read speed of memory associated with the RSX, when accessed from the Cell, is really slow.
That's not really news. It is a highly assymetric memory, effectively "write only" as you put it (from the perspective of the Cell), but that makes it like another very useful type of memory: a FIFO buffer. From the prospective of the source end of the FIFO, it is effectively a write-only memory. However, FIFOs are very useful in producer-consumer architectures, where you have one end that produces the data, and another end that consumes it.
Which is exactly what we have here. The Cell CPU can produce data and write it into the local memory, and the RSX can use that data to texture the scene. The Cell CPU can produce command buffers and write them into local memory, and the RSX can consume those command packets to figure out what to draw. The fact that the Cell CPU can't read them back very fast is irrelevent, there is really no need to.
Which is, of course, why almost all non-UMA graphics architectures work this way. Reading from the local memory of a PC graphics card is also an extremely slow process. We're talking tens of megabytes per second over a 4GB AGP bus. That really doesn't hurt anything --- because you almost never need to read from GPU memory.
Thank you for that!
This article takes the statement completely out of context, and the Slashdot reaction to it is just ridiculous.
Anybody who didn't know reads from GPU memory are slow turn in your geek card right now! On a PC, even with a 4GB/sec AGP connection, reading from the framebuffer can be as slow as 75MB/sec. This has been true for a very long time --- GPU's don't like anybody else directly touching their framebuffer. That's why Microsoft took direct framebuffer access out of "DirectX". It's a performance killer on modern systems. Sony's "work around" for the situation, using the GPU to handle texture uploads/downloads, isn't news --- it's common knowledge to anybody who has done any graphics programming on modern hardware.
That really wasn't my point. What I'm trying to get at is that people refer to the $300 360 as crippled, because its missing a fundemental component: the HDD. The $500 PS3 isn't missing any fundemental components, as a gaming system. It is thus unfair to call it "crippled". The $600 PS3 is a justifiable "extras" package. It contains stuff that you'd want if you cared about the PS3 as a media center and HD video player. If you don't care about these things, and the people complaining about the PS3's price say they don't --- they just want a gaming machine, then its dishonest to pretend that the $500 PS3 doesn't exist, because it is "crippled" along some dimension you don't care about anyway.
2) I'm not paying $1600 for a TV. I won't pay that for a computer. Wake me up when they are $300 or less.
Lot's of people pay $1600+ for a TV. Are you living in the same United States I am? I honestly cannot remember the last house I visited that did not have a big-screen TV in it. It's not really a luxury item anymore. $1600 just isn't that much for something someone spends a significant amount of time watching, and will use for four or five years at least.
4) how much of a footprint does a PC game take? Anything that is not on the HD will need to be loaded every time. A 2x BD-ROM reads slower MB per MB than a 12x DVD-ROM. If they really need the 25-GB you will have a hard time putting a significant amount of multiple games on the HD.
Obviously, you don't understand the concept of caching. I mentioned CPU caches for a reason: how does a 1-4MB CPU cache perform effectively when your main memory is 1000x bigger? The answer is because you only need to work with a subset of that data at any given time. That's why a 20GB hard drive can effectively cache lots of BD games. It just needs to store enough data to prevent obvious delays. For example, the core game engine could be stored on the HD, so the game UI pops up immediately without any load time. In an FPS, the system could be loading data for the next area onto HDD while you're playing the current level. In a multiplayer game, a map could be cached on the HDD after the first time its loaded. So once the game got going, the load-times would be very short. And of course, there is no reason to cache things like videos or music tracks, which take up a lot of space but can be streamed in from disc during the game.
Could expand for you... but will not expand for the layman. Will likely come at a steep cost. Wii again has an embedded browser. Truthfully, they will make Linux for all platforms, but honestly no system will have a OS that is so easy, cheap, and useful that John Q Public will bother.
What do you mean "could expand for you"? Sony is a consumer products company. They're not going to hand John Q Public a Linux command line! Linux will be used as a platform on which task-specific software can be built. So for example, if Sony adds DVR capabilities, Linux would be used as the OS, but the UI would be some Tivo-like DRV software. And what makes you assume that extras will come at a steep cost? The PS2 hard drive upgrade is $100 bundled with a game. Was that expensive? The PS2 didn't even have expensive add-ons like keyboards, although Sony could have done that. It just used regular USB keyboards.
When I say "tweeked", I mean slightly modified. All the chips in in this generation are not "tweeked" versions of the PPC601 --- they look more like a PPC601 internally than they do a Pentium 3. On the other hand, it is fair to say, for example, that the Power5 is a "tweeked" Power4, or that a Pentium-3 is a "tweeked" Pentium 2. I should also point out that the Pentium 3 (Katmai) and the Pentium 2 (Klamath), had different codenames.
The most precise reports I've seen thus far indicate that Hollywood and Broadway are "tweeked" versions of Gecko and Flipper, in the "Pentium 2 to Pentium 3" sense of the word. Such reports are consistent with reports of a 2x performance improvement. A 90nm die-shrink, with a little bit of circuit tweeking for the new process, could result in single-chip solution 1/2 the size of just Flipper or Gecko by itself. The resulting chip could also likely run at twice the clockspeed without pushing the thermal envelope. That's be consistent with all the reports, and would be extremely cheap for Nintendo to make.
Of course, those reports could be wrong. Broadway and Hollywood could indeed be genuinely new chips. In that case, I have a very hard time believing the performance improvement is only 2x. The Gamecube's CPU was about 50 mm^2, and its GPU was about 100 mm^2. It had a 162 MHz 128-bit bus to its 1T-SRAM. For reference, the PS3 CPU is 230mm^2, its GPU is close to 200mm^2, and it has 2 128-bit busses, one to VRAM and one to main RAM. If the Wii followed the same development process as the GC, to hit the same size targets, and thus similar costs, Nintendo would get a *lot* more than a 2x improvement in performance. Within the 50mm^2 envelope, you could fit a pair of Gecko cores running at 1+ GHz, with a substantial boost in cache to top it off. Within the 100mm^2 envelope, you could fit one of ATI's RV515 chips, with 4 pixel shaders, 4 vertex shaders, a full palette of 3D effects, running at 500 Mhz. To top it off, you could clock the 1T-SRAM at 700 MHz for over 11GB/sec of memory bandwidth. These are all conservative assumptions, working from tech that is already very cheap today.
The resulting system would be a lot more than 2x more powerful than the GC. It'd be closer to 4-5x more powerful, and could make use of modern features like pixel shaders while maintaining performance. The fact that Nintendo isn't citing bigger numbers points very strongly to the Wii being a "tweeked" Gamecube, not a substantially reworked design.
As for the PS3, hardware does have intrinsic value, in the sense that it has an intrinsic cost. That value may not be worthwhile to a particular consumer, but there is little arguing that the intrinsic cost of the components in the PS3 are not at all out of line with its selling price. It's not like Sony is taking $50 of components and trying to sell them for $500.
The launch prices of the PS1 and PS2 were both 50% more than the launch prices of the N64 and Gamecube. That didn't stop Sony from selling metric assloads of them.
If the initial specs of the Wii are accurate (die-shrunk GC chips), then, yes. Nintendo sells the current GC hardware for $99 at a profit. If the Wii is indeed a tweeked Gamecube like everyone is reporting, then at $200 Nintendo is going to make a nice amount of money on the machine. Their development cost for the console was minimal, and on a modern 90nm or 65nm process, the whole Gamecube chipset can be put on a single chip with a very small die size. Unless the gyros in the controller are super expensive, their manufacturing cost is going to be tiny.
The PS3 is a serious amount of hardware. It's got a big CPU and a big GPU, each connected to some expensive RAM and with some fat busses inbetween. You might argue that this hardware is not necessary, but you can't argue that its cheap. Sony is not overcharging for the PS3, by any reasonable conception.
Resorting to lying are we?
1) No ICT on BluRay means HD without HDMI.
2) What do you mean "gaddamn expensive"? Good 1080p TVs are down to $1600. That's not cheap, but in the USA anyway, not really that expensive either.
3) Games don't use ICT! Even if movies do start using ICT, locking out 1080p, games won't.
4) Yes, and a 4MB L2 cache couldn't possibly do a good job caching 2GB of system memory.
5) Linux support means the potential of expanding the PS3's capabilities. Consider a PS3 home media server, or web browsing and e-mail, etc. Consider DVR add-ons, or consolidation of a bunch of other gadgets people spend $200-$400 on seperately.
6) The gameboy had tilt sensitivity, really?
7) Good point about the DS connectivity.
The lack of a hard drive in the XBox 360 cripples it, because eliminates a fundemental feature that can be used in games. There are no fundemental gaming elements missing from the low-end PS3. The PS3 will do 1080p over component (like some DVD players already do). Hell, it even has perks like wireless controllers. The only thing the high-end XBox has that the low-end PS3 is missing is a remote, which you don't need if you consider the PS3's media capabilities useless. The two PS3 models are entirely sensical. The $500 PS3 has all the gaming elements, and the $600 PS3 adds all the media extras.
The bottom line is this. If you're in it just for the gaming, its just plain dishonest to claim you need the $600 PS3. That model adds no gaming elements to the console. If you're in it for the video, then $600 is a hell of a deal for a combo gaming machine/Blu Ray player.
It has nothing to do with being a graphics whore. I've been playing video games since the 1980s. I've played all these "simple but fun" games all these Wii fanboys keep talking about. And you know what? They were a ton of fun back in the day, but this is 2006, and I'd rather play a game that looks like it was made in 2006.
People are intensely visual creatures. The visual aspects of products are important, and change with time. Products with out-of-date visual styles are perceived negatively, even if they would not have been at their original time. Arguing that its "whorish" to hold a game's outdated graphics against it is like saying its "whorish" to hold a suit's 1970's style against it. Hell, that polyester number covered you up just great in 1970, are these fancy new suits really that much better?
As for 480p being enough, that's bullshit. Play a first person shooter at 640x480 on a 24" LCD, then play it at 1920x1200. Tell me which one is more playable, in terms of actually being able to see the shit you're shooting at. 480p looks just fine on a small TV, but big-screen TVs aren't exactly a luxury item to most people who have enough money to waste on video games, and 480p on a big screen is insufficient. I've been playing through Wind Waker this week, on a 70 inch TV, and while its great, it'd be a whole lot better if it didn't look like I needed my contacts adjusted.
1) Less than a quarter of US households have PS2s. According to Sony's research, 34% of PS2 owners have HDTVs. That makes HDTV ownership among PS2 owners twice as high as HDTV ownership among the general population. If that trend holds, at current rates of growth, the majority of prospective PS3 owners will have HDTVs in the next few years. If you can expect half of your prospective users to have HDTVs over the lifetime of the console, it makes perfect sense to offer something that lets them take advantage of it.
2) What's with the invectives? Did I call you names? Just because you don't feel a need for better technology, you shouldn't ridicule people who do. For a technology site, there are an incredible number of luddites here...
3) Your argument about the free market would be valid if:
a) If the airwaves weren't a limited public resource. It is entirely consistent, under modern economic theory, for the government to control such resources within a free market system.
b) If the current massive growth in HDTV adoption rates was the result of an impending transition deadline, but the deadline is still many years away.
As much as I'm sure you'd like to believe the current HDTV adoption is the result of "high tech dweebs" (coming from someone browsing Slashdot? Please!) and "rich idiots", you can't rationalize that position. People aren't buying HDTVs now because they're worried about some government transition in 2009 (at which point they'd have to buy a cheap digital conversion box, not a whole new TV), but because HDTVs have dropped dramatically in price, and lots of people have been switching to LCD and plasma displays (which are mostly HD), for asthetic and space reasons. They also buy it because its dead obvious to anybody with eyes how much better an NFL broadcast looks in HD versus SD resolution.