I think they could.jacozz said:Dave.
So, correct me if I'm wrong, AMD chose to insure all end users the same performance, although theoretically they could very well tune it in a similar way as Nvidia has done with current technology?
So... If I'm unlucky to get a leaky 680-chip, I'll get worse performance, compared to the probably handpicked cards the review sites got?High end boards can have a large power delta from chip to chip variation
That much, eh? Thanks for sharing. Makes perfect sense from a consistency perspective (and enthusiasts will overclock/tweak their systems anyway), if not for maximum stock benchmarking performance on review cards.Cayman could have a variation of 90W or more from one chip to another.
Dave said:
So... If I'm unlucky to get a leaky 680-chip, I'll get worse performance, compared to the probably handpicked cards the review sites got?
Dave.
So, correct me if I'm wrong, AMD chose to insure all end users the same performance, although theoretically they could very well tune it in a similar way as Nvidia has done with current technology?
I think they could.
The question is: do you stick to a set clock specification and let the customers play with overclocking, or do you overclock dynamically without the customer having to do anything himself (and still with some kind of guard band that allows some additional, limited, overclock.) I think the latter is more appealing for most users, and for Nvidia for that matter, but that's just a matter of opinion.
That's really orthogonal to the implementation method. Dave, you say your method is deterministic. I assume that you have a shitload of idle/activity counters in your design that are fed into a weighed sum to estimate, with fairly decent accuracy, the instantaneous power for different sections? I can see who this has advantages over measuring power at the regulators. I'm not sure it makes a major difference for a user. As always, it's not what you have but what you do with it. Marketing it only as a fail-safe mechanism against burning up your GPU (that's always how I looked at it at least) is not the kind of feature that make my heart and games go faster, even if I appreciate the details behind it.
The issues is that, unless there is some way of figuring ASIC to ASIC speed variation, this implementation of Boost isn't overclocking. "Overclocking" is allowing the end user to take the chip variation margin within a Bin/SKU and play with it; Boost still needs to guarantee that all the chips actually run at that maximum boost state performance.The question is: do you stick to a set clock specification and let the customers play with overclocking, or do you overclock dynamically without the customer having to do anything himself (and still with some kind of guard band that allows some additional, limited, overclock.) I think the latter is more appealing for most users, and for Nvidia for that matter, but that's just a matter of opinion.
That's really orthogonal to the implementation method. Dave, you say your method is deterministic. I assume that you have a shitload of idle/activity counters in your design that are fed into a weighed sum to estimate, with fairly decent accuracy, the instantaneous power for different sections? I can see who this has advantages over measuring power at the regulators. I'm not sure it makes a major difference for a user. As always, it's not what you have but what you do with it. Marketing it only as a fail-safe mechanism against burning up your GPU (that's always how I looked at it at least) is not the kind of feature that make my heart and games go faster, even if I appreciate the details behind it.
So... If I'm unlucky to get a leaky 680-chip, I'll get worse performance, compared to the probably handpicked cards the review sites got?
Current implementation of PowerTune has per-MHz of clock control. In higher end chips the power is somewhat static leakage dominated, though, so on high power apps (Furmark) the reaction can be quite severe. If you are using an app that is close the the limits you can see more fine grained clock variation.
I see what you did thereIt was an active decision on our part to take these variables out of the equation on the current high end products.
Bear in mind that you are also subject to the sampling frequency of the application you're using to measure clocks. I've no clue how or when GPU-z takes clock samples.
Edit Also, Furmark is an interesting one to look at if you are watching the clock traces. Because the "furry doughnut" is rotating you can see higher clocks when it is on its side and lower clocks when it it fully facing because it is rendering more fur here.
Isn't that something that drivers already know anyway?Dave Baumann said:The issues is that, unless there is some way of figuring ASIC to ASIC speed variation, this implementation of Boost isn't overclocking.
Agreed, it does since you don't have to size for the very worst power case.It has always been marketed (in the enthusiast segement) as something that is enabling faster application performance.
Understood.It was an active decision on our part to take these variables out of the equation on the current high end products.
Why? Nothing I have seen changes the decision to be deterministic or not on the current products. On the contrary in fact.I'm guessing that this decision with be under some scrutiny right now.
Bingo.Nothing sucks more than buying the same product as someone else but due to random roll of the die (pun intended) he may have paid the same amount of money for a crappier performing card than his buddy.