I didn't realise Andy was really that selective in who he tells he hates!
Oh, did you get the letter too?
Sir Eric Demers on AMD R600
- Thread starter B3D News
- Start date
- Status
Oh, did you get the letter too?
Too bad no real questions asked about rv630
Yes. It's very nice.
Yeah but have we actually seen R580 go head to head against R520 with everything constant but the shader count? R580 has become synonymous with the X1950XTX and it has a significant bandwidth advantage over R520 based parts. The only place I could find a direct comparison was on Tom's VGA Charts and R580's 3x shader power doesn't seem to be doing much at all when comparing the X1900XTX to the X1800XT. I would really like to see a head-to-head of these two parts in today's games but as expected they aren't included in benchmark suites any more.
Geo said:
Yeah he seemed to confirm as much. It's his use of sub-optimal that threw me off really. Even if it was a forward looking comment, current performance doesn't really instill confidence in how the architecture will handle upcoming games. But that's all muddled by the current state of drivers anyway /shrug
Completely understand, thanks for the clarification. Can you comment further on how R600 will benefit from upcoming workloads? Is it a case of just longer shaders or will future code be easier to schedule given R600's VLIW configuration? I know you probably can't comment on this outright but are the driver issues in any way related to getting good efficiency out of the current ALU setup in existing titles?
This actually hasn't been clear to me, even with R580 (see my post above). It's one thing to have the right ratio but it's another thing to have sufficient absolute performance in each area that matters. For example, if we blame a low ALU:TEX ratio for the XT's inability to consistently beat the GTS that has a significant shader and bandwidth deficit, how are we to expect useful performance advantages in future games where the ratio might be higher but the absolute texture workload will also increase?
I'd imagine that at some point, a game could become ALU limited before it is TEX limited. That being the case, XT would then (all else being roughly equal) surpass performance of the GTS. Whether or not we'll see it in the games this year, who knows? *Shrugs*
Well, the nice thing about needing to get even with Rys re photos, is he insists on making it so easy.
"Hector, I need a small piece of the front page for a few days. . . for. . err. . .an exciting gaming thing."
Well I would hope so given that the XT has a massive absolute shader performance advantage over the GTS and not much of a texturing deficit
I'm trying to think of this in terms of the ratios that keep getting bandied about. We hear that applications are approaching 12:1 ALU:TEX ratios yet we have a texturing monster ruling the roost. The promises just aren't coming true.Longer shaders, with more GPRs, as well as more complex ALU workloads -- These are inline with our expectations. The scalar/VLIW architecture is fine and better than previous archs, but is not an advantage compared to our newest competition.
You answered your own question -- If the ratio improves, an architecture inline with this will give a better performance than other -- Regardless of the total load.
Well technically, I said useful performance As in, if we ever get to a point where the XT is faster than the GTX due to an ALU advantage would the performance level be playable? I'm not sure how to go about evaluating whether being forward looking in this industry makes sense. I really wish we had some updated X1900XT numbers as that would shed some light on how practical it is to try to predict the future.
As in, if we ever get to a point where the XT is faster than the GTX due to an ALU advantage would the performance level be playable? I'm not sure how to go about evaluating whether being forward looking in this industry makes sense. I really wish we had some updated X1900XT numbers as that would shed some light on how practical it is to try to predict the future.I think you'd need to ask the software partners for this one...As always, I'm sure the design choices made were choices made with what software developers have told ATI/AMD that they need, for one reason or another. Once the design is done, it's up to the developers to follow through with those needs, and like R520/R580, this has not become apparant until a while after the product is released.
OpenGL guy
Veteran
As I stated a while ago, F.E.A.R. performance on R520 was split roughly evenly between shadow rendering and everything else. Given that, increasing the shader power by 3x gave a larger boost than, say, doubling Z power would have given. The main shaders in F.E.A.R. are ALU-heavy (I think I even posted one of the shaders more than a year ago). So, in F.E.A.R., half your workload goes ~3x as fast.Well technically, I said useful performance
Looking at some of our benchmarks, with R580 clocked at 625e/730m and R520 at 650e/775m, F.E.A.R. at 16x12 was 78 for R580 vs. 56 for R520. How's that?
There are few things I want to talk about ATI is
ATI you did a great job but Nvidia already designed the G80 before the Design of the G70.What I am interested in is -when we can see the Real-Advance architecture can maintain and refresh within least 2 years? It is not about the performance but all sort of the things combined altogether. From the R5xx Family, It is understandable that ATI barely cover all R&D cost on return fully compared to G7X and G8x family.
It is not too late to change and transform the company into the new pathway or without.
The main shaders in F.E.A.R. are ALU-heavy (I think I even posted one of the shaders more than a year ago). So, in F.E.A.R., half your workload goes ~3x as fast.
Looking at some of our benchmarks, with R580 clocked at 625e/730m and R520 at 650e/775m, F.E.A.R. at 16x12 was 78 for R580 vs. 56 for R520. How's that?
Not bad, not bad :smile: What does shadowing stress the most anyway?
That's the only picture of you we had, blame it on the lack of paparazzi around ATI's HQ!
And I tried to make the photo look a bit better than the original, so at least there's that!
Then, there's the hidden picture in page one...
Great interview by the way, to conclude on a more serious note.
Did nvidia suprise your team from this standpoint? were you expecting them going completely scalar?
OpenGL guy
Veteran
The shadows are stencil shadows, so they are largely limited by Z/stencil performance. If you enable soft shadows, then the balance shifts some as there is still a lot of Z/stencil going on, but there are some extra passes to compute shadow edges so they can be filtered.
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?
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?
DX10 is mentioned all over the place, but is there any consideration for OpenGL futures when designing a base architecture these days?
How exactly does the fast path work for passing back MSAA sample data to the shader core?
Have you had time to poke the windowed sinc yet?!
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?
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?
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!
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?
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?
DX10 is mentioned all over the place, but is there any consideration for OpenGL futures when designing a base architecture these days?
How exactly does the fast path work for passing back MSAA sample data to the shader core?
Have you had time to poke the windowed sinc yet?!
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?
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?
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!
- Status
