No apologies required, I know CF has serious problems and that out of the box it is horrible. The fact that you have a 120Hz monitor may be the issue, so I don't dispute that you had problems. I dispute your assertion that it is unfixable by the simple reason that you (or I ) can't possibly assume to talk for everyone.
Fair enough, and indeed we cannot speak for others. 120Hz may indeed be the issue because, since moving to it, I find myself quite unsatisfied gaming at 60Hz/fps on other people's screens/systems. Some people claim not to notice a difference between 60 and 120Hz/fps gaming, but I am
not one of them. Perhaps this change has made me particularly intolerant of imperfect smoothness...I'm not sure.
However, before wrapping this up I would like to ask this: you say that we can look at a near-smooth frame metering graph produced via FRAPS and can conclude that the same smoothness should be displayed on an FCAT graph based on the same sample of gameplay. What's your thinking here? I'm not saying that you're wrong. It's just that
Anandtech's coverage from their interview with AMD seemed pretty clear that:
FRAPS is at the very start of the rendering pipeline; its before the GPU, its before the drivers, its even before Direct3D and the context queue. As such FRAPS can tell you all about what goes into the rendering pipeline, but FRAPS cannot tell you what comes out of the rendering pipeline.
So to use FRAPS in this method as a way of measuring frame intervals is problematic. Considering in particular that the application can only pass off a new frame when the context queue is ready for it, what FRAPS is actually measuring is the very start of the rendering pipeline, which not unlike a true pipe is limited by what comes after it. If the pipeline is backed up for whatever reason (context queue, drivers, etc), then FRAPS is essentially reporting on what the pipeline is doing, and not the frame interval on the final displayed frames. Simply put, FRAPS cannot tell you the frame interval at the end of the pipeline, it can only infer it from what its seeing.
That whole quotation is interesting in itself, but particularly the part in
bold. FRAPS measures the part of the pipeline that comes before the GPU and the drivers, and yet it is well-accepted that microstutter from Crossfire/SLI stems directly from
AFR. AFR is, as I understand it, something handled near-entirely by the GPU. So how can we conclude that FRAPS graphs from a Crossfire setup - even smooth graphs - tell us with confidence that the graph would also be 'smooth' if done using FCAT? This is one major reason why I remain(ed) skeptical of your graphs as evidence that vsync fixed microstutter.
Or am I missing something?