Cyberpunk 2077 update 2.x: RT Overdrive, DLSS 3.5, generování snímků a odezva | Kapitola 8
Seznam kapitol
Poslední várka aktualizací pro Cyberpunk přidala kromě obsahu i výrazné vylepšení grafiky s využitím ray tracingu s technologií Ray Reconstruction. Podíváme se, jak je na tom vylepšený Cyberpunk 2077 s výkonem a odezvou a jaký vliv na input lag má, pokud na GeForce zvýšíte výkon s pomocí generování snímků z DLSS.
Cyberpunk 2.02 – nastavení použitá pro měření
Měřil jsem s nejnáročnějším nastavením RT Overdrive. Nastavení jsem nechal v angličtině, protože je paradoxně z anglických názvů technologií na rozdíl od kreativních překladů do češtiny obvykle srozumitelnější, co která položka dělá.
Cyberpunk 2077 je trochu zákeřný z hlediska nastavení DLSS. S globálními profily nastavení totiž nastavuje metody supersamplingu na Auto. Kvalitu DLSS pak mění v závislosti na rozlišení – v 1920 × 1080 je DLSS v režimu Quality, v 2560 × 1440 v režimu Balanced a v 3840 × 2160 v režimu Performance.
Pokud kvalitu supersamplingu změníte ručně, název presetu RT Overdrive se změní na Custom (vlastní). Ještě zákeřnější je, že pokud s tímto nastavením hru ukončíte a znovu restartujete, po spuštění se preset opět změní na RT Overdrive a vyhlazování se přepne zpět na Auto.
To, že Cyberpunk při různých nastaveních vrací po restartu některé změny na globální preset, je zřejmě bug, který se v různých obdobách a nastaveních táhne Cyberpunkem už od uvedení a je potřeba si to při měření výkonu ohlídat.
Cyberpunk 2.1 – nastavení použitá pro měření
Ve verzi 2.1 jsem použil totéž nastavení – tedy globální preset RT Overdrive…
v němž jsem kvůli tomu, abychom se v různých rozlišeních srovnávalo vždy se stejným nastavením DLSS, měnil jeho kvalitu ručně na Quality. Vedle toho jsem ještě zapínal a vypínal Frame Generation, tedy generování mezisnímků. Ve 4K jsem ve FrameView změřil i výsledky s DLSS v režimu Performance, protože s Quality už nebylo hraní kvůli nižší základní snímkové frekvenci komfortní.
Měření odezvy
Na to, jaké hodnoty snímkových frekvencí a odezvy (latence) naměříte pomocí FrameView, se můžete podívat na následujícím grafu. Na první pohled je asi trochu nezvyklý, ale na druhý je snadno pochopitelný. Jde o dva grafy spojené do jednoho. Osa je zhruba v první třetině, nalevo od osy je latence při daném nastavení (oranžová) a napravo snímková frekvence (modrá).
U snímkové frekvence je pak kromě obvyklých průměrných hodnot ještě hodnota 1% minimálních snímkových frekvencí.
Z grafů je hezky vidět, že jak se starším patchem, tak s tím novějším je Cyberpunk bez Reflexu při relativně plynulých snímkových frekvencích kolem 30 fps prakticky nehratelný – zpoždění obrazu za myší bylo přes desetinu sekundy. Když k tomu přidáte horší výbavu v podobě 60Hz monitoru a běžné neherní myši, není oč stát.
Naměřené latence můžeme rovnou srovnat i s tím, co jsem naměřil a napočítal s pomocí kamery ve verzi 2.02. U obrazu na monitoru reagujícího na pohyb myši máme ještě jeden problém – obraz se začíná pohybovat při vykreslení generovaného mezisnímku, ale reálné reakci na pohyb myši odpovídá až pohyb u renderovaného snímku.
Už se zobrazením vygenerovaného snímku začnete vnímat, že se obraz pohybuje (a subjektivně tedy vnímáte, že se obraz začíná pohybovat v reakci na myš), ale opravdu netuším, zda je možné třeba nějak podvědomě vnímat i to, že má pohyb zpoždění o půl snímku.
Sám to nepoznám, ale nedokážu vám říct, podle kterého snímku bude být správnější odezvu počítat. Proto jsem do grafů u (oranžových) datových řad s měřením z kamery dal čas odezvy jak pro první, tak pro druhý vykreslovaný snímek.
Z toho, že máme v grafech obě hodnoty, je ale pěkně vidět, že zpoždění půlsnímku i renderovaného snímku způsobené aktivním framegenem není nijak dramatické vedle toho, jak dlouho samotné hře trvá reakce na pohyb myši.
A taky je vidět, že odezva naměřená dle FrameView nějakým rozdílem daným zpožděním na straně myši a monitoru poměrně věrně kopíruje hodnoty naměřené kamerou.