3D Scene Rendering optimization (1)

3D Scene Rendering optimization (1)

-- How to conduct effective performance evaluation

For any 3D application, pursuing realistic scenes is a complete goal. The result is to make our scenarios more complex and more precise, this will inevitably bring a huge load to the graphics hardware so that the frame rate cannot be set in real time. Therefore, rendering optimization is essential. Before rendering optimization, We need to systematically evaluate the application performance, identify bottlenecks, and remedy the problem. For 3D applications, the performance is greatly affected, and the bottle diameter varies with different hardware configurations. Therefore, to evaluate the performance of an application, we not only need to have a deep understanding of the principle of the entire rendering pipeline, but also use some evaluation tools to make our work easier.

We know that the speed of the rendering pipeline is determined by the slowest stage. Therefore, to evaluate a 3D application, we must first analyze whether the bottleneck affecting rendering performance is on the CPU or GPU end, therefore, we absolutely optimize the object. Because the current graphics acceleration hardware is powerful, this bottle diameter often appears on the CPU end. We can obtain this information through some tools, such as NVIDIA nvperfhud. In the evaluation options, we can check the CPU and GPU busy degree. When the CPU busy degree is 100% and the GPU is not yet, we know that the performance bottleneck is on the CPU end, we must perform operations on the CPU side and try to "Feed" the GPU as much as possible to shift some troublesome computing values to the GPU, such as hardware skeleton skin. When the GPU side is a bottleneck, it indicates that the GPU is overloaded, probably because there is too much rendering fill, that is, the number of polygon is too large (the current powerful GPU makes this rare case.

There are two bottlenecks on the CPU. One is complicated AI computing or inefficient code, and the other is poor rendering batch processing or resource management. In the first case, we can use tools such as vturn to sort the call time of all functions in the application from large to small, so that we can easily know the problem. In the second case, we can also use nvperfhud to check the number of DP entries per frame to see if there are too many batches (a specific conversion formula) and the number of texture memory, whether excessive memory is consumed. Using these tools, we can basically locate application bottlenecks. Compile an embedded profiler function in the application to facilitate the evaluation. In addition, the script program like Lua allows us to debug during running and improve the evaluation efficiency.