Yup.
Yup, that too. But I'm used to crossbars that are WAY bigger than whatever they use in GPUs. Look at it this way: in a GPU, how much area do you think just the crossbar with just 4 units (because that's what we're talking about in the case) takes compared to the rest of the area?
All he said there was that the first spin came back dead because of an issue with the process parameter of TSMC not matching real life. For a standard cell based design, that's saying: a characterization issue. It does not point to a fundamental architecture problem.
Yes. But that has nothing to do with fundamental architecture issues: a fundamental architecture is not something you can fix with even a limited base spin, IMO.
Detecting basic gpu/mem frequencies should be quite trivial even if the particular chip isn't supported, no?
No, just what the first tab shows as "default" & "current" clocks (with obviously mistakenly hotclock too)Maybe it's just me but you don't see what the Sensors tab shows.
There is always the possibility that a new generation introduces new power states or swizzles the old ones, so I would not take anything for granted that is displayed by a utility not supporting a particular architecture.
I don't expect Kepler to be any different than Fermi in consumer vs. professional segmentation -- half-rate setup w/o tessellation and full-rate with tessellation enabled.
It's not going to change the opinion of the gullible, but 3 years after the fact, it's probably time to settle this once and for all: the issue in GF100-A01 was in a back-end bus that fed the memory controllers. It was not even in the general xbar that interconnects the usual agents. There was a custom designed cell that with a timing violation that was not picked up during characterization.
Is that the main reason for the low memory clocks in Fermi?
The slide with the "adaptive VSync" appears a bit strange. What they describe is basically vsync'd triple buffering. Otherwise tearing would appear also below the refresh rate.
