AMD: R9xx Speculation

He is looking at the aspect which happens to be important: what is fraking annoying to his eyeballs. I mean hell why not render in black and white... after all color is only "a single aspect."

Not true, there are millions of different colours and therefore aspects to rendering in colour.
 
If one moves the hue, color, etc sliders to anything other than default you get the pink tint.


It's not about that but about monitor temperature calibration.

How this could've gone unnoticed between the beta and release is beyond me though.
 
not supporting differential gddr5 signaling makes him 50% smaller than one in Cypress/Juniper).
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.
 
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
because of this?

gddr5_05_ram-roadmapkgqt.jpg
 
Large considering only 70% instead 80% active engines
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.
 
Maybe AMD should do something for gamers - and i mean not to lower the default iq of their filtering.

That's the reason why ubisoft asked nVidia for help. You can watch how nVidia and Ubisoft implemented it in HAWX 2 (start at 40:00): http://nvidia.fullviewmedia.com/gtc2010/0920-a5-2157.html
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?

AMD is not interessted in bringing Tessellation to the pc community right now.
So what's Civ 5?

They don't even have a own Tessellation-Showcase. After CES i think they stopped immediately their support for it. None of the latest DX11 games (which have all Tessellation) are on their DX11 games slide.
The only thing i'm seeing from them it's their pr who is complaining that Tessellation is not anymore the "biggest hardware feature of DX11".
Hmm, apparently I'm feeding a troll.
 
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?
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:
Was checking the hdmi wikipedia page, specifically 1.4 specs. Does barts support ethernet over hdmi or the audio return channel?
 
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.
 
Was checking the hdmi wikipedia page, specifically 1.4 specs. Does barts support ethernet over hdmi or the audio return channel?

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

Why would a video card support Ethernet over HDMI?

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?

The ROPS also have more idle time on Barts.

ofc when they come in abundance :D So that many ROPs are just ther for SIX 2560x1600 DP1.1 outputs compliancy sake?

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.

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?!

I use a hardware colorimeter with my monitor. I already target 6500K color temperature, Catalyst 10.10 completely screws that up. The official WHQL 10.10s are already up on the server, you just have to change the link.

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.
 
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
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.
 
Back
Top