Scott i think you have really started something. What road you have been paving has finally opened and people are wanting to go down it. I wanted to bring up the ABT as it complements your work for sure. i had not seen this
http://techreport.com/blog/24133/as-the ... 9ae8#metal before i posted above. So i read the beyond3d thread from Andrew Lauritzen and found it very interesting for sure. There is a lot of information there and so much more to consider. The game simulation clock times really can be a tremendous factor to the hitching or jitter. This happens because of the long frame time spikes. This is variable that really makes things a little crazy. If we had tools that simply measured the output in frames displayed, they could be way more consistent than the jitters we see on the screen. I dont think there is any reasonable way to take in all these variables and represent them meaningfully. But the techniques you are using are a fantastic way to show a lack of smoothness. Especially since the game engines use frame times as an input that triggers clock/adjustments of simulation/ whatever we may call it......
So the skyrim video shows the character walking steady but then its like the animation skipped steps and was ahead then behind. There could be an effect of the game simulation clock/timing which was disrupted by those spikes in frame times but instead of staying high they quickly go to shorter/small frame times. The engine would adjust again to try to play catch up. The frame times you measure from DX calls is used as an input for important synchronization of game simulation. Those long frame times are more than just a chance of a hitch but also could trigger a chain reaction. I think this is a very important thing to consider. From Andrew's post, i take it is his suggestion that more than likely most of the actual output frames to the lcd are pretty much steady and the most of the hitching is is a result of disruption to the games internal simulation clocks its trying to keep synced. It has bound to have some weight to it.
This bring me back to my point in all this. From this thread i take it that you have some reasons to believe that your frame time methods with fraps are lacking when it comes to representing hitching in multGPU setups. From this i conclude you probably have tested multiGPUs and have not seen the trends you expected. That frame times were not representing your experience? Is this correct?
Is it possible that the frame time spikes you measure have a major impact on fluidity by throwing the games simulation clocks out of whack but multGPU setups have other issues that these tools are not capable of measuring? Like perhaps the actual output to the monitor is not steady or something else is occurring as the task are being manipulated and split long after the DX calls occur and the frame time data is collect. Maybe fraps isnt capable of seeing this because it is not monitoring it at all?