3 ms·

Some questions from someone who is obsessed with getting 0 frames of latency: >the one frame of added latency with compositing and game VSync does not apply to

Some questions from someone who is obsessed with getting 0 frames of latency: >the one frame of added latency with compositing and game VSync does not apply to Wayland I thought that on X with vsync disabled, a fullscreen game will write pixels directly to the framebuffer on the gpu without going through the x server / compositor, so there will be 0 frames of delay. Is this correct? > application contents can be put directly on the screen with the display hardware (which is called “direct scanout”. You may have heard the X related term “unredirection” used for the same thing, too). So on a machine running wayland, direct scanout would let a fullscreen game render directly to the framebuffer without any copying, compositing, color remapping, etc etc, just pure pixel data to the screen without any intermediate steps, right? And how does this work exactly, like does the program that wants to render to the screen have to call some API function to explicitly opt-in to direct scanout? Because most games, even the ones designed to run on linux, are not aware of wayland. Also I think something is up with the final measurements, on his 120hz monitor one frame of latency is about 8 ms, but the lowest he ever measured was 19ms so it seems like something is adding at least a frame of latency.

heftig 5y ago
These days, a game has at least double buffering. This means one frame is currently displayed on the monitor (front buffer) and one frame is being drawn by the game (back buffer). In a classic "fullscreen game" situation, whenever a back buffer is finished, the game would configure the GPU's CRTC (the hardware that generates the data stream that goes to the monitor) to read from this back buffer instead. This turns the back buffer into the current front buffer and releases the old front buffer to act as the next back buffer ("page flipping"). When this happens without any synchronization with the monitor, the buffer can be changed in the middle of the frame, causing the characteristic tearing. With VSync, the game delays the swap until the monitor is between frames. With Wayland, the game swaps buffers with the compositor instead. Direct scanout means that the compositor will configure the CRTC to read from the game's front buffer. So this is really similar to the "classic" situation, except it involves a bit of inter-process communication. Otherwise, the compositor has its own set of front and back buffer, and the game's front buffer is copied (composited) into the compositor's back buffer first. So we have another buffer swap that has to be done, and this is what causes the composition lag. Whether direct scanout happens or not is transparent to the game, which does not need to care. Wayland enforces VSync by default, though there's a protocol being designed (`zwp_tearing_control_unstable_v1`) so a game can request asynchronous flipping.
- voldacar 5y ago
  Thanks for the explantion. I already knew about double buffering but for whatever reason my brain didn't make the connection.
- vbphprubyjsgo 5y ago
  Ah, so this "direct scanout" is just an improvement over the previous bad situation, not an improvement over the classic double buffered vsync, and not a way to give the application the choice to write directly to the active framebuffer during scanout.
vbphprubyjsgo 5y ago
Games typically go through OpenGL (or D3D), and don't touch the framebuffer. 2D games will be going through SDL or something else. All of these involve transformations in internal memory far before writing out to the framebuffer. Edit: the other guy explained it better. > but the lowest he ever measured was 19ms so it seems like something is adding at least a frame of latency. Ignoring the fact that the measurements are completely bogus and nothing can be taken from them, the monitor itself will add lag, and the mouse/keyboard will add between 0 and 8ms lag per frame if it's a standard 125Hz polling rate configuration.

heftig 5y ago

These days, a game has at least double buffering. This means one frame is currently displayed on the monitor (front buffer) and one frame is being drawn by the game (back buffer). In a classic "fullscreen game" situation, whenever a back buffer is finished, the game would configure the GPU's CRTC (the hardware that generates the data stream that goes to the monitor) to read from this back buffer instead. This turns the back buffer into the current front buffer and releases the old front buffer to act as the next back buffer ("page flipping"). When this happens without any synchronization with the monitor, the buffer can be changed in the middle of the frame, causing the characteristic tearing. With VSync, the game delays the swap until the monitor is between frames. With Wayland, the game swaps buffers with the compositor instead. Direct scanout means that the compositor will configure the CRTC to read from the game's front buffer. So this is really similar to the "classic" situation, except it involves a bit of inter-process communication. Otherwise, the compositor has its own set of front and back buffer, and the game's front buffer is copied (composited) into the compositor's back buffer first. So we have another buffer swap that has to be done, and this is what causes the composition lag. Whether direct scanout happens or not is transparent to the game, which does not need to care. Wayland enforces VSync by default, though there's a protocol being designed (`zwp_tearing_control_unstable_v1`) so a game can request asynchronous flipping.

voldacar 5y ago
Thanks for the explantion. I already knew about double buffering but for whatever reason my brain didn't make the connection.
vbphprubyjsgo 5y ago
Ah, so this "direct scanout" is just an improvement over the previous bad situation, not an improvement over the classic double buffered vsync, and not a way to give the application the choice to write directly to the active framebuffer during scanout.

vbphprubyjsgo 5y ago

Games typically go through OpenGL (or D3D), and don't touch the framebuffer. 2D games will be going through SDL or something else. All of these involve transformations in internal memory far before writing out to the framebuffer. Edit: the other guy explained it better. > but the lowest he ever measured was 19ms so it seems like something is adding at least a frame of latency. Ignoring the fact that the measurements are completely bogus and nothing can be taken from them, the monitor itself will add lag, and the mouse/keyboard will add between 0 and 8ms lag per frame if it's a standard 125Hz polling rate configuration.