There's so much extra we could have asked and question avenues we could have gone down, but hopefully we got some goodies in there to make it worth a read. Thanks to Eric for answering over 30 Qs :smile:
I'd love to know so much more based on what was said, here's a sample off the top of my head:
~750MHz being partly a yield choice, as well as a performance one, but why exactly when it seems 800MHz would have been just as comfortable from a heat and power perspective, and you seem to be yielding excellently by virtue of only having one SKU?
I did not pick 750 -- It was an iteration process, based on the "corner" process lots to get the best yield. The difference between 750 and 800 is not enough to really make a difference. 800 was probably just a little too much for some corners. Hitting a good price was very important.
Was there ever a set of simulations run comparing R600 + R580 RBEs vs the final design, and if so what were the interesting datapoints that came out?
Yes, there were hundreds. Yes, a few things came out in the final design, but, in general, it was as expected. -- Resolve was moved into the shader, so that can't really get compared.
DX10 is mentioned all over the place, but is there any consideration for OpenGL futures when designing a base architecture these days?
There are some OGL considerations -- Certainly some of the workstation requirements are taken into considerations, though those don't tend to push the technical enveloppe. We also make sure that current generation apps are working well on new architectures. But when it comes to defining next gen features, it's been coming generally from the DX or even GPGPU side. There's more today from OpenGL-ES than OpenGL traditional. Having said that, there's certainly energy afoot to make all new features (and more) available to OGL asap.
How exactly does the fast path work for passing back MSAA sample data to the shader core?
Secret.
Have you had time to poke the windowed sinc yet?!
Not my team directly, so I'd have to check. We know of your request mister!
If the tesselator is so cheap in terms of area, why not build it into a GPU before Xenos, or was there a coming together of DirectX future discussions that made it inapplicable to R5xx because the tesselator's future in DirectX hadn't been decided yet?
Dunno, really. I was't involved in the Xenos decisions, so I don't know/remember exactly. There certainly was't a great pull for it during the R5xx timeframe -- DX9 or DX10 weren't planning on supporting it.
What proportion of R600 is memory cells versus programmable logic vs glue logic vs IO vs clocking vs power? Or easier to answer, which one dominates, and which dominated R580?
Not exactly sure what all your terms mean -- Standard logic I believe dominates the chip as a whole, but it's followed closely by memory; the two not being that far apart. Not sure on the other ones, but I would assume pretty low.
And as far as RV6xx goes, folks, we held off on too many derivative questions until we've had a closer looks at the first boards. If Eric's keen, we'll poke him again in July, with less Furby!
Sure. I'll be off for part of July (Europe mostly), but I'll be around. I'm not taking as much time in the above answers. because I'm doing it fast, and it's friday afternoon...