Not true, there are millions of different colours and therefore aspects to rendering in colour.
AMD: R9xx Speculation
- Thread starter Lukfi
- Start date
Not true, there are millions of different colours and therefore aspects to rendering in colour.
It was driving me nuts too, thanks Thatdude90210.
If one moves the hue, color, etc sliders to anything other than default you get the pink tint.
That's not what saves area, there is no such thing as differential gddr5 vs. single ended gddr5.
GDDR5 uses differential signaling for the clocks only , single ended for everything else.
(I don't understand why so many people find this so hard to comprehend)
The size reduction is in the off chip signal drivers not needing to be so large because of the reduced memory frequency target.
And I think you need to explain better why you think Bart is large for it specifications, because if you just take into account the reduction in SIMDS and smaller mem PHYs it should still have been over 280mm^2. If the remainder of the size reduction came from loss of fp64 then fp64 support would have to be over 25% of a simd. Bart seems small to me.
Mintmaster
Veteran
You're not posing a very good question. Large compared to what? Juniper? You should be comparing to the 256-bit Cypress card. The shader engines are less than half the total area, so have 70% of the engines would only get you down to 85% of Cypress' die size. Instead, Barts is much smaller than that.
brain_stew have a slipstreamed driver here and in the same post there is a registry setting you can check if it doesn't work:
http://forum.beyond3d.com/showpost.php?p=1485754&postcount=54
You find it under AA in the 3D section of CCC:
@Dave Baumann: Any chance of releasing the capture tool, so we can make full screen shots of MLAA?
Jawed
Legend
I guess the years of presentations on the subject of tessellation (including adaptive terrain tessellation) that AMD has done don't count? Including doing tessellation on DX9 hardware using R2VB?
So what's Civ 5?
Hmm, apparently I'm feeding a troll.
Jawed
Legend
You mean like Froblins?
http://developer.amd.com/samples/demos/pages/froblins.aspx
See the adaptive terrain tessellation section of the tech video. Running on D3D10.1 hardware. Seems AMD's problem is they've been doing it so long people have forgotten
Seems AMD's problem is they've been doing it so long people have forgotten
No, only people with an agenda....
Jawed
Legend
What's that? Something to do with wide gamut monitors?
Could it be possible, that Barts ~255mm2 are not the pad-limit for a ~4.2GBps 256-Bit GPU?
Anandtech said that AMD used Redwoods MC (~104mm2): http://www.anandtech.com/show/3987/...renewing-competition-in-the-midrange-market/2
If 32nm would be available, Barts might be ~200mm2 still featuring a 256-Bit GDDR5 MC?
Anandtech said that AMD used Redwoods MC (~104mm2): http://www.anandtech.com/show/3987/...renewing-competition-in-the-midrange-market/2
If 32nm would be available, Barts might be ~200mm2 still featuring a 256-Bit GDDR5 MC?
Looks like a stretch to me. Shouldn't it be a bit smaller at 32nm? Also I think typically I/O shrinks quite badly but I don't know the specifics from the specific 40nm/32nm process.
Also don't forget perimeter doesn't actually grow that much for 104->255mm² - if the chips were square (which they aren't but I can't find the numbers now) perimeter would only increase from ~40mm to ~64mm.
Though I have no idea if Barts is pad limited or not... The non-square die could indicate it is but there could well be other reasons for that.
edit: just realized that non-square die doesn't really increase perimeter a whole lot. If you really want more perimeter you need go to rather extreme non-square dimensions. Even something like 4:1 length/width only gets you about 25% more perimeter compared to a square die (I think that's about the ratio of silverthorne but certainly neither Juniper nor Barts is anywhere close that making perimeter maybe 2% larger than what it would be with a square die). So there goes that theory...
Last edited by a moderator:
Why would a video card support Ethernet over HDMI?
Jawed
Legend
Assuming that the GDDR5 physical I/O is ~40mm², all other I/O is 15mm² and the corners are another 2mm², for 0.64 scaling with 32nm I get a total chip size of 184mm².
To get a perimeter of about 57mm (not all I/O consumes 1mm depth at edge of die, but it's close enough) would require a chip that's about 10x18.4mm. Thing is the perimeter is quite sensitive to dimensions here. e.g. if the perimeter needed to be 54mm, then the chip could be 13x14.2mm. So there's quite a significant error factor derived from the perimeter required by I/O.
On the other hand, it doesn't seem impossible for Barts's spec to be achieved on 32nm. It wouldn't be a tragedy, I guess, to add a couple of cores, I suppose, if it was pad-limited.
To get a perimeter of about 57mm (not all I/O consumes 1mm depth at edge of die, but it's close enough) would require a chip that's about 10x18.4mm. Thing is the perimeter is quite sensitive to dimensions here. e.g. if the perimeter needed to be 54mm, then the chip could be 13x14.2mm. So there's quite a significant error factor derived from the perimeter required by I/O.
On the other hand, it doesn't seem impossible for Barts's spec to be achieved on 32nm. It wouldn't be a tragedy, I guess, to add a couple of cores, I suppose, if it was pad-limited.
Yep Barts supports HDMI 1.4a and thus ethernet over hdmi(no idea how this would work with a video card though). Dont know about the audio return channel
Its part of the HDMI 1.4 spec
What kind of rigged power consumption charts have PCper in their review? They're only that shows how HD6870 consumes 19W more!! than HD5850 and HD6850 consumes only 17W less than HD6870 (in other benches it's more like 30W less), only 40w less than GTX460 (most of others go down to 65W less) and EQUAL To GTX460 768M (while most has at least 12W or up even to 22W less CoD-heXus).
Similar review findings on direct competition comparison could be found [H]ardocp & HWcanucks so how could only PCper have such bad performing HD6800 cards?
ofc when they come in abundance So that many ROPs are just ther for SIX 2560x1600 DP1.1 outputs compliancy sake?
I know that SPs doesnt account for large area but the last pic we had was RV770 and since that SPs become DX11 compatible and more threaded making it bigger (according to R800 series prelaunch). So according to Jawed then SPs were ~41% as repeated here. So now as long we're know there were twice as much SPs in Cypress than in RV770 and being DX11 they're probably took significantly more than 2:3 ratio i'd go more for 2:3 ratio in Cypress and MC (as I/O) accordingly doesnt scale too well 55nm-40nm but it's improved over RV770 to Cypress so it might be even bigger. Also anand article claims 50% MC reduction by replacing "Cypress one MC" and using "Redwood alike MC" instead.
So irc RV770 MC was ~45mm2 reduce that in 40nm to ~40mm2 but all improvements undertook make them let's say ~50mm2 and 0.5x50mm2 is ~25mm2 reduction
334mm2 (cypress) x0.6(1600SPs) x0.3 (1-1120SP:1600SP ratio) ~60mm2 reduction
So only SPs and MC would take ~85mm2 reduction in die size ~250mm2
But there's also missing CFlink dont believe that was too large maybe 2mm2 and no DP support and that should slim SPs and frontend somewhat ~10mm2. Or it's just artificial/market disable?!
What's the last Cat10.x you used? Just install previously working Cat and everything should revert to normal settings before this issue. Hope it's not some software bug that broke down the card.
Similar review findings on direct competition comparison could be found [H]ardocp & HWcanucks so how could only PCper have such bad performing HD6800 cards?
ofc when they come in abundance
So that many ROPs are just ther for SIX 2560x1600 DP1.1 outputs compliancy sake?I know that SPs doesnt account for large area but the last pic we had was RV770 and since that SPs become DX11 compatible and more threaded making it bigger (according to R800 series prelaunch). So according to Jawed then SPs were ~41% as repeated here. So now as long we're know there were twice as much SPs in Cypress than in RV770 and being DX11 they're probably took significantly more than 2:3 ratio i'd go more for 2:3 ratio in Cypress and MC (as I/O) accordingly doesnt scale too well 55nm-40nm but it's improved over RV770 to Cypress so it might be even bigger. Also anand article claims 50% MC reduction by replacing "Cypress one MC" and using "Redwood alike MC" instead.
So irc RV770 MC was ~45mm2 reduce that in 40nm to ~40mm2 but all improvements undertook make them let's say ~50mm2 and 0.5x50mm2 is ~25mm2 reduction
334mm2 (cypress) x0.6(1600SPs) x0.3 (1-1120SP:1600SP ratio) ~60mm2 reduction
So only SPs and MC would take ~85mm2 reduction in die size ~250mm2
But there's also missing CFlink dont believe that was too large maybe 2mm2 and no DP support and that should slim SPs and frontend somewhat ~10mm2. Or it's just artificial/market disable?!
What's the last Cat10.x you used? Just install previously working Cat and everything should revert to normal settings before this issue. Hope it's not some software bug that broke down the card.
Over the base stuff HDMI is an optional spec, i.e. you only have to support one element of a particular revision to point out that you are that revision (though on packaging and product listing you have to call out what parts of the spec you actually support). HDMI1.4a is also a revision that specifically relates to the frame packing methods used to support 3D Stereoscopic content that does not require a transmitter / reciever speeds higher than most current devices are, where the other stereo modes in the HDMI1.4 spec do.
Similar threads
