在《实时渲染下的多线程协作》一文中提出的无等待多线程协作机制可应用于实时渲染，这是由于实时渲染下，每一帧与下一帧存在相关性。设想一下存在一个无限快速的渲染设备，导致帧速无限大，dt无限小，那么，场景内物体的运动变化在frame n时与frame n+1时无限接近，我们可以近似地把frame n与frame n+1的变化累积起来，一次过地在frame n+1时呈现出来，而frame n我们什么也不错。
以下DEMO就是基于上述观点：首先，DEMO显示两个自旋的六面体，左下角六面体自旋角度由主线程计算，右下角六面体由自旋角度由辅助线程计算；其次，辅助线程为了模拟复杂运算，在每计算一个自旋转换矩阵后，都Sleep一百毫秒；最后，两个六面体均由主线程提交GPU进行渲染。
在单线程或等待机制多线程下，整个程序的帧速将只有10fps，因为程序的Application阶段花费了100毫秒，成为瓶颈。
而在无等待多线程协作机制下，程序仍会以系统最高性能运行，在3.6Ghz四核CPU和HD6970的环境下，主线程的渲染帧速能达到4300fps。辅助线程的复杂运算导致右下角六面体旋转有卡顿感，但并不会影响程序的帧速及响应速度，而且，辅助线程依然以它的最高效率运行着（这个例子只是简单Sleep一下，模拟它的满负荷运算量花费100毫秒），只不过辅助线程的运算量的确很巨大，需要100毫秒才更新一次结果。
总结，无等待多线程协作机制下，辅助线程不会拖累主线程，不会影响渲染速度，而且，只要分配合适的工作量给辅助线程，就能使辅助线程永远处于最高负载，这时系统性能最高，充分发挥多线程优势。如何决定分配给辅助线程的工作量？我认为工作量控制在主线程渲染一帧时间dt的2倍之内最好，因为即使辅助线程耗时2dt，辅助线程所负责的场景元素仍有程序帧速一半的更新速度，落差感不会太大，如果超过2dt，对比就会很强烈，除非这些元素远离视点。
在这里，我们设想一下辅助线程负责的六面体如果远离视点，在屏幕上只有十几个像素甚至只有几个像素，那么，这个六面体无论以1000fps的速度渲染还是以10fps的速度渲染，其实也无关紧要，因为用户并不会去关心这些像素的渲染速度，只要这些像素看起来是动的就行了。
最后说明一下，DEMO是使用DirectX9接口编写，程序框架使用的是《Introduction to 3D Game Programming with DirectX 9.0c—A Shader Approach》里面的框架代码。
DEMO源代码：http://files.cnblogs.com/rickerliang/CubeDemo_ProgrammablePipeline_with_FreeRun.zip
DEMO示例视频地址：http://v.youku.com/v_show/id_XMjYxNDk2NDU2.html。