CPU blocking potentially causing slow update rates

[russell-taylor]

In an attempt to minimize missed deadlines during ATW rendering, fences were put in the code to make sure that rendering was complete on the graphics card before handing a buffer to be presented.

Although this decreases the second-pass rendering latency and avoids tearing, it also causes the CPU to block for what may be a large fraction of the potential rendering time. This can make non-ATW causes have slower rendering rates because it reduces the potential overlap between CPU operation one frame with GPU operation in the previous frame.

In the non-ATW case, we should consider not blocking the CPU at the fence but just letting the vsync in the GPU handle swapping buffers at the right time.

[russell-taylor]

We're going to need to put in our own thread to wait for rendering completion, since we're in charge of presentation in DirectMode.

[russell-taylor]

Timing tests on this code revealed that the maxMsBeforeVsync parameter seemed to be causing the problems in large-poly examples, rather than the wait. Leaving this issue open until we've checked large-shader codes as well.