AMD: R9xx Speculation

apparently that overclock site is saying that amd is going to raise the prices in january. Makes little sense to me ,but meh , looks like i'm sitting this out cause i wouldn't be able to order till after the holiday

Didn't that have something to do with their taxes increasing? I don't really remember, but if supply is good I wouldn't expect prices to rise.

I dunno , the way it was told to me is that AMD was raising the prices , not that the taxes would increase.

I dunno , i'm hoping a pride drop from nvidia will spur one from amd !

Indeed, it is due to an increase in taxes of 2,5% in UK starting next year 2011.
 
The 69XX are certainly good cards. I do have the feeling that I expected something more though.

From a power draw/performance point of view, they seem to have taken a step backwards, while Nvidia has taken a step forward.

My local retailers are asking 400 euros for the 6970, when I found PNY's 570 for 340 euros. That, coupled with the issues AMD is having with the frequency selection on HDTVs, is a no brainer for me. Soon I will be a proud owner of two 570s that should be enough for the year to come I guess. I will keep my 5850s though on the secondary machine. The extra framebuffer of the 6970 is useless to me anyway and the extra 25% of the 570s compared to my 5850s, will be more than enough.

All in all, good job from companies though, considering the limitations of 40nm. They could be better priced imo, but oh well!
 
Other than the larger-than-it-should-be blur area in the end, is it unfortunately? If the screenshots from GeForce is correct (in the 5800 AF Broken thread), it seems nVidia is just blurring the textures on the certain areas prone to shimmer.
Of course choice would be nice and all, but I rather take shimmering in some games vs blurred textures.


Depends if you see the shimmering or the blurred textures. I prefer non visible (without a magnifying glass) blurred textures rather than visible shimmering (the inverse is true also) :!:
 
How many of the reviews had the AMD cards on HQ filtering for this? nVidia was on a push to ensure as many as possible had the highest setting - just for AMD mind.
 
Please Carsten , have your colleagues publish your reviews in English , it's been a while since the last time you guys did that , you used to write reviews and reports both in English and German , what happened ?

Maybe try out Chrome browser. I dont think it would make to much sense for them with all the translators. They just need to avoid putting to much text on the pictures. (and german->english is quite accurate)
 
For example, in my opinion the switch to VLIW4 was in preparation of doubling the ALU count per SIMD, but 40nm didn't allow for that yet (at least not without reaching GF100 levels of die area and power consumption).

I fully expect Cayman's 28nm successor to feature 128 ALUs per SIMD and more SIMDs as well. 32*128=4096 sounds nice to me.
There's no reason for AMD to meddle with the SIMD width (and batch size, in the same manner). It would be counter productive to utilization efficiency.

Anyway, let's take on the AA front. Cayman seems to introduce new default 4xAA sample pattern:

48464027.png


Probably this is in relation to the new coverage sampling method, not sure about the vanilla MSAA pattern.
 
Isn't that only the case with EQ-mode on?

edit: I like the numbering of EQAA in the CCC. It's just so much more concise than Nvidias nomenclature in this regard.
 
Last edited by a moderator:
Looks like the tessellation off-chip buffer is just the RAM !
Just having two 7th generation-like tessellators goes a long way towards improving AMD’s tessellation performance. However all of that geometry can still lead to a bottleneck at times, which means it needs to be stored somewhere until it can be processed. As AMD has not changed any cache sizes for Cayman, there’s the same amount of cache for potentially thrice as much geometry, so in order to keep things flowing that geometry has to go somewhere. That somewhere is the GPU’s RAM, or as AMD likes to put it, their “off-chip buffer.” Compared to cache access RAM is slow and hence this isn’t necessarily a desirable action, but it’s much, much better than stalling the pipeline entirely while the rasterizers clear out the backlog.
Anand
 

Nor in ours, just as expected. Having said that, without upping Powertune, there was some minor throtteling going on which affected random tests out of the suite, where rioughly 20% less performance was being measured.

Looks like the tessellation off-chip buffer is just the RAM !
Anand

Honestly, what did you expect, when AMD says "off chip". I mean, what else is there besides the chip and the memory. :)
 
Maybe try out Chrome browser. I dont think it would make to much sense for them with all the translators. They just need to avoid putting to much text on the pictures. (and german->english is quite accurate)
Quite , but not accurate enough -at least for me- .
I really would like to see pcgameshardware's reviews and reports written in English , especially as they usually do cool reports on games and graphics .

Honestly, what did you expect, when AMD says "off chip". I mean, what else is there besides the chip and the memory. :smile:
Yeah , I guess I should have expected that :-?!

Now the only thing missing in the picture is R/W L2 cache to complelent that buffering, but that's for the next generation.
Speaking of which ,look like Charlie is expecting 28nm to appear late this year !
 
Please Carsten , have your colleagues publish your reviews in English , it's been a while since the last time you guys did that , you used to write reviews and reports both in English and German , what happened ?
Ooops, didn't see that.
Thanks for liking our tests :) But now with a rather large article (we also have to do a version for our print mag, which needs to have some cool stuff not found online as well) almost every other week, it's just time constraints.

But rest assured, I keep pushing my boss to allow time for translations.

Also, if there's anything particularly unclear in the automated translation via google, just ask. As long as it it's not whole pages, I'll be happy to help. :)
 
Yep!
Now the only thing missing in the picture is R/W L2 cache to complelent that buffering, but that's for the next generation.

Does this mean that there in fact is no bandwidth saving when doing tessellation on the 5800s and 6900s? Doesn't that then defeat the purpose of doing tessellation in the first place (other than using less memory to store all the geometry)?
 
The first part of the bandwidth savings starts with the transfer of geometry data from the host system to the graphics card itself. Also, the off-chip buffer only kicks in, when local buffers overflow - something I would have taken for granted on first-gen DX11 chips also.
 
But rest assured, I keep pushing my boss to allow time for translations.

Also, if there's anything particularly unclear in the automated translation via google, just ask. As long as it it's not whole pages, I'll be happy to help. :)
Thanks , I really appreciate it :smile: , keep pushing that boss of yours though , tell him the fans are waiting eagerly :D .
 
Does this mean that there in fact is no bandwidth saving when doing tessellation on the 5800s and 6900s? Doesn't that then defeat the purpose of doing tessellation in the first place (other than using less memory to store all the geometry)?
Cypress simply stalls its pipeline with higher tessellation factors. Cayman now simply dumps all the data from the hull/domain shader in the frame buffer (video memory), but now the limiting factor becomes the memory BW -- not much better situation from the previous gen.

Jawed could elaborate more on the matter, I think. ;)
 
Looks like the tessellation off-chip buffer is just the RAM !
What else did you think off-chip meant?

I'm not impressed with ATI's tessellation technology at all. The whole point of DX11 tessellation is that you don't need to tessellate a whole patch before you start rasterizing, so buffer requirements for a good algorithm are minimal. Still, even if you have to buffer the tessellator output in the RAM, the bandwidth cost should be very low, so as kludgy as this solution is, it should work. Carsten's results, however, still show the horrible scaling from before.

The doubled geometry throughput doesn't seem to be working very well, either. I hope drivers can cure whatever ails Cayman in this respect.
 
Back
Top