Monday, September 27th 2010

AMD Radeon HD 6700 Series ''Barts'' Specs Sheet Surfaces

Here is the slide we've been waiting for, the specs sheet of AMD's next-generation Radeon HD 6700 series GPUs, based on a new, radically redesigned core, codenamed "Barts". The XT variant denotes Radeon HD 6770, and Pro denotes HD 6750. AMD claims that the HD 6700 series will pack "Twice the Horsepower", over previous generation HD 5700 series. Compared to the "Juniper" die that went into making the Radeon HD 5700 series, Barts features twice the memory bandwidth thanks to its 256-bit wide high-speed memory interface, key components such as the SIMD arrays split into two blocks (like on Cypress), and we're now getting to learn that it uses a more efficient 4-D stream processor design. There are 1280 stream processors available to the HD 6770 (Barts XT), and 1120 stream processors to the HD 6750 (Barts Pro). Both SKUs use the full 256-bit memory bus width.

The most interesting specification here is the shader compute power. Barts XT churns out 2.3 TFLOP/s with 1280 stream processors, GPU clocked at 900 MHz, while the Radeon HD 5870 manages 2.72 TFLOP/s with 1600 stream processors, 850 MHz. So indeed the redesigned SIMD core is working its magic. Z/Stencil performance also shot up more than 100% over the Radeon HD 5700 series. Both the HD 6770 and HD 6750 will be equipped with 5 GT/s memory chips, at least on the reference-design cards, which are technically capable of running at 1250 MHz (5 GHz effective), though are clocked at 1050 MHz (4.20 GHz effective) on HD 6770, and 1000 MHz (4 GHz effective) on HD 6750. Although these design changes will inevitably result in a larger die compared to Juniper, it could still be smaller than Cypress, and hence, more energy-efficient.

Source: PCinLife
Add your own comment

245 Comments on AMD Radeon HD 6700 Series ''Barts'' Specs Sheet Surfaces

#1
Wile E
Power User
TheMailMan78 said:
And maybe one day people will learn how to properly uninstall and install their drivers instead of screaming "ATI DRIVERS SUCKS!" on every forum in the interwebz.
Maybe AMD will hire something other than monkeys to code their drivers and installers, then maybe I'll stop screaming "ATI DRIVERS SUCKS!" all the time. They even suck on a clean install.

This is the last AMD card I will have until they put out some decent drivers. The last good one was 10.4a. The last good one before that? 8.10

The hardware is great, software is garbage.
Posted on Reply
#2
T3kl0rd
5770 was meant to be equal to 4870 with marginal improvements and DX 11 support. As I predicted, the new 6xxx series will double the power of the 5xxx series despite recycling the 40nm process. Hopefully I can get another GTX 470 cheap soon. ^^
Posted on Reply
#3
cheezburger
wahdangun said:
then i will betting 256bit bus with high speed GDDR5
do you honestly believe a high end card will only feature 32rop and 256bit bus while have ridiculous number of shader? this is no longer r670 to r770 transition that you can add up 2.5x shader to boost performance. that will not be the case this time. that means more shader don't mean huge boot in performance. under the same rops/bus configuration a balance GPU design will out perform a GPU that's steroid with more shader ALU. like when 4830 compete with 4870 it shows 4830 has more efficient than 4870. all they need to do is enhance the ALU performance rather than make cheaper low complex shader but take more space and number to fill up the performance.


the rumor of 640ALU with 32 rops and narrow 256bit bus will just make it sound stupid if everything double up except rops/bus since the original r600 design is already unbalanced. if they haven't learn from what happened on r770 then they are pretty much hopeless...which i doubt amd are smart company if they done such non profit plan.

this is the fact that adding rops/bus are more profitable than adding ALU number
shader die space in cypress is 60% and 4D shader is 80% of 5D shader in size and SIMD controller and TMU took about 15% then here will be 2(334x 0.6 x0.8)+2(334x0.15)+334x0.25 = 320.64 + 100.2 +83.5 = 504.34mm^2 + hard wiring = 510mm^2

that is huge die and such 510mm^2 only has 32 rops????and i don't see any reason why we'd need 640ALU for? folding@home?
and you expect a 510mm^2 chip using a narrow 256bit bus on it?

if the shader turn out to be 5120(1280ALU) then the die size will be:

4(334x 0.6 x0.8)+4(334x0.15)+334x0.25 = 641.28 + 200.4 + 83.5 = 925.18mm^2 + hard wiring = 940mm^2......

shader like this are pointless if you don't have more rops to push it. like g92 was bottleneck by its 16 rop while it had 128 ALU. and now cayman that has 1280 ALU but 32 rops....that is a big joke...

if the specification turn out to be 1920:96:64 512bit story will be vastly different from above

1.5(334x0.6x0.8)+1.5(334x0.15)+2(334x0.25) = 240.48 + 75.15 + 167 = 482.64mm^2 + hard wiring = 484mm^2

480ALU is what we need in existed 40nm..no go further....
what is most profitable if you can't shrink the die size because of put too many ALU on it

hard fact, a 480:96:64 with 512bit will make a 640:128:32, 256bit like shit in term of die space/power consumption/performance.
Posted on Reply
#4
pantherx12
Is it not possible to have 64 rops AND a 256bit bus?
Posted on Reply
#5
Tatty_One
Senior Moderator
pantherx12 said:
Is it not possible to have 64 rops AND a 256bit bus?
No, Clusters of 8 within the bus/rop/sp/tmu relationship..... example, GTX 480.... 384bit bus divided by 8 = 48 ROP's.
Posted on Reply
#6
pantherx12
Tatty_One said:
No, Clusters of 8..... example, GTX 480.... 384bit bus divided by 8 = 48 ROP's.
But that is not set in stone, see 2900xt for past reference.

16 rops over a 512bit bus : ]


64/256 is possible I'm sure of it.
Posted on Reply
#7
Tatty_One
Senior Moderator
pantherx12 said:
But that is not set in stone, see 2900xt for past reference.

16 rops over a 512bit bus : ]


64/256 is possible I'm sure of it.
less is possible of course, more is not as I understand it.... with more you get the limitations, with less you don't..... think of a Jaguar S Type car, it will take a 4.2 litre V8 engine, the most common engine however is the 3 litre V6 :laugh: it won't take the old Sovereign V12 6 litre, hence why Jag had to re-design their engines when they redisgned thier new model range.....

Crap example I know but I just had to!
Posted on Reply
#8
Tank
so what's the real name then?

i sure hope AMD don't go the nv route with changing naming conventions so early :(
Posted on Reply
#9
Tatty_One
Senior Moderator
cheezburger said:
technology is progress as ground breaking/brutal force(new technology/architecture)=> tweak,efficient redesign(reconfigure/die shrink)=>upward and push further performance with brutal force again. that is what moore's law about and these average consumer are about to destroy it. however hd 6000 will be just as what moore's law predict and all IC industry will follow until the end of humanity! that won't change forever.

moore's law and technology only serve elite, not average joe.
Actually you are over complicating things, I am old so I like it simple, such as..........

"Developing (New) technology is simply offering more (performance) ....... for less (production costs).... to increase profit (margins)". Where retail costs increase because of that development is usually down to one of two factors...... they didn't quite get it right or simply just greed :laugh:
Posted on Reply
#10
bear jesus
I honestly had no idea rop's were tied to memory bus size, well a few things make a little more sense now although i feel a little dumb for not knowing this before :laugh:
Posted on Reply
#11
Tatty_One
Senior Moderator
bear jesus said:
I honestly had no idea rop's were tied to memory bus size, well a few things make a little more sense now although i feel a little dumb for not knowing this before :laugh:
ROP's > TMU's > SP's (Cuda Cores etc) > bus width all form a relationship of sorts, it can get quite complicated, I am not an expert but there are limitations with some of those relationships.
Posted on Reply
#12
dalelaroy
Increasing ROPs

Tatty_One said:
less is possible of course, more is not as I understand it.... with more you get the limitations, with less you don't..... think of a Jaguar S Type car, it will take a 4.2 litre V8 engine, the most common engine however is the 3 litre V6 :laugh: it won't take the old Sovereign V12 6 litre, hence why Jag had to re-design their engines when they redisgned thier new model range.....

Crap example I know but I just had to!
Saying that doubling the number of ROPs per bus is impossible is absurd. This would imply that, no matter how fast memory gets, the industry would have to go beyond a 512-bit bus to go beyond 64 ROPs. It might however be overkill. Cayman will likely only be 1.5x Barts, and might only be 1.25x Barts. It seems the Radeon HD 2900 GT had only 3 ROPs per memory controller, so an odd number would appear possible. This would imply that 12 ROPs per memory controller could be possible.

It is the Radeon HD 4730 versus the Radeon HD 4830 that demonstrates just what impact changing the number of ROPs can have. They were virtually identicle in specs, except the Radeon HD 4730 had half the ROPs and was clocked at 750MHz versus 575 MHz for the Radeon HD 4830. On average the Radeon HD 4830 beat the Radeon HD 4730 by a small margin. According to my estimate, the Radeon HD 5830 could be clocked at about 700 MHz and provide equivalent performance if it had its full complement of ROPs.

Assuming Barts is as described, and provides the same per shader performance as Cypress, it should provide about a 4.3% increase in performance over Cypress LE, despite being clocked 9.375% lower. This would be due to Barts Pro having 81.25% more ROP performance than Cypress LE. And Barts XT should provide about a 18.685% increase over Cypress Pro despite having just a 10.345% increase in shader performance, because of a 24.138% increase in ROP performance.

With these assumptions, doubling the ROPs would increase performance of Barts XT by about 10.25%. I don't think doubling the ROPs would be cost effective with regards to die size, but if they could, increasing the ROPs per memory controller by 50% probably would.
Posted on Reply
#13
Tatty_One
Senior Moderator
dalelaroy said:
Saying that doubling the number of ROPs per bus is impossible is absurd. This would imply that, no matter how fast memory gets, the industry would have to go to a 1024-bit bus to go beyond 64 ROPs. It might however be overkill. Cayman will likely only be 1.5x Barts, and might only be 1.25x Barts. It seems the Radeon HD 2900 GT had only 3 ROPs per memory controller, so an odd number would appear possible. This would imply that 12 ROPs per memory controller could be possible.

It is the Radeon HD 4730 versus the Radeon HD 4830 that demonstrates just what impact changing the number of ROPs can have. They were virtually identicle in specs, except the Radeon HD 4730 had half the ROPs and was clocked at 750MHz versus 575 MHz for the Radeon HD 4830. On average the Radeon HD 4830 beat the Radeon HD 4730 by a small margin. According to my estimate, the Radeon HD 5830 could be clocked at about 700 MHz and provide equivalent performance if it had its full complement of ROPs.

Assuming Barts is as described, and provides the same per shader performance as Cypress, it should provide about a 4.3% increase in performance over Cypress LE, despite being clocked 9.375% lower. This would be due to Barts Pro having 81.25% more ROP performance than Cypress LE. And Barts XT should provide about a 18.685% increase over Cypress Pro despite having just a 10.345% increase in shader performance, because of a 24.138% increase in ROP performance.

With these assumptions, doubling the ROPs would increase performance of Barts XT by about 10.25%. I don't think doubling the ROPs would be cost effective with regards to die size, but if they could, increasing the ROPs per memory controller by 50% probably would, if it can be done.
Well nothing technically is impossible..... even though your narrative makes assumptions that it might be possible or it might be impossible? As i have said, there are a number of other factors that determine performance, not just memory bandwidth and ROP count. I understand your logic, however there is I beleive with the current architecure the limitation and with that in mind I think it is not possible currently, I cannot speculate on what might be in the future, as it stands.... today, I don't beleive it can be done (otherwide someone would have had a go), possibly in the future as you have indicated but I can only make a call on what is and not what might be.... the question was "can it be doubled" ....

Lets see if the ROP ratio does increase in relation to bus size on the new 6XXX series, if it does your sure to be right! :) and if it don't you will probably just say that they chose not too.
Posted on Reply
#14
yogurt_21
Tatty_One said:
Well nothing technically is impossible..... even though your narrative makes assumptions that it might be possible or it might be impossible? I understand your logic, however there is I beleive with the current architecure the limitation and with that in mind I think it is not possible currently, I cannot speculate on what might be in the future, as it stands.... today, I don't beleive it can be done (otherwide someone would have had a go), possibly in the future as you have indicated but I can only make a call on what is and not what might be.... the question was "can it be doubled" ....

Lets see if the ROP ratio does increase in relation to bus size on the new 6XXX series, if it does your sure to be right! :) and if it don't you will probably just say that they chose not too.
well it's simply hard to believe that they'd keep the same rop number from the mid range to the highend. so if barts does have 32 rop's, I'd have to assume that caymen has more shader increase alone isn't going to offer that great of a performance boost which would essentially cause a ton more people to buy barts and overclock it rather than waste money on caymen.

while 64 rop's and 512bit memory are a little ridculous cost wise, the idea of 384-bit and 48 rop's isn't imo. soo... running down that line.

spec------barts xt------caymen xt
rop's------32-----------48
memory---256-bit-------384bit
shaders---1280---------1920
tmus------64-----------96
Posted on Reply
#15
de.das.dude
Pro Indian Modder
i hope they develop the 6700 fast ! cant wait to see some pix!
Posted on Reply
#16
Tatty_One
Senior Moderator
yogurt_21 said:
well it's simply hard to believe that they'd keep the same rop number from the mid range to the highend. so if barts does have 32 rop's, I'd have to assume that caymen has more shader increase alone isn't going to offer that great of a performance boost which would essentially cause a ton more people to buy barts and overclock it rather than waste money on caymen.

while 64 rop's and 512bit memory are a little ridculous cost wise, the idea of 384-bit and 48 rop's isn't imo. soo... running down that line.

spec------barts xt------caymen xt
rop's------32-----------48
memory---256-bit-------384bit
shaders---1280---------1920
tmus------64-----------96
What you (and Dalelaroy)are saying makes sense and I am not arguing against the logic, the point is that the memory bus and ROP count are not the only factors determining the performance. Cypress is a good example, the 5850 and 5870 have the same memory bus and the same ROP count (32) to determine the performance segment differences one is clocked higher, it has a greater number of SP's AND more texture units as well as having (reference) faster memory. Now if that architecture is significantly changed and the relationships between each process within the architecture changes it might be that what is considered the "norm" or the limitation now ceases to be in the future, but again that is speculation.

Additionally your comparision therefore between "Barts" and "Caymen" is little more than the comparison between the 5850 and the 5870 surely, less bus size and therefore ROP count? The typical performance differences within the market often can be attained (lets say 15% between 2 models) without having to increase bus size and/or ROP count as Cypress has shown.

Although this does not deal with any limitations between bus width and ROP count that we have mentioned, it does explain very well how segments with the same bus sizes and ROP count can differ a fair bit in performance through other means, I know the link is from semi accurate but this piece is not about speculation but actually makes comparisions with actual hardware and its architecture, if you scroll down to the chart about the 9600 and 9800 and read until the end of the page, it is quite interesting.....

http://www.semiaccurate.com/2010/09/20/northern-islands-barts/
Posted on Reply
#17
TheMailMan78
Big Member
Wile E said:
Maybe AMD will hire something other than monkeys to code their drivers and installers, then maybe I'll stop screaming "ATI DRIVERS SUCKS!" all the time. They even suck on a clean install.

This is the last AMD card I will have until they put out some decent drivers. The last good one was 10.4a. The last good one before that? 8.10

The hardware is great, software is garbage.
Posted on Reply
#18
Benetanegia
Tatty_One said:
What you (and Dalelaroy)are saying makes sense and I am not arguing against the logic, however "they" don't keep the same number of ROP's from the mid range to the high end, thats just the point, HD 5850 does not have the same amount of ROP's as the HD 5870 does even though they both have the same memory bus, why? because as i said, each cards has its market segement as well as they both have different SP's, because there are links with TMU's, SP's and Rop's, the 5850 with it's lesser SP count is given
First of all the HD5850 and HD5870 do have the same ammount of ROPs. Second you are right regarding the links, there is probably a close limit in the relation between ROPs and memory bandwidth, personally I think this limit is mostly on z/stencil. The two main purposes of ROPs are to calculate z/stencil and blend final pixels, either one requires writing to memory, so there is a strong relation between both.

I stand to be corrected in what follows, as I'm in no way an expert, but it's what I understand from the things I do know or have heard about. Let's explain it with an example, and let's take the HD5870 numbers from the chart in the OP.

Memory bandwidth: 153.6 GB/s == 1228.8 Gb/s
Pixel fillrate: 27.2 GPixel/s
Z/stencil: 108.8 GSamples/s

Now for stencil the most common used value is one byte per pixel, while Z sample in modern games is either 24 bit or 32 bit, because 16 bit creates artifacts.

Thus the average bit-lenght of samples is going to be between 8 and 24/32, let's settle down to 16 bit samples. Simple math from the specs tells that 108.8 Gsamples x 16 bit samples = 1740,8 Gb/s.

As you can see the required bandwidth to write z/stencil only scenarios already exceeds memory bandwidth limitations and it's worse in the cases when it's doing Z test. Of course the ROPs also have to write down pixels so I understand that is less taxing and makes up for the difference, because typical HDR pixels are 16 bit wide (per channel), so 27.2 GPixel/s x 16 bit* = 435.2 Gb/s and output of current games is 32 bit so 870.4 Gb/s.

* Here I have to admit I don't know if the pixels are blended and written separately by channels or alltogether. In case of the latter, the figure jumps to 1740.8 Gb/s (64 bit x 27.2 GPixel/s) again, and may actually reflect better the relation as the average of both 32 bit and 64 bit outputs is 1305.6 Gb/s, quite similar to the actual memory bandwidth.

As you might have guessed already doubling (even increasing) the ROPs is not going to yield any substantial gains, even with the increased 25% GDDR5 speed of 7 GT/s modules, especially considering that above numbers are only for write operations (and not all of them) and you still have to take into account read operations.

That being said, the above is just talking about theoretical throughouput and the effective balance. On practice, I think that 32 ROPs are more than enough for the kind of performance we can expect from Cayman and putting 64 would be a waste of die area for little or no gain (something I could see Nvidia doing** but not AMD). 48 would be ideal I guess, but I don't think AMD is willing to use odd numbers, or they would have done it in the past, with crippled 256 bit parts instead of making them 128 bit...

** This is another story, but the reason Nvidia "wastes" die area on 384 bit / 48 ROPs is because they are critical in the proffesional Quadro/Tesla cards, not because it poses any dramatical improvement or necessity on the desktop cards.
Posted on Reply
#19
Tatty_One
Senior Moderator
Thats pretty much what I was getting at without wanting to get too technical, I just hate all this speculation, lets all vote for no leaks of partial info until the day the cards hit retail lol. As I understand it, more games for example become TMU constrained than they ever do through ROP count in the real world, I dont know what the answers will be for the 6XXX series, but cynical old me thinks that a 256/32 will be the norm, I might be wrong though.

PS: You quoted my deleted post lol, you will see I say the rop count is the same) I was answering 2 different threads at the same time and messed on up..... I am too old to multi task these days!
Posted on Reply
#20
jasper1605
Wile E said:
Maybe AMD will hire something other than monkeys to code their drivers and installers, then maybe I'll stop screaming "ATI DRIVERS SUCKS!" all the time. They even suck on a clean install.

This is the last AMD card I will have until they put out some decent drivers. The last good one was 10.4a. The last good one before that? 8.10

The hardware is great, software is garbage.
I've not once had a driver issue except on 10.2 I think where all of my speakers would randomly reconfigure on the HDMI sound (my fronts went to the right side, my rears moved front, and my sides disappeared lol)
Posted on Reply
#21
cadaveca
My name is Dave
jasper1605 said:
I've not once had a driver issue except on 10.2 I think where all of my speakers would randomly reconfigure on the HDMI sound (my fronts went to the right side, my rears moved front, and my sides disappeared lol)
Just because you dpn't have any issues, doesn't mean that it's impossible for anyone to have issues.

For example, I know that 90% of my issues are either related to Crossfire, Eyefinity, or both. According to your system specs, you have neither, so would probably never see any of the issues I have.

And because of these issues, I will be focusing entirely on how the 6-series behaves under similar conditions.

And this is important...specifically when dealing with Eyefinity...AMD has lauded how they chose a hardware solution for Multi-monitor...yet, handing cursor off from one monitor to the next, often corrupts the cursor.

The cursor issue has been around since day one, and AMD has said that they fixed it, it's a known issues, etc...with a driver. I'm not too sure that a driver can really fix a hardware problem, but AMD seems pretty confident, even though it's been a year without any real fix.

Until AMD starts being honest about issues like this(need i mentopn my cards overheat due to the fan not spinning up correctly, due to the driver?), and there are some real legitimate claims to AMD's drivers steadly declining in quality.

Better yet, guess how I can avoid the cursor corruption? Two ways...either use a single monitor...or not use the DisplayPort connector...

Granted, maybe I just got some bad cards. I'll be mailing yet another one away for RMA later today, and hopefully that might sort it...time will tell.
Posted on Reply
#22
TheMailMan78
Big Member
cadaveca said:
Just because you dpn't have any issues, doesn't mean that it's impossible for anyone to have issues.

For example, I know that 90% of my issues are either related to Crossfire, Eyefinity, or both. According to your system specs, you have neither, so would probably never see any of the issues I have.

And because of these issues, I will be focusing entirely on how the 6-series behaves under similar conditions.

And this is important...specifically when dealing with Eyefinity...AMD has lauded how they chose a hardware solution for Multi-monitor...yet, handing cursor off from one monitor to the next, often corrupts the cursor.

The cursor issue has been around since day one, and AMD has said that they fixed it, it's a known issues, etc...with a driver. I'm not too sure that a driver can really fix a hardware problem, but AMD seems pretty confident, even though it's been a year without any real fix.

Until AMD starts being honest about issues like this(need i mentopn my cards overheat due to the fan not spinning up correctly, due to the driver?), and there are some real legitimate claims to AMD's drivers steadly declining in quality.

Better yet, guess how I can avoid the cursor corruption? Two ways...either use a single monitor...or not use the DisplayPort connector...

Granted, maybe I just got some bad cards. I'll be mailing yet another one away for RMA later today, and hopefully that might sort it...time will tell.
Its just you have bad cards. I ran crossfire with 4850s for a very long time without issue.
Posted on Reply
#23
wahdangun
cheezburger said:
do you honestly believe a high end card will only feature 32rop and 256bit bus while have ridiculous number of shader? this is no longer r670 to r770 transition that you can add up 2.5x shader to boost performance. that will not be the case this time. that means more shader don't mean huge boot in performance. under the same rops/bus configuration a balance GPU design will out perform a GPU that's steroid with more shader ALU. like when 4830 compete with 4870 it shows 4830 has more efficient than 4870. all they need to do is enhance the ALU performance rather than make cheaper low complex shader but take more space and number to fill up the performance.


the rumor of 640ALU with 32 rops and narrow 256bit bus will just make it sound stupid if everything double up except rops/bus since the original r600 design is already unbalanced. if they haven't learn from what happened on r770 then they are pretty much hopeless...which i doubt amd are smart company if they done such non profit plan.

this is the fact that adding rops/bus are more profitable than adding ALU number



what is most profitable if you can't shrink the die size because of put too many ALU on it

hard fact, a 480:96:64 with 512bit will make a 640:128:32, 256bit like shit in term of die space/power consumption/performance.
are you afraid to bet? lets see who are the winner,
Posted on Reply
#24
yogurt_21
Tatty_One said:
What you (and Dalelaroy)are saying makes sense and I am not arguing against the logic, the point is that the memory bus and ROP count are not the only factors determining the performance. Cypress is a good example, the 5850 and 5870 have the same memory bus and the same ROP count (32) to determine the performance segment differences one is clocked higher, it has a greater number of SP's AND more texture units as well as having (reference) faster memory. Now if that architecture is significantly changed and the relationships between each process within the architecture changes it might be that what is considered the "norm" or the limitation now ceases to be in the future, but again that is speculation.

Additionally your comparision therefore between "Barts" and "Caymen" is little more than the comparison between the 5850 and the 5870 surely, less bus size and therefore ROP count? The typical performance differences within the market often can be attained (lets say 15% between 2 models) without having to increase bus size and/or ROP count as Cypress has shown.

Although this does not deal with any limitations between bus width and ROP count that we have mentioned, it does explain very well how segments with the same bus sizes and ROP count can differ a fair bit in performance through other means, I know the link is from semi accurate but this piece is not about speculation but actually makes comparisions with actual hardware and its architecture, if you scroll down to the chart about the 9600 and 9800 and read until the end of the page, it is quite interesting.....

http://www.semiaccurate.com/2010/09/20/northern-islands-barts/
well 1 5850 vs 5870 yet you used it as a reason why the 6770 and 6870 would have the same number of rop's. If you're going to use the cypress you have to incorporate juniper as a comparison for barts to caymen, not cypress pro vs cypress xt. again were talking mid range to highend not lower highend to higher highend.

so the gap has to be larger between the two to make sense in pricing and market positioning.


second overclock a 5850 to 5870's clocks and it'll bench just a hair lower. overclock a 5850 past a 5870 and it'll bench higher. so while shaders do help, there's plenty of them on all modern gpu's. This is exactly why far more 5850's sold than 5870s, the prformance was similar but the prices were not.

plus with the swapout from 4 simple + 1 complex to 4 moderately complex we're likly going to see more frames per shader out of the 6k series. So if we're talking the same rop's and more shaders it's unlikely that caymen would be that much better than barts. after all the chart shows barts at 1280 medium complexity shaders that should be a stark contrast with the 320 complex and 1280 simple on cypress xt.

if you take a look at 5770 vs 5830 where both have 16 rop's, clocks are close with the exception of memory clock and the memory bit is different, but the main difference is 800 shaders vs 1120 shaders (40% more) the difference averages to 13% in W1z's reviews. Now while I feel 256bit vs 128 bit accounts for at least a couple of those frames It's more than easy enough to make up that amount with overclocking.

so if caymen is only increasing shaders by 50% and tmu's while keeping the same rop's, the performance won't be as scalable as the 5770 to 5870 and we'll have a 6770 capable of taking sales away from the 6870 not just in price/performance but performance in general.

imo it would be a bad bad move when they have the chance to repeat the success of the 5xxx series.
Posted on Reply
#25
cadaveca
My name is Dave
TheMailMan78 said:
Its just you have bad cards. I ran crossfire with 4850s for a very long time without issue.
Not like you'd know, running a single card.:laugh: I had few problems too, with 4850, 4870, or 4890...I actually kinda miss those cards...:cry: Alas, they don't support Eyefinity.

Those cards serve as the basis for how bad my current cards actually are...4-series shows AMD can do better. Wonderful gen for AMD, that one...effective, and CHEAP. On the other hand, they also serve as the basis for my interest in 6-series..I hope it's another 4-series.
Posted on Reply
Add your own comment