Eu ouvi muitas pessoas trabalhando em VR falarem sobre corridas de scanline e isso deveria ajudar a melhorar a latência do movimento para o fóton. No entanto, não está claro para mim como isso pode ser feito com o OpenGL. Alguém poderia explicar como funciona a corrida scanline e como ela pode ser implementada nas GPUs modernas.
Respostas:
Quando sua GPU exibe um novo quadro na tela, transfere a imagem pelo cabo HDMI (ou qualquer outro tipo) em um processo chamado "digitalização". Os pixels são enviados em ordem linear, geralmente da esquerda para a direita e de cima para baixo. O processo é cronometrado, de modo que leva a maior parte da duração de um intervalo de atualização para fazer isso. Por exemplo, a 60Hz, um quadro é de ~ 17 ms. Cada digitalização levará provavelmente em torno de 15 a 16 ms, com 1-2 ms de vblank no meio (os valores exatos variam de acordo com o modo de exibição e vídeo).
Tradicionalmente, a renderização é com buffer duplo, o que significa que existem dois buffers armazenados na memória da GPU: um que está sendo verificado no momento ("buffer frontal") e outro que está sendo processado no ("buffer de fundo"). Cada quadro, os dois são trocados. A GPU nunca processa no mesmo buffer que está sendo digitalizado, o que impede artefatos devido à possibilidade de ver partes de um quadro incompleto. No entanto, um efeito colateral disso é o aumento da latência, pois cada quadro pode permanecer no buffer por vários ms antes de começar a ser digitalizado.
A RV é muito sensível à latência, portanto, isso não é desejável. Uma abordagem alternativa é renderizar diretamente para o buffer frontal, mas decifre o tempo com muito cuidado para que você renderize cada linha da imagem logo antes da digitalização chegar lá. Isso é chamado de "corrida na linha de varredura" ou "corrida na viga" (a "viga" remontando aos dias anteriores da CRT). Isso exige mais ou menos a renderização da imagem na ordem da linha de digitalização, ou seja, na mesma ordem em que os pixels são digitalizados. Ele não precisa literalmente ser renderizado uma linha de cada vez - pode ser renderizado em faixas finas com alguns pixels de altura, mas precisa ser feito em ordem, pois você não pode voltar e editar os pixels que já foram foi digitalizado.
Existem muitas desvantagens nessa abordagem; possui requisitos de desempenho muito rigorosos, precisa ser cronometrado com muito cuidado contra o vsync, e isso complica bastante o processo de renderização. Mas, em princípio, ele pode economizar milissegundos de sua latência, motivo pelo qual as pessoas de VR estão interessadas nela.
O melhor é que podemos finalmente prever a precisão da varredura exata da linha de varredura sem acesso a uma consulta por linha de varredura:
https://www.youtube.com/watch?v=OZ7Loh830Ec
Eu inventei as fórmulas exatas de microssegundos como um deslocamento VSYNC, para prever a posição de uma linha de lágrima. As linhas de lágrima durante o VSYNC OFF são sempre exatas, portanto você pode desviá-las da visibilidade durante a "renderização de buffer frontal simulada" no nível da faixa, através da troca repetida de buffer do VSYNC OFF.
Preste atenção ao tópico do fórum - há algum código de código aberto sendo continuamente adicionado - https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Se for de interesse, o Dreamcast tinha um modo de renderização "acelerando o feixe", pelo qual era capaz de dedicar uma fração de memória relativamente pequena aos pixels do buffer de quadros (por exemplo, 64 linhas de varredura) e renderizava linhas de 32 por vez, sincronizadas com a atualização de exibição. No entanto, isso foi usado apenas para economizar memória. Duvido que alguém estivesse gerando geometria "modificada" para as últimas partes da tela.