The following video shows how a display updates itself in 500x slow-motion (filmed with 1000 frames per second):Īdding everything up in a vsynced scenario with a gaming mouse we get: When all pixels have received the command to switch, we still have to wait the pixel response time until the last of them changed there colour – this is the one value the manufactures are willing to tell us: around 5-8 msec (and some gaming monitors are down to 1-2 msec). Now the display can start to update the image, it will take 16.6 msec until it is finished. some special gaming monitors as well as the Oculus Rift), often adding less then 5 msec of latency. Only a few monitors display an image (nearly) as soon as they get it from the GPU (e.g. ![]() TVs might even cache multiple frames to perform 100Hz up-sampling or other post-processes (which is why some TVs have a “gaming” mode which just deactivates these sources of latency). Most monitors wait until a new frame was completely transferred before they start to display it adding another frame of latency. In the worst case we just missed the sync and have to wait for 16.6 msec. If the image would change within this redraw we would see tearing lines, so often the driver wants to sync the display of the new image with the vertical redraw (vsync). When the image is ready to be displayed it can be send to the screen right away but often the driver waits until the monitor is about to draw a new image: The monitor does not switch the whole image at once but redraws it from top to bottom. The application can force the driver not to cache multiple frames with glFinish() in OpenGL or by waiting for the result of a hardware query (e.g. Even worse: The driver might buffer the draw commands of multiple frames to ensure a better utilisation of the hardware and a overall higher framerate (Triple Buffering is one name of such techniques). This way another 16 msec are added to our latency list. It might collect all drawing commands for the whole frame and not start to render anything until all commands are present. The GPU does not render the image right away, it runs in parallel with the CPU code (this is why the draw commands return nearly instantly). In times of multi core CPUs this might be pipelined: One thread is calculating the physics and logic for frame N while another thread is generating rendering commands based on the simulation results of frame N-1. and then generate the rendering commands for the GPU (adding 16.6 msec to our list). In the old times(TM) the game would now simulate the game logic, physics etc. While the game could receive the input from a gaming mouse in around 2 msecs, I measured that a standart mouse adds 12 msecs on average.Īssuming the game is running at 60 Hz, we get nearly 16.6 msec latency if the input occurred right after the game queried the user input and no latency if it occurred right before the input was queried. The input is then processed by the operating system before it is handed to the application. Those only update the input they receive 125 times (normal PC mouse) to 1000 times (“gamer” mouse) per second. Most of the time the input for a computer game comes from a keyboard, mouse or gamepad. Let’s take a look at why this is the case: Sadly, the true latency for most games is more in the range of 100 msec instead of 21.6 msec. ![]() What latency can we expect between a user input and the updated image on the screen? You might thing that because your game runs at 60 frames per second it would take 16.6 msec to send the new image to the display plus the 5 msec the monitor needs to switch the pixels (a number you read on the data sheet). I will first quickly talk about the parts of the system that play a role in adding latency and then show how the total system latency can be measured. This delay, or latency as I will call it from now on, depends on the input devices used, the kind of monitor, the rendering software and driver settings. If the delay gets to high, it can even result in “simulator sickness”, especially in simulations using a head mounted display. The amount of delay between a user input and the change of the systems output is crucial to trick the user to believe to actually be part of the simulated world. To deliver a convincing virtual reality experience it is not enough to ensure a high update rate of the (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |