Today marks our first glimpse at Evergreen.

Evergreen is the codename for AMD's 40nm DX11 based product. With AMD's codename shift this time around, it is still a little ambiguous as to whether Evergreen is a GPU class or a specific configuration. While it is exciting that they're sharing what they are, AMD are still holding quite a few cards close to their chest. We know almost nothing about the details of the configuration, except that is is built on a 40nm process, is fully DX11 compliant, and that AMD put forth a slide titled "DirectX 11: sooner than you think."

Of course, sooner than I think would have to mean DirectX 11 would be here before Windows 7 launches (which is sort of impossible). We learned today that Microsoft has announced Windows 7 will be here on on shelves on October 22nd. From AMD's press release and slide deck, however, the only safe bet on when we'll see hardware is before the end of the year. But teasing us with "sooner than you think" would just be mean if we'll have to wait that long.

If AMD doesn't need to respin their silicon and Evergreen really is complete as of today (aside from qualification, tuning and ramping production), AMD really could be ready to ship product much sooner than November, getting product out along side or in advance of Windows 7. It all really depends on a bunch of things they aren't going to tell us. Of course that's just the way it is, but that doesn't make it any less frustrating not knowing.

We can ascertain from the wafer shot AMD provided us that there are about 19.5 dies vertically and 25.5 dies horizontally. As this is a 300mm wafer, we can sort of "guess" the dimensions of the chip at roughly 15.38mm x 11.76mm resulting in a die area of a little over 180mm^2. This is much smaller than the 55nm RV770 which is a 260mm^2 part, so if we expect a similar price target for the first Evergreen die that we saw with RV770, we could see a significant cost savings (and hopefully this tiny die will deliver a good general performance improvement as well).

Compare this die size to RV740 that weighs in at 137mm^2 and 826 million transistors, and we can estimate very loosely that Evergreen could come in at something over 1 billion transistors. Certainly the process has been tweaked since RV740 and Evergreen is a different architecture and layout, so scaling isn't exact or direct, but proportionally AMD should be able to fit that many transistors into only 180mm^2 on the 40nm process.

We'll definitely be interested in seeing how close our guesses are when we finally have hardware in hand. But this still doesn't speak to performance. Our only real reference for AMD's target is to guess that they will want to come in at near the same price point the RV770 hit at: the $200 - $300 range. With the added transistors, changes in architecture, and clock speed advantages with the 40nm process over 55nm, we could reasonably see AMD hitting that target.

Showing off Demos and Preliminary Thoughts

Unfortunately, we don't have any videos of the demos in action as presented at Computex. All we have to go on right now is a presentation from AMD with some slides showing stills from some demos. Here's a DX11 SDK sample showing sub-division surfaces using tessellation.

Since we don't have hardware that can run this demo as of yet, we can't really know how good 14 frames per second really is or what it means. We'll have to wait until we have competitive hardware to do any evaluation of performance (or we'll have to wait until AMD shows us something we can compare to current DX10 hardware running on Evergreen). Also shown were some other demos including transcoding and compute shader based AI.

While there are a lot of applications that will be potentially enabled by the compute shader, it will certainly take some time for developers to get familiar and comfortable with treating the GPU like another processor for data-parallel compute operations. Our expectation is that DX11 (and preparation for the next round of console game systems) will serve as a catalyst for a final push away from DX9 based hardware and into the realm of real programmability.

While dynamic branching has been available since DX9, we haven't seen heavy use of it as it can be very resource intensive and slow even on modern hardware. Yes, it's much faster today, but there are still somethings that are not practical today despite the fact that some algorithms would significantly benefit from fast branching. We hope, and it seems AMD believes, that DX11 class hardware will continue the trend of speeding up and improving branching on GPUs. Here's a timeline showing ATIs GPU technology progression at a very high level.

From the context of the presentation and what we've seen, AMD is really interested in pushing their tessellation technology. Tessellation has been an option since R600, but it hasn't been taken incredibly seriously because it wasn't a standard feature and couldn't run on all DX10 hardware. DirectX 11 changes that, and AMD is touting their experience as a benefit here. We'll have to wait and see what NVIDIA does, as experience doesn't always mean better.

So, the big deal today is that AMD is showing off working DX11 silicon on a 40nm process running DX11 demos. We expect DX11 before the end of the year based on what AMD has said. Now that we know when Windows 7 will hit (October 22nd) and that AMD already has Evergreen silicon in their hands, we are fairly hopeful that AMD could introduce their DX11 part ahead of Windows 7 if everything goes smoothly for them from now until then. Definitely cool stuff that really puts the pressure on NVIDIA to follow suit and start talking about their DX11 answer.

POST A COMMENT

33 Comments

View All Comments

  • DerekWilson - Wednesday, June 03, 2009 - link

    TruForm was horrible.

    It was tacked on tessellation that users could enable through the driver and caused very bad looking artifacts. developers could modify their game to not make truform look horrible (which it did most of the time), but they had no real, useful, workable control over the tessellation and had to design models in a restricted way to make it work right.

    ATI always tries to add truform to their list of reasons they know tessellation, but if I were them I would certainly want to distance myself from that technological horror.

    Developers have had the option of building their games to include sane, good, and appropriate tessellation with good control over what and how something is tessellated since the R600. Despite the fact that it was not available in DX and developers did not do it as a rule, it was possible to implement tessellation in a game on R600 and later hardware.

    I stand by my statement. Anyone could put a geometry amplifier in their hardware, close their eyes and hope it works out for the best. Truform did a great job of showing that is not a good idea.

    I am sorry about the grammar errors, though. I hope I've fixed all the errors by now.
    Reply
  • Goty - Wednesday, June 03, 2009 - link

    TruForm (implemented since the Radeon 8500 days) is tessellation.

    Nice try, now go troll somewhere else, please.

    Reply
  • doncerdo1 - Wednesday, June 03, 2009 - link

    Your answer was pretty weird...my whole point was precisely talking about ATI's TruForm (available as you said since the R200) showing that Wilson's "Tessellation has been an option since R600" statement is false (as most of the crap he writes basically because he never cares to check facts.) So seriously dude WTF with your answer?

    I love Anandtech but seriously Wilson makes this site look really bad.
    Reply
  • TA152H - Wednesday, June 03, 2009 - link

    The grammar in this article is horrible too. It was really poorly thrown together, and just plain bad reading. I resent it when people write articles and do not put forth an effort to write it properly. For something this small, it's unsupportable. I am sure they realize how many people read these articles. Why write them to be sub-literate like this is? He's surely able to do better, so it's lack of effort. It's not good. Reply
  • samspqr - Wednesday, June 03, 2009 - link

    a) relax, people!

    b) I didn't think the article was written any worse than the average internet text; the bar is so low, I just got used to it: unless it's truly impossible, my brain transparently translates everything to a language it can understand

    c) in any case, you have to understand that he's (most probably) at computex, so it's either rush the story in a hurry, or wait a week and post it when you're back home; I prefer the first option

    d) with respect to tesselation, I think Wilson is referring to the fact that R600 included most of what's going to be DX11's tesselation, because it was supposed to be a part of DX10, but got dropped from the spec at the last moment, because of nvidia pressure; I don't know about TruForm, but I'd be quite surprised if R200 were compatibe with DX11's tightly defined tesselation
    Reply
  • SilentSin - Wednesday, June 03, 2009 - link

    In response to d), not even the R7xx implementations of tessellation will be compatible with the newer DX11 spec because of slight differences. I've read about it in various articles where AMD responds to changes with DX11, but I can't recall exactly where atm.

    It might have been good proof of concept testing for AMD to put in their chips, but I wouldn't hold my breath hoping that game devs will branch their code paths just to make tessellation work with AMD's DX10 hardware no matter how close it is to DX11. AMD might try to get that kind of backwards functionality via drivers, just as some DX10.1 features (mostly AA stuff) have been made possible on NV hardware with driver revisions, but I don't think it's likely.

    I think you're right in saying the only real reason we see this on the 2000-4000 series is because of how DX10 was supposed to be. They didn't have a real reason to take it out and it probably wasn't taking up much room so they just left it in for R7xx. I guess it also gave PC devs the option of having that feature if they were porting an X360 game, but I don't think that has ever been used.

    If you look at the actual slides that AMD showed at this conference (see or google) then you will see they put TruForm in the same evolutionary line as the more modern implementations of tessellation. It also gives 2 real world usage examples which are, lo and behold, both examples from X360 games. They mention Mass Effect, not sure if the tessellation carried over to the PC for ATi hardware but I have a feeling it wasn't.

    At any rate, with DX11 tessellation should start to take off. AMD can at least say they've been around that block once or twice, but with something like this I'm not too sure that will give them much of a leg up on NVidia once they get the ball rolling too.
    Reply
  • bobvodka - Wednesday, June 03, 2009 - link

    The R600+ tessellation hasn't shown up simply because until early this year there has been NO way to program it.

    DX9 doesn't have support, DX10 doesn't have support and it was only recently that the OpenGL implimentation started exposing the extension string to get at it, and given that game wise OpenGL is basically dead on the PC (I say this as an ex-OpenGL developer; iD are the only company of note to use it, even WoW ships with D3D enabled by default on windows) no one has bothered to deal with it.

    As for DX11 itself, it's important for a number of reasons beyond the extra hardware;
    - multi-threading is MUCH easier, while the final draw still has to happen on the main thread other threads can submit resources and build 'display lists' to be quickly executed
    - Feature levels; DX9's capbits without the explosion... iirc this will even allow the DX11 API to be used with DX9 hardware.

    There are a few more, but it's late and my memory has escaped me on the matter.
    Reply
  • doncerdo1 - Wednesday, June 03, 2009 - link

    a) I am ;)

    b) That's what I don't like about AT part 1: The whole idea of this site was the QUALITY of its content...maybe the internet is like this but AT was one of the few bastions that were free from being mediocre

    c) Rush justifies a piss poor reporting job?

    d) Inferring what he might have meant is not the best way to go. In the end, you end up giving a guy like Mr. Wilson the credibility he doesn't deserve...seroiously he's pretty bad whenever he states an opionion. At most he should be tester but let someone else write for him.

    In the end I insist, I love AT but seriously guys like this bring the content quality down. Besides AT has a big influence and is very well respected as a professional source of information. Why should mediocrity be justified?
    Reply
  • Viditor - Thursday, June 04, 2009 - link

    doncerdo1
    "The whole idea of this site was the QUALITY of its content"

    And the idea for these comments is to give useable feedback, not rude tirades. Seriously, I don't know if you had a valid point or not because your comments were so nasty that to me you were illegible.

    You should attempt constructive criticism on specifics if you really want to accomplish anything more than just venting.

    Specifically, lines like:
    "As always, Wilson shows how little he knows about GPUs and proves he is only good at benching tons of hardware"

    What good does that do except to show that you can be an asshole?
    Reply
  • sbuckler - Wednesday, June 03, 2009 - link

    d) I am sure Mr Wilson knows perfectly well what TruForm is. Most people who've been around graphics cards for a few years know about it. This is mainly because Ati fan boys banged on about how great it was for years.

    Hence all you do is sound like a bitter fan boy upset about the fact the rest of the world never embraced TruForm.

    The point I thought he was trying to make in the article is that in DX11 tessellation is now in the standard. Be happy that it therefore might actually start to get used and stop nit picking about the past.
    Reply

Log in

Don't have an account? Sign up now