|
|
|
|
|
by pistachiopro
1411 days ago
|
|
Games generally don't use copy on write, but they do often explicitly pipeline processing to happen across multiple frames (usually by manually copying the necessary data from sim "owned" memory to render "owned" memory, but varying amounts of double buffering is also used). This was especially true after the transition to multi-core but before the many-core regime of today. Transitioning from a single threaded engine, it was easier to run effectively a single-threaded simulation frame and a single-threaded render frame in parallel than to fully multithread everything. Graphics APIs took a while to support multithreading, as well. These days game programmers have gotten experienced enough to get closer to fully saturating all cores in both the simulation and render steps, so you sometimes no longer see the two full frames of latency there. > 16.6 (GPU is rendering the previous frame, current frame is cached) Not entirely sure what this is about. Maybe some sort of triple buffering is being employed as a way to reduce hitches? If you push the engine really close to the 16 ms limit for each stage of your pipeline, sometimes something out of you control, like the OS deciding to do some heavy background work, will push you over your limit. Without the extra buffer, you will miss your vsync and the user will perceive a very disturbing judder. |
|