Multi-thread collaboration in real-time rendering: Practice

The no-Wait multi-thread collaboration mechanism proposed in "multi-thread collaboration under real-time rendering" can be applied to real-time rendering. This is because there is a correlation between each frame and the next frame in real-time rendering. Imagine that there is an infinite and Fast Rendering device, resulting in an infinite frame rate and an infinitely small dt. In this case, the motion changes of objects in the scene are infinitely close to those of frames n + 1 at frame n, we can accumulate the changes of frame n and frame n + 1 in an approximate way, and present them at frame n + 1 at a time, while frame n is good.

The following DEMO is based on the above point of view: first, the DEMO shows two spin cubes. The spin angle of the cubes in the lower left corner is calculated by the main thread, and that of the cubes in the lower right corner is calculated by the auxiliary thread. Second, to simulate complex operations, each time a spin conversion matrix is computed, the secondary thread Sleep for one hundred milliseconds. Finally, the two cubes are submitted to the GPU for rendering by the main thread.

In a single thread or multi-thread Wait Mechanism, the frame speed of the entire program will be only 10 FPS, because the Application phase of the program takes 100 milliseconds, becoming a bottleneck.

Under the multi-thread collaboration mechanism without waiting, the program will still run at the highest performance. In the GHz quad-core CPU and HD6970 environment, the rendering frame speed of the main thread can reach FPS. The complex operations of the auxiliary thread lead to a sense of lag in the lower right corner of the cube rotation, but it does not affect the frame rate and response speed of the program, the auxiliary thread is still running at its highest efficiency (this example is just a simple Sleep, it takes 100 milliseconds to simulate its full load), but the calculation workload of the auxiliary thread is indeed huge, it takes 100 milliseconds to update the result.

In summary, the secondary thread does not drag down the main thread and does not affect the rendering speed without waiting for multi-thread collaboration. In addition, as long as the appropriate workload is assigned to the secondary thread, in this way, the auxiliary thread will always be at the highest load, and the system performance will be the highest, giving full play to the advantages of multithreading. How to determine the workload assigned to the auxiliary thread? I think it is best to control the workload within twice the time dt is rendered by the main thread, because even if the auxiliary thread consumes 2 dt, the scene elements of the auxiliary thread are still updated at half the frame speed of the program, and the gap is not too large. If the frame speed exceeds 2 DT, the comparison will be strong unless these elements are far away from the viewpoint.

Here, we assume that the cube of the auxiliary thread is far away from the viewpoint and there are only a dozen or even several pixels on the screen, it doesn't matter whether the cubes are rendered at a speed of FPS or at a speed of 10 FPS, because users don't care about the rendering speed of these pixels, as long as these pixels look dynamic.

Finally, the DEMO is written using the DirectX9 interface. The program framework uses the Framework Code in Introduction to 3D Game Programming with DirectX 9.0c-A Shader Approach.

DEMO Source: http://files.cnblogs.com/rickerliang/CubeDemo_ProgrammablePipeline_with_FreeRun.zip

DEMO Video address: http://v.youku.com/v_show/id_xmjyxndk2ndu2.html.