Sir Eric Demers on AMD R600

[tabs]

Of course not. Only actually playing games can give you the full picture.

heh, I wondered if someone was going to say that. :smile:

What I meant was, objectively can this improvement be measured? just as we can with the lovely colour patterns we are treated to with each new arch. I'm sure all the reviewers (apart from here at B3D ) played some games with the cards and I don't remember one of them saying that the AF IQ was improved.

 

[juicytuna]

And yet one of his answers talks about the derivatives being "very popular". If there haven't been any sales, how could that be true? I do wonder if they did launch together, just not in both channels (OEM and retail) simultaneously in order to preference supplies for one over the other in the fat part (volume-wise) of the market. The "sucks to be you" part of such deals is you don't announce for the customer, so you can't beat your chest until he's ready for you to do so.

The statements about a family launch were clearly aimed at the graphics consumer and not at the OEM's, and AFAIK, none of the lower end derivatives will be available to buy until the beginning of July - at least 6 weeks after the launch of the x2900xt.

Whether it be through miscommunication or just plain deceit, a clear message was given to the graphics card buying public that the full family of r6xx based cards will be available to buy from launch. Talking about separate OEM and retail launches is just a cop out IMO.

 

[Geeforcer]

And yet one of his answers talks about the derivatives being "very popular". If there haven't been any sales, how could that be true? I do wonder if they did launch together, just not in both channels (OEM and retail) simultaneously in order to preference supplies for one over the other in the fat part (volume-wise) of the market. The "sucks to be you" part of such deals is you don't announce for the customer, so you can't beat your chest until he's ready for you to do so.

Geo, you can't possibly content that what took place was a "family, all together, not-a-soft" launch. I mean, we try to pound square pegs into round holes all day long and pretend that them not fitting is due to the lack of of some deep insight into the nturee of the pegs, holes and universe itself. BTW, selling something and shipping can something be two very different things. You don't honestly believe that RV6xx's have been shpping in volume for the past month, do you?

 

[Robbitop]

The AF hit can be more significant on R600 at this time. It should show higher quality in exchange (not on the LOD isotropy front, but on the mipmap transition front). I believe some of that will be addressed, in part, in future drivers. I can't promise a % improvement at this time.

Did you or other chaps at ATI try to play WoW or HL2 on R600?
Here is a HL2 Savegame: http://www.keepmyfile.com/download/56cf9c1598001

F.e look at the ground while you walking along the rails. You will notice pretty hefty shimering artifacts. In WoW it is the same. On any texture with high frequency content, the filter seems to shimmer. I guess the filter kernel doesn't meet the nyquist criteria.

At R580 it's quite the same. But if you deactivate A.I. it's all fine. No shimering. But on R600 the shimering stays whether AI is on or off.

Will there be future improvements in the driver?

 

[hoom]

I was hoping for a bit more detail on what the R400 was going to be.
Like pipeline/tex/rop config & target clocks.
Surely not commercially sensitive now.

Also, could we get a promise that the next ATI/AMD high end will have the fan blades facing the right way?
Current R600 fan blades have similar orientation to the noisy r300 competitor...

ATI used to have such nice fans

 

[Pantagruel's Friend]

Wow, what an impressive Q&A

I've got a question that's been nagging me ever since I saw the first R600 architecture diagram:
What is the design philosophy behind extra hierarchy level in the SPU clusters, binding those 4+1 SPUs together? I understand the intent towards vec4 (or larger) operands and future shader codes with the (V)LIW approach, but for the time being (with predominant vec2 pixel shader codes), wouldn't it have been more efficient to serialize them? As I understand, the R600 has excellent capabilities to minimize (or even completely negate) cycle losses from such a serialization.

 

[Geo]

Geo, you can't possibly content that what took place was a "family, all together, not-a-soft" launch. I mean, we try to pound square pegs into round holes all day long and pretend that them not fitting is due to the lack of of some deep insight into the nturee of the pegs, holes and universe itself. BTW, selling something and shipping can something be two very different things. You don't honestly believe that RV6xx's have been shpping in volume for the past month, do you?

I think it certainly wasn't a family, all together, not-a-soft launch for the retail channel. Isn't that what I said? As it says in the PR linked on our front page, they've been shipping to "board customers" (and yes, that's a direct quote) since June 11th, apparently. Do I think they've been shipping BBA to OEMs for longer than that? Yes, I do. Could I be wrong? Yep. Was I hoping Eric might confirm? Yep. Did you step on my sideways efforts at getting confirmation in your rush to make righteous points about pegs and holes? Yep, but that's okay. :smile: Should I stop doing a Donald Rumsfeld impersonation? Also probably a good idea.

 

[trinibwoy]

Did you step on my sideways efforts at getting confirmation in your rush to make righteous points about pegs and holes? Yep, but that's okay.

 

[zealotonous]

Great Q/A. Coming from the tech world, I know how hard it is to be forth coming to the consumer without giving the competition too much info. I was pleasantly surprised that he was as open as he was.

As far as the delay issues, I think the reason we are seeing a difference in his response to that of the executive and marketing statements during the announcement of the delay is that Eric is in engineering, through my own personal experience, won't waste time looking for corporate-correct statements. I think it's clear that the delay was due to driver issues like G80, they are still ongoing with much work to be done.

I wonder if Eric could give us a little bit of information on the history behind R600's development cycle. Do they have a group within ATI strictly working on future technologies? At what point on the roadmap does a product get internally created and issued a code (like R600)? Once the product code for R600 was created, were the requirements already done for it or are they developed prior to the issuing of the code? Which team at ATI creates the requirements and how soon in the development process are they created? 1 year? 2 years? 3 years?!?

Great stuff Eric and B3d.

 

[PD]

Well, the nice thing about needing to get even with Rys re photos, is he insists on making it so easy.

lolz

 

[sireric]

I wonder if Eric could give us a little bit of information on the history behind R600's development cycle. Do they have a group within ATI strictly working on future technologies?

We sort of did at the time we started R600, but we clearly have a group for that now.

At what point on the roadmap does a product get internally created and issued a code (like R600)?

Actually, it gets given a project name, very early in the process. Codes like R600 usually show up a little later, but are infered until then.

Once the product code for R600 was created, were the requirements already done for it or are they developed prior to the issuing of the code?

I'm not sure, really. But the process evolves over time, and started a long time ago. We focused on DX10, which set clear schedules and basic expectations. A lot of architecture / problem solving was done first, before transitioning to design/coding.

Which team at ATI creates the requirements and how soon in the development process are they created? 1 year? 2 years? 3 years?!?

Great stuff Eric and B3d.

A new architecture like R6xx took over 3 years of design work. 36 months for a new design is probably a minimum, at this time, considering the shear number of transistors (and associated design) involved. Follow on products, typically follow within 6 months or so, and don't need a huge amount of redesign. In the last year of design, very little change occurs -- Configs, features, etc... are all locked down. Only clock can change a little afterwards.

BTW, I'm only going to focus on engineering type questions ;-)

Thanks!

 

[AlNom]

BTW, I'm only going to focus on engineering type questions ;-)

Hi Eric, thanks for taking the time to answer all these questions.

I was wondering, when your team is designing the chip for a particular process node, what sort of challenges are there for moving to a smaller node? What sorts of things need to be considered? Is there a difference in those considerations when moving from say, 90->80nm or 90->65nm?

With the different clock speeds around the R600 chip, does that mean you are using different voltages around the chip? And with respect to scalability, will there be any changes required beyond disabling pipes/ALUs etc for the mobile editions? (all wrt power consumption)

 

[nelg]

Eric,

What was the first game tested on the R600?

Now that it is complete what interaction do you have with the driver team? In particular, do you let them know how close / far away from theoretical performance they are?

 

[Bludd]

In a HyperTransport enabled system, would the HD2900 benefit from being directly connected to HyperTransport (via HTX for instance)?

 

[WaltC]

Sir Eric,

First of all, thanks for the info. Seeing you writing again like this reminds me of other days, long past... Your input, as always, is both interesting and much appreciated.

I wanted to ask you whether, from an engineering standpoint relative to the R600 project, the merger with AMD presented situations that might have in some ways impacted the roll out of R600. I'm speaking only of any practical things that you may have seen arise as a result of the merger process that affected your particular job in that regard. This isn't really a loaded question as I have no idea what you might say, if anything. If the merger didn't phase you in that respect I'd like to know it out of simple curiosity.

Also, talking about new architectures and the necessity of progressive driver refinement, I am reminded of the early months after R300 shipped. In particular, you may remember all of the Internet speculation and opinion circulated at the time NWN shipped, when it was often stated in the beginning that the reason NWN's "shiny water" wasn't shiny on R300 was because of innate hardware limitations inside R300 that precluded the chip from being able to handle such effects in general. I believe that in the beginning even Bioware itself stated such an opinion. Of course, as time and drivers and Bioware's education of R300 progressed, the shiny water effect soon displayed perfectly on R300 in the game and that particular bugaboo was put to bed for good. Just a comment to indicate that if things with R600 improve with further driver refinement over the next few months, much as they did following the shipping of R300, that I would not be surprised.

Great to hear from you again!

 

[Apocros]

re fast14

A key issue with this scheme is the potentially dramatic change in the thermal profile of the die. Bear in mind when this deal was announced... No one was going to sign up to convert the bulk of their design to dynamic logic, so only key blocks were candidates (personally, I think the choice is obvious). Block <foo> (pick your poison), implemented as dynamic-logic running at 2GHz (compared to static-logic cmos at 500MHz) in your favorite 90nm process is going to be a non-trivial heat source (or power-hog, depending on how you look at it). The area savings have to be pretty significant to offset the higher BOM costs from this solution (better heatsink, beefier regulator, etc). If you've already got a fixed power budget, or a relatively hot-running design, the idea might be a non-starter.

In short, I wouldn't hold my breath waiting for this one...

 

[sireric]

Hi Eric, thanks for taking the time to answer all these questions.

I was wondering, when your team is designing the chip for a particular process node, what sort of challenges are there for moving to a smaller node? What sorts of things need to be considered? Is there a difference in those considerations when moving from say, 90->80nm or 90->65nm?

With the different clock speeds around the R600 chip, does that mean you are using different voltages around the chip? And with respect to scalability, will there be any changes required beyond disabling pipes/ALUs etc for the mobile editions? (all wrt power consumption)

Well, all physical aspects depend on the technology. This includes the elements that make up ASICs (stdcell, memories, macros, etc...). We need to re-characterize and update all libraries and models associated with those. This can mean new synthesis, new P&R rules, new macro designs, etc... This affects everything from the netlist on down, but it can even have ramifications up through the architecture, as you might need to change some functionality, re-pipeline, change your memory usage, for example. It's a lot of work.

1/2 nodes are a little easier, as most things can be simply optically shrunk -- You have to design with that in mind, but it can be easier. Famous last words.

 

[sireric]

Eric,

What was the first game tested on the R600?

Now that it is complete what interaction do you have with the driver team? In particular, do you let them know how close / far away from theoretical performance they are?

First game? ooouf, I don't remember. I know that once you've booted up windows and gotten some of the SDKs working, you've made it past many potential problems.

I know a lot of the driver folks personally -- Some for many years. The driver "team" is actually composed of many subteams, each specializing in different aspects of the code. I try to attend some of their weekly meetings, to get a bead on their status and to give some HW feedback; though I haven't been very good on that front. But we field daily questions from them on various aspects of our chips, as well. We certainly encourage them to take advantage of any aspect of our chips we can think of -- Sometimes, when we both focus on 1 problem, we come out with lots of ideas.

But there's the whole forward looking / architecture aspect that also occurs. We work together to specify how our chips should work in the future. We realize that we ship systems that are composed of SW and HW, and one cannot exist without the other. We plan things together.

 

[sireric]

Sir Eric,

First of all, thanks for the info. Seeing you writing again like this reminds me of other days, long past... Your input, as always, is both interesting and much appreciated.

No prob. I'm just giving my opinion -- As many have said, take it with a grain of salt and make up your own minds. But I'm just telling it as I see it.

I wanted to ask you whether, from an engineering standpoint relative to the R600 project, the merger with AMD presented situations that might have in some ways impacted the roll out of R600. I'm speaking only of any practical things that you may have seen arise as a result of the merger process that affected your particular job in that regard. This isn't really a loaded question as I have no idea what you might say, if anything. If the merger didn't phase you in that respect I'd like to know it out of simple curiosity.

It's a valid question. From a day to day thing, I don't think that the R600 was much impacted by the merger. When we heard about it last summer, the chip was pretty much finished and on its way to manufacturing, or even back. During the bringup, I don't know that it affected things much at all -- From an engineer standpoint, it's not a big impact; the main aspects have been changing how we do certain things (like filing expense reports ;-)), but it hasn't interfered with the engineering methods. We do interact with a lot of new engineers now, but that's all good stuff. From a time to launch, marketing, PR standpoint -- It's possible those were affected, but I'm not directly involved so I'm not going to comment.
Also, talking about new architectures and the necessity of progressive driver refinement, I am reminded of the early months after R300 shipped. In particular, you may remember all of the Internet speculation and opinion circulated at the time NWN shipped, when it was often stated in the beginning that the reason NWN's "shiny water" wasn't shiny on R300 was because of innate hardware limitations inside R300 that precluded the chip from being able to handle such effects in general. I believe that in the beginning even Bioware itself stated such an opinion. Of course, as time and drivers and Bioware's education of R300 progressed, the shiny water effect soon displayed perfectly on R300 in the game and that particular bugaboo was put to bed for good. Just a comment to indicate that if things with R600 improve with further driver refinement over the next few months, much as they did following the shipping of R300, that I would not be surprised.

Hope that answers things.

 

[sireric]

In a HyperTransport enabled system, would the HD2900 benefit from being directly connected to HyperTransport (via HTX for instance)?

That's a good question -- Off hand, I don't have the BW and latencies involved in the HT vs. PCIe numbers. Though I would guess that it would benefit from being directly on the HT (lower latency and probably something like ~50% higher BW). It would make hooking up a southbridge harder though.