Chalnoth said:
*sigh* So much crap spewed in that interview, I almost don't know where to begin.
So you decided to begin by spewing some of your own?
When we think we can produce a product with adequate performance that allows you to actually take advantage of some of these new features, then that's when we'll add the features into that product. But if you try to introduce them too early, you're basically adding additional cost to the product that's not providing a benefit to the end user, and that's just something you want to avoid.
With an attitude like this, we'd have much slower advancement of gaming technology. It's not until low-end hardware is saturated with a certain set of features that those features can be used to their fullest.
So you're saying that, for example, the GeForce FX 5200 is driving the adoption of SM2.0 in software even though it can't run most SM2.0 shaders are usable frame rates? I'd be more inclined to say it's had the opposite effect.
One thing to consider when you're looking at these things is, you know, it might not sound like a huge difference between 24 bits or 32 bits, but what you're basically talking about is 33% more hardware that's required. You need 33% more transistors. Your data paths have to be 33% wider. Your registers have to be 33% wider.
This is all blatantly false. FP32 math units aren't 33% bigger than FP24 math units, and the parts that you would change wouldn't take up all of the core.
Well, the area required for many functions (like multipliers, registers, and caches) tends to increase linearly with number of bits. And area required for routing certainly increases as the datapath width increases (although I don't know what the typical relationship is). So I don't understand why you find this so hard to believe. It doesn't matter how much of the chip is taken up by the shader units - he's just saying that part of the chip would have been 33% larger, and that space could have been used for additional shader units.
So if you were instead to devote those extra transistors to increasing performance, now you're able to run those 150-instruction shader programs at a much higher speed, so that a lot of techniques that were previously not feasible to run in real time now become feasible.
There's absolutely nothing that the X800 can do that the GeForce 6800 cannot do. The difference in performance is quite small, and there's simply no algorithm in the world that you could run on the X800 that would be that much faster. So, based on this logic, nVidia definitely took the better route, as they added both performance and features, allowing for more developer freedom.
You've got no evidence to back up this statement. The benchmarks we've seen so far indicate that the X800 outperforms the 6800 in a majority of the applications tested, particularly shader-heavy ones, and often by much greater margins than could be explained simply by the clock speed differences.
[about branching]So performance will potentially be somewhat lower, because now you have to add in the extra pass, but certainly there's that you couldn't do—that you could do only with hardware that supported it.
That's the understatement of the century. With the wrong kind of loop, performance could be absolutely abysmal without actual dynamic branching support.
And it could also be absolutely abysmal even WITH hardware dynamic branching support. So what's your point?
TR: Won't Shader Model 3 provide an easier-to-use programming model?
Nalasco: Well, not necessarily.
Yeah, right!!!
Come on! SM3 adds flexibility. This makes programming easier. Without that flexibility, you have to use hacks and workarounds. That's never easier than straight programming. This is just a silly argument, as he's basically arguing that since you can do more advanced things with SM3, it's going to be harder to develop for.
No, the point is that when you want to do the exact same thing on SM2 and SM3, it's either going to be identical or easier with SM3.
No, you ignored the rest of his statement. He was saying that it's much more difficult to make efficient hardware and compilers for SM3 and SM2, so your supposedly simpler SM3 code may end up running inexplicably slow, and it will be difficult to debug, or you may end up using hacks and workarounds. SM2 avoids the difficult areas and delivers more predictable performance. The PS2.0a support Nvidia has in the FX series is a perfect example of how more flexibility doesn't necessarily translate into easier programming.
Nobody in their right mind is going to apply a blur filter to a game.
There's a great quote. Apparently you haven't played many DX9 games lately. Blur filters are one of the most commonly used post-process effects!
IMO, the "total number of transistors" in a chip *may* tell us something about likely yields (may)--but that's about it...
