ATI didn't have
I actually had a pic of the 1600 Gemini in that post but hot-linking etc.
AMD: R9xx Speculation
- Thread starter Lukfi
- Start date
I actually had a pic of the 1600 Gemini in that post but hot-linking etc.
The best i can offer is +97% for GTX480 compared to 5870. But that's z-only in 2560x1600, so probably not achievable in games.
Is there more information to the HD6990 available?
That above is just pure speculation.
And wrong for that matter ...
gamervivek
Regular
From what I can tell ATI/AMD defines their chips by the power use now so perhaps we can assume that the current design rules will apply moving forward as well.
HD x6xx = no PCI-E power adapter. = <75W
HD x7xx = 1 PCI-E 6 pin power adapter = <150W
HD x8xx = 2 PCI-E 6 pin power adapters = <225W
HD x9xx = 1 PCI-E 6 pin, 1 PCI-E 8 pin power adapters. =
A good way to prevent people from taking a lower end SKU and overclocking it to much higher performance is to limit the available power.
there is no such thing as "available power" using a PCIE adapter.
Companies are going to make choices based on the competitive environment, available resources and their long term strategies. They don't have personalities that sway them in any one particular direction.
AMD has to relish the opportunity to increase their ASPs. The "sweet spot" strategy was right for that time since they were still reeling from their last big chip which caused them all sorts of grief. Wouldn't surprise me in the least if they see an opening to attack Nvidia aggressively on the gaming performance front given the power consumption headroom available to them. I suspect ASPs scale up faster than cost and are a bigger profit driver.
"attribute interpolation" has been remove from RV870
But sometime it stole a lot % cycle from ALU, when you pass many attribute from vertex shader.
And I observed 20% cycles lost.
I think AMD should add that enhanced fixed function block for "attribute interpolation"
back on HD6x00.
Hardwire attribute interpolation unit is cheap. (In term of die size)
It's much easier gain performance by bring it back , than add hundreds SP.
But sometime it stole a lot % cycle from ALU, when you pass many attribute from vertex shader.
And I observed 20% cycles lost.
I think AMD should add that enhanced fixed function block for "attribute interpolation"
back on HD6x00.
Hardwire attribute interpolation unit is cheap. (In term of die size)
It's much easier gain performance by bring it back , than add hundreds SP.
Adding attribute interpolation back to the front-end probably isn't an option. Pre-calculating and storing pixel attributes for all the threads in flight doesn't seem like the best way to go about things. Especially when tessellating. They could add interpolation instructions to the shader core ala Nvidia but I'm not sure how that would work on a VLIW. Can different lanes in the VLIW issue instructions of varying latency? I imagine you could decompose a long latency instruction into multiple shorter instructions that could be co-issued alongside the regular ALU ops.
Ok then.
600 series or less < or = 6.25A
700 series < or = 12.5A
800 series < or = 18.75A
900 series < or = 25A
Not gonna happen.
Jawed
Legend
How much slower was the frame rate?
Months ago when I looked at the interpolations being compiled, the compilation quality was awful. Do you have an opinion on the compilation quality for your code?
Bear in mind that fixed function interpolation adds latency to the time it takes to create a hardware thread of fragments. You can't see how long it takes because you can't see the cycle count for the instructions issued to the interpolator.
GPUSA reports the number of fixed function interpolation instructions it executes, per fragment, for GPUs that are older than R600. If your shader is SM3 or older then you should be able to see how many interpolation instructions would execute on the older GPUs.
For some reason AMD did not implement this statistic for R600 onwards.
Fixed function interpolation is also a bottleneck. It's not quite as clear-cut as it appears. I remember a discussion around here where some games were slower than expected on HD5770, and the conclusion was attribute interpolation. But I think there have been games where some games were seen as faster than expected on HD5770 and that was reckoned to be attribute interpolation. Proving the latter is fairly tricky, though.
Jawed
Legend
That's what they did.
IMHO it should work better with VLIW, as I see no reason why they couldn't pack the interpolation instructions with the regular shader code (as long as the interpolants aren't used right from the start ofcourse), helping on the ILP and thereby utilization..
It should work quite well. 1D interpolation requires two ALU slots, 2D interpolation can be done with 2 instructions requiring 2+2 slots. So, in contrast to nvidia (at least the pre-fermi designs but I think they kept that?) this doesn't use the "special" alu unit.
Not sure it really can make HD5770 (don't forget the HD48xx couldn't actually do enough interpolations to feed all units) that much slower but I guess you could always come up with some examples. The performance loss of Cedar vs. rv710 however (at the same clocks) was indeed said to be caused by interpolation "stealing" alu cycles (confirmed by Dave), since with its lower alu/tex ratio it potentially makes twice the difference there.
UniversalTruth
Veteran
We have a very very nice kind of speculation here:
http://semiaccurate.com/forums/showthread.php?p=67549#post67549
http://semiaccurate.com/forums/showpost.php?p=67541&postcount=655
Very nice, indeed. That's what I expect too.
http://semiaccurate.com/forums/showthread.php?p=67549#post67549
http://semiaccurate.com/forums/showpost.php?p=67541&postcount=655
Very nice, indeed. That's what I expect too.
My speculation:
Cayman XT: 1920SP(30 SIMD)/120TMU/32ROP/256bit
Barts XT: 1280SP(20 SIMD)/80TMU/16ROP/256bit
Turks XT: 512SP(8 SIMD)/32TMU/8ROP/128bit
Caicos: 128SP(2 SIMD)/8TMU/4ROP/64bit
I think Turks would be slower than Juniper.If Turks match Juniper's performance,it will require a 6pin connecter,which is highly unlikely for a Redwood replacement,
Cayman XT: 1920SP(30 SIMD)/120TMU/32ROP/256bit
Barts XT: 1280SP(20 SIMD)/80TMU/16ROP/256bit
Turks XT: 512SP(8 SIMD)/32TMU/8ROP/128bit
Caicos: 128SP(2 SIMD)/8TMU/4ROP/64bit
I think Turks would be slower than Juniper.If Turks match Juniper's performance,it will require a 6pin connecter,which is highly unlikely for a Redwood replacement,
IIRC, ATi's RBEs are tied to the memory controller so you wouldn't have two chips with the same memory interface and different number of RBEs as you have listed here with Barts and Cayman.
Rv770 16ROP/256bit
Cypress 32ROP/256bit
If Barts has 32ROP,it would be too big for a mid-range product.
You can't have random ratios like 3:2, but multiples of 2 are possible... 4/8/16/32/64 ROPs per 64/128/256/512bit interface are all possible combinations (in theory, of course, many of them wouldn't be practical)
Similar threads
