- Em medições em um monitor de 500 Hz, do clique até a mudança de brilho na tela, mesmo aplicando X11, VRR e dxvk-low-latency, a latência ponta a ponta mediana ficou apenas 0,72 ms menor que no Wayland padrão
- O Wayland nativo foi 0,14~0,22 ms mais lento que o X11, enquanto o XWayland adicionou até 3,13 ms em relação ao Wayland nativo, criando uma diferença muito maior
- A taxa de atualização variável (VRR) reduziu a latência em 0,26~0,45 ms em todas as comparações e também estreitou a amplitude da distribuição p5~p95 de 2,6~3,0 ms para 2,1~2,2 ms
- O dxvk-low-latency reduziu 0,10~0,29 ms com limite de frames e 0,84 ms sem limite, mas neste último caso manteve o uso da GPU em 95~97%, em vez de 100%, enquanto o FPS caiu de 715 para 670
- Os resultados vêm de condições ideais, com FPS estável e gargalo de CPU, e de uma combinação específica de hardware e software; em jogo real, a redução de jitter do VRR e a contenção da fila de renderização pelo frame pacer podem produzir diferenças maiores que a mediana
Por que verificar diretamente as dicas de otimização
- No gaming em Linux, há inúmeras dicas de otimização, como usar X11 em vez de Wayland, desativar composição, usar forks do DXVK otimizados para latência, schedulers de kernel para jogos, aplicar gamescope, gamemode e variáveis de ambiente
- Em FPS competitivos, baixa latência, tempos de frame consistentes e FPS alto são importantes, mas é difícil saber se uma mudança de configuração é uma melhoria real, placebo ou até contraproducente
- O hardware do dispositivo de medição, o gabinete, o firmware, o código de análise e os dados brutos estão publicados no repositório click2photon no GitHub
Dispositivo que mede do clique até a mudança na tela
- O dispositivo é preso ao monitor e gera um clique de mouse via USB; então mede o tempo até que um sensor óptico detecte uma mudança na tela, medindo a latência ponta a ponta do sistema
- O projeto inicial tomou como referência o esquemático do OSLTT disponível na época, e durante a finalização também integrou ideias do m2p-latency e do Open-Source-LDAT
- A construção exigiu microcontrolador, soldagem, firmware Arduino, tempo de integração, amplificador de transimpedância, KiCad e projeto do gabinete
- Um Adafruit QT Py RP2040 funciona como mouse USB HID com polling de 1.000 Hz e gera os cliques
- Logo após enviar o clique, coleta amostras do fotodiodo a cada cerca de 24 µs
- A cada clique, envia 12.000 amostras ao host por conexão serial, registradas em CSV
- A ferramenta no host calcula a linha de base por clique e procura a primeira amostra que se desvia da linha de base acima de um certo nível
- Como o tempo de coleta das 12.000 amostras é fixo, é possível calcular o tempo entre o envio do clique e a mudança de brilho na tela
Configurações de tela e renderização comparadas
- X11 e Wayland nativo foram comparados para confrontar a percepção de que o Wayland parece mais lento com resultados medidos
- Foi comparado o uso ou não da taxa de atualização variável (VRR), incluindo G-Sync e FreeSync
- Foi medida a diferença entre dxvk-low-latency e o DXVK padrão
- O frame pacer desse fork foi integrado ao pacote oficial
proton-cachyos, e é ativado com PROTON_DXVK_LOWLATENCY=1
- Dois casos com FPS sem limite foram adicionados para verificar se o frame pacer absorve variações de tempo de frame e evita o acúmulo na fila de renderização
- Na cena estática do jogo não houve variação de tempo de frame, e o teste também estava em condição de gargalo de CPU, portanto não reflete totalmente uma sessão real de jogo
- Em sessões reais, o tempo de frame pode variar conforme situações internas do jogo ou uso de recursos por outros processos
- Os testes em Wayland foram executados, por padrão, em Wayland nativo usando
PROTON_ENABLE_WAYLAND=1; para comparação, também foram medidos dois casos de XWayland com VRR desligado
Hardware e software de teste
- Durante os testes, apenas um monitor ficou conectado, com a seguinte configuração de hardware
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- Dois módulos DDR4 de 3.200 MHz e 8 GB
- MSI MAG 272QP QD-OLED X50, 2560×1440, 500 Hz
- MSI B450 GAMING PRO CARBON AC
- A pilha de software foi composta por CachyOS, Kernel 7.1.3-2-cachyos, driver NVIDIA 610.43.03-1, KDE Plasma 6.7.2-1.1 e xorg-server 21.1.24-1.1
- Foram usados
proton-cachyos-native 1:11.0.20260602-3 e dxvk 3.0
- O scheduler de kernel padrão do CachyOS foi mantido
Configurações de display e DXVK
- A taxa de atualização do sistema foi definida em 500 Hz
- No X11, o modo flip e o VRR foram ativados com
nvidia-settings, e mudar o VRR exige reinicialização
- No Wayland, o VRR é ativado pelas configurações do KDE e não exige reinicialização
- No Wayland, o modo flip ou scanout direto não é configurado manualmente pelo usuário; o compositor decide a cada frame
- Na aba Effects do KWin Debug Console,
showcompositing foi ativado
- Se apenas o jogo aparece em tela cheia e totalmente em foco, sem uma borda vermelha nas laterais, isso foi interpretado como modo flip
- Foi usado um
dxvk.conf otimizado para cada condição de comparação
- Com VRR desativado:
dxgi.maxFrameRate = 500
- Com VRR ativado e dxvk-low-latency desativado:
dxgi.maxFrameRate = 497
- Ao ativar VRR junto com dxvk-low-latency, as configurações abaixo foram usadas para frame pacing VRR de baixa latência em 500 Hz
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
d3d11.cachedDynamicResources = "c" foi aplicado a todas as configurações
Ambiente de jogo e procedimento de medições repetidas
- O jogo de teste foi Diabotical, um jogo DirectX 11 executado com Heroic e Proton
- Foram usados resolução nativa e escala de renderização de 100%; o Vsync foi desligado, e as demais configurações gráficas foram reduzidas ao máximo possível
- Um comando oculto que esconde a UI por um instante foi vinculado ao clique esquerdo com
/bind mouse_left testlatency, e um HUD que mostra um grande retângulo branco foi configurado para aumentar a diferença de brilho no clique
- Cada teste foi repetido nas mesmas condições
- Softwares desnecessários foram fechados, e um servidor local no mesmo modo e mapa foi iniciado
- Em uma posição definida, o mouse foi alinhado a uma marca específica do cenário
- O processo de dar 100 cliques por cerca de 2 minutos foi repetido 3 vezes no total
- Uma cena estática foi mantida, sem bots, outros jogadores, movimento ou reinício de rodada
- Nenhum outro processo significativo foi deixado em execução, e a posição do dispositivo de medição também foi mantida fixa em todos os testes
Faixa de latência de todas as configurações
- Todos os casos com limite de frames mantiveram o FPS-alvo de forma estável, e o jogo permaneceu com gargalo de CPU durante todo o teste
- Todos os casos apresentaram distribuições em forma de sino, sem grandes outliers, e a amplitude entre p5 e p95 ficou em cerca de 2~3 ms
- As medianas das 8 configurações principais ficaram em 4,21~4,93 ms, com uma diferença total de apenas 0,72 ms
- O XWayland teve mediana até 3,13 ms maior que a configuração correspondente em Wayland nativo, registrando 8,06 ms contra 4,93 ms
- Nos casos sem limite de FPS, o dxvk-low-latency reduziu a latência em 0,84 ms em relação ao DXVK padrão
Pequena diferença entre X11 e Wayland nativo
- O X11 foi mais rápido em todas as configurações, mas a diferença foi pequena, de 0,14~0,22 ms, insuficiente para explicar a percepção de que o Wayland é muito mais lento
- low-latency e VRR ativados: X11 4,21 ms, Wayland 4,38 ms, diferença +0,17 ms
- apenas low-latency ativado: X11 4,64 ms, Wayland 4,83 ms, diferença +0,19 ms
- apenas VRR ativado: X11 4,45 ms, Wayland 4,67 ms, diferença +0,22 ms
- ambos desativados: X11 4,79 ms, Wayland 4,93 ms, diferença +0,14 ms
- O formato da distribuição de latência dos dois servidores de display também foi muito parecido
Efeito do VRR na latência e na distribuição
- O VRR teve o maior impacto entre os itens comparados, ficando 0,26~0,45 ms mais rápido em todas as combinações
- X11 com low-latency: redução de 4,64 ms para 4,21 ms, queda de 0,43 ms
- X11 com DXVK padrão: redução de 4,79 ms para 4,45 ms, queda de 0,34 ms
- Wayland com low-latency: redução de 4,83 ms para 4,38 ms, queda de 0,45 ms
- Wayland com DXVK padrão: redução de 4,93 ms para 4,67 ms, queda de 0,26 ms
- A amplitude entre p95 e p5 foi de 2,1~2,2 ms com VRR, contra 2,6~3,0 ms sem VRR, estreitando também a distribuição de latência
- Com VRR, os frames são escaneados assim que ficam prontos, sem esperar pelo próximo slot de scanout, portanto o resultado medido condiz com o modo de funcionamento
Efeito e custo do dxvk-low-latency
- Nos casos com limite de FPS, o dxvk-low-latency reduziu a latência em todas as combinações, com melhoria média de 0,20 ms, semelhante à diferença média de 0,18 ms entre X11 e Wayland
- X11 com VRR: redução de 4,45 ms para 4,21 ms, queda de 0,24 ms
- X11 com VRR desativado: redução de 4,79 ms para 4,64 ms, queda de 0,15 ms
- Wayland com VRR: redução de 4,67 ms para 4,38 ms, queda de 0,29 ms
- Wayland com VRR desativado: redução de 4,93 ms para 4,83 ms, queda de 0,10 ms
- Na condição sem limite de FPS, o pacer teve um efeito maior ao impedir o acúmulo na fila de renderização e aliviar o frame pacing irregular
- Manteve a GPU próxima de um gargalo de GPU, sem saturá-la completamente
- O uso da GPU foi de 100% no DXVK padrão e 95~97% no dxvk-low-latency
- A latência caiu de 5,27 ms para 4,43 ms, redução de 0,84 ms
- O FPS caiu 45 FPS, de 715 para 670
Grande latência adicionada pelo XWayland
- Ao desligar
Enable Wine-Wayland (Experimental) no Heroic Launcher ou PROTON_ENABLE_WAYLAND=1, o jogo roda por meio do XWayland
- O XWayland adiciona uma latência grande em relação ao Wayland nativo
- low-latency ativado: aumento de 4,83 ms para 5,95 ms, alta de 1,12 ms
- DXVK padrão: aumento de 4,93 ms para 8,06 ms, alta de 3,13 ms
- Os 3,13 ms adicionados no DXVK padrão foram maiores que a soma de todos os outros efeitos medidos, e não resultaram de alguns frames ruins elevando a média; toda a distribuição se deslocou
- Adicionar dxvk-low-latency no XWayland reduziu a latência em 2,11 ms, a maior melhoria entre todos os casos
Escopo dos resultados e interpretação prática
- Os resultados se limitam a condições ideais de FPS limitado estável, gargalo de CPU e cena estática, além de uma pilha específica de hardware e software
- Em outros ambientes, os valores absolutos de latência podem variar, mas os aumentos e reduções ocorridos em cada configuração devem, em geral, ser transferíveis
- Em monitores com taxa de atualização mais baixa, é possível que os ganhos de VRR e de pacers de baixa latência sejam maiores
- O X11 foi 0,14~0,22 ms mais rápido que o Wayland, mas o trabalho de otimização no KWin pode reduzir essa diferença, e outros compositores Wayland talvez já sejam melhores
- Excluindo o XWayland, aplicar X11, VRR e dxvk-low-latency juntos deixa a mediana 0,72 ms menor que a configuração Wayland padrão
- Embora a diferença na mediana seja pequena, o VRR reduz o jitter de latência, e o dxvk-low-latency mitiga quedas de tempo de frame e situações de gargalo de GPU que ocorrem em jogos reais
Projetos semelhantes de medição de latência de entrada
1 comentários
Opiniões no Hacker News
O bom do Linux é que esse tipo de análise não só é possível, como de fato leva a melhorias no ecossistema. Os resultados chegam aos desenvolvedores de software gráfico e aos mantenedores de pacotes das distribuições, mas na Microsoft parece difícil esperar esse caminho de melhoria.
Usei Windows por muito tempo e recentemente migrei para Linux; gostei do fato de o KDE Plasma ser mais ágil que o Windows 11 e de eu poder mexer diretamente para melhorar algo quando surge um problema. Se você não usa um desktop Linux há algum tempo, recomendo o Bazzite, um Fedora ajustado para jogos; mesmo sem jogar, ele permite montar rapidamente um desktop bem acabado.
No passado, era possível mudar as coisas como quisesse com um único arquivo de configuração intuitivo, mas agora, mesmo com inúmeras camadas de abstração para temas, ícones, modo claro e modo escuro, é difícil encontrar uma combinação que funcione direito. No modo claro aparecem letras cinzas sobre cinza-claro; no modo escuro, letras pretas sobre fundo preto; e, dependendo de temas como o Adwaita, até visualizadores de PDF às vezes não conseguem definir corretamente as cores do texto e do fundo.
Nenhum tema deixa a barra de rolagem suficientemente visível, nem diferencia claramente janelas ativas e inativas por cor. Até o Windows 3.11 fazia melhor as barras de rolagem, a indicação de janela ativa e a personalização de cores; ou seja, era melhor antes de tudo ser projetado em excesso.
A Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) e a Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) também coletam esse tipo de dado de usuários que consentiram. Ainda assim, ambas usam adesão opcional, então pode não haver muitos dados de gamers mais entusiasmados.
Há muitas mudanças incrementais, mas elas frequentemente ficam presas por anos em ótimos locais. Ainda assim, é bom poder inspecionar o funcionamento interno com relativa facilidade, e não entendo muito bem por que Windows e macOS necessariamente precisam ser de código fechado.
Há alguns meses troquei meu sistema operacional principal e ambiente de jogos para o Fedora, e no geral ele pareceu mais ágil que o Windows; essa medição esclareceu parte da minha curiosidade sobre latência de entrada em jogos.
Recentemente migrei para o Hyprland baseado em Wayland e estou curioso para ver como os resultados mudariam; como ele ficou popular, seria bom testarem de novo. Também considerei o Gamescope, mas ouvi dizer que ele não funciona bem com Nvidia, e só agora soube que existem kernels otimizados para jogos. Em jogos de luta competitivos, a latência de entrada é muito importante, então gostaria de ouvir relatos de quem fez otimizações parecidas.
Para jogos, gostei do Hyprland, e foi mais fácil ajustar detalhes como taxa de atualização variável e tearing via Gamescope do que quando eu usava o AwesomeWM no X11. A configuração em Lua também pareceu familiar para quem vinha do AwesomeWM.
Como o teste foi feito com um display de 500 Hz, muitos problemas que apareceriam em telas de baixa taxa de atualização podem ter ficado mascarados. O fato de o XWayland ter sido 3 ms mais lento pode significar que, nessa taxa de atualização, ele ficou um frame atrás.
Testar a 120 Hz ou 60 Hz permitiria distinguir mais claramente entre pequenas diferenças no momento de execução e o efeito maior de atrasar um frame inteiro.
No fim do texto, o autor estranha o motivo de o Wayland ser considerado lento, mas os resultados do XWayland podem ser justamente esse motivo. É possível que usuários que executaram jogos X11 no Wayland tenham sentido uma latência significativa. Seria bom ver mais medições reais desse tipo em várias áreas
O autor eliminou bem outras variáveis de confusão, mas usuários que sentiram o Wayland como lento podem ter começado em um ambiente não otimizado e, ao mudar para uma configuração de baixa latência, também corrigido configurações relacionadas
Diferente do X11, em que o Xorg é praticamente a implementação de referência padrão em todos os lugares e se comporta de forma parecida, as diferenças entre implementações do Wayland são grandes. Pode haver compositores mais lentos que o KDE Plasma usado no teste, e também mais rápidos
A própria expressão latência de entrada do Wayland mistura camadas diferentes, como
suavidade de animação HTTP. O que este texto mediu foram Xorg, KWin e XWayland; outras implementações de X11 e Wayland podem ter características diferentesAinda assim, a latência adicional do XWayland é grande o bastante para ser suspeita demais para ser tratada como um simples custo extra
Em especial, o Emacs em modo pgtk funciona muito melhor no GNOME, mas no KWin usa bastante CPU ao rolar a tela e, em alta resolução, às vezes também apresenta um pouco de atraso
Também seria muito interessante ver como ficaria uma comparação com Windows no mesmo hardware
No Breaka Club, estão lidando diretamente com esse problema ensinando programação a crianças com um Overcooked 2! modificado
Como é difícil instalar mods nos dispositivos da escola, eles transmitem por WebRTC uma versão de OC2 com o mod incluído, e as crianças jogam no Mobile Safari do iPad usando um gamepad na tela. As instâncias do jogo rodam em contêineres Docker no Kubernetes/k3s sobre hardware Nvidia antigo e passam pela internet e pela rede da escola, então eles usam recursos como a transferência sem cópia com NVEnc e DMABuf para reduzir a latência total
Atualmente estão sofrendo com o custo adicional de entrada do XWayland, mas como a entrada vem de dispositivos virtuais, o comportamento pode ser diferente. A otimização de ponta a ponta é difícil, e o desempenho atual é aceitável. Vídeo de programação com OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
As licenças de OC2 são compradas em quantidade limitada; quando um pod é iniciado, recebe uma delas, e se todas estiverem em uso as crianças jogam outro jogo
Ao usar renderização composta no X11, se uma janela em tela cheia envia ao compositor uma dica de desredirecionamento, a composição pode ser interrompida enquanto nenhum outro elemento é desenhado na tela, e a swapchain do aplicativo pode ser enviada diretamente para a tela. Na prática, é o método ideal, então é difícil melhorar mais
Se outra janela aparecer por cima ou o compositor decidir que não pode fazer o envio direto, surge uma etapa intermediária que compõe a janela do aplicativo e outros elementos em um buffer temporário. Se o desredirecionamento for quebrado — por exemplo, com a janela criada 1 pixel menor que a altura da tela — ou se XWayland for usado, a latência pode aumentar; isso é uma limitação fundamental, e problemas semelhantes surgem também em compositores de outros sistemas operacionais
O Wayland também vem explorando planos de exibição (display planes), em que o hardware da GPU compõe várias camadas diretamente. Com isso, o jogo pode renderizar na taxa máxima de quadros por segundo, enquanto a janela acima é desenhada em um plano separado e composta sem efeitos colaterais, mas não sei se isso está sendo usado em ambientes de produção reais
Enquanto os consoles tendem a mirar uma taxa fixa de quadros por segundo na saída e resolução dinâmica, no PC a tendência é fixar a resolução e deixar dinâmicos os quadros por segundo e os intervalos de tempo entre frames. Fico curioso sobre como isso se relaciona com a latência
Especialmente em jogos competitivos, mira-se em taxas de quadros por segundo muito acima da taxa de atualização do display, mas não tenho certeza se isso é uma vantagem real ou uma ilusão
O ponto central não é ver mais frames, mas ver informações mais recentes. Também seria possível atrasar o início da renderização para que ela termine logo antes da atualização da tela, mas errar esse momento por pouco causa engasgos severos, e o tempo de execução da GPU e o tempo de submissão de trabalho pela CPU não são determinísticos
Idealmente, bastaria começar a renderização logo antes da atualização da tela sem criar frames desnecessários, mas, se você perder o prazo, ocorre um engasgo muito incômodo
Um novo frame pode entrar no meio do processo de varredura da tela, causando tearing, mas abaixo da linha de divisão serão exibidos pixels mais recentes. Assim, vários frames renderizados podem se misturar em um único frame do monitor e, embora não seja tão bom quanto um display de alta taxa de atualização com taxa variável, isso reduz a latência. Em jogos nos quais o movimento é menos importante, é comum usar VSync para alinhar os frames à taxa de atualização e eliminar o tearing
Alguns jogos ajustam a resolução em tempo real para manter uma taxa de quadros por segundo constante. No PC, sempre foi possível rodar jogos mesmo em máquinas muito abaixo da especificação-alvo original, taxas de quadros baixas eram culturalmente mais aceitas, e, se a pessoa não gostasse, podia fazer upgrade. Consoles não têm caminho de upgrade e precisam ser otimizados para uma configuração única, então reduzir a resolução antes que o desempenho caia demais fazia mais sentido
Isso não quer dizer que o jogo receba mais eventos de entrada, mas que ele pode processá-los e refleti-los mais rápido. Não é ilusão, embora os retornos decrescentes sejam grandes, e o efeito varie conforme fila de frames, VSync, taxa de atualização variável, gargalo de CPU ou GPU, e a estrutura dos loops de entrada e simulação
O autor tenta descartar a ilusão desde o início, mas me pergunto se latência, no fim, não é algo avaliado pela sensação e pela experiência de uso. Pessoalmente, como você percebe é o teste final; mesmo que dados sejam úteis para diagnosticar e corrigir latência real, acho que na maior parte de UI/UX não há problema em depender de preferência e percepção
Combinar isso com avaliações menos técnicas, como notas por estrelas, também pode impedir que testes e coleta de dados fiquem presos demais à metodologia. Em testes montados com muita precisão, podem ficar de fora condições de queda de desempenho que aparecem com frequência no uso cotidiano de determinado ambiente