Esittelyssä uusi testi: peräkkäisten ruutujen latenssi

Olemme viime aikoina kehitelleet uutta testiä, jolla on tarkoitus mitata peräkkäisten ruutujen latenssin aiheuttamia vaikutuksia pelikokemukseen. Aiemmin testauksessa käytetty mittari on ollut yleisesti pelkkä keskimääräinen ruudunpäivitysnopeus, mutta nykyään tiedetään, että se ei välttämättä kerro kaikkea pelikokemuksen laadusta.

Niin kutsuttu micro-stuttering eli pieni nykiminen muutoin sulavassa grafiikan päivityksessä lienee tuttu ilmiö jo suurelle osalle lukijoista. Niin kutsuttu mikronykiminen liitetään yleensä useamman kortin SLI- tai CrossFire-kokoonpanoihin. Sen syynä on pienet erot peräkkäisten ruutujen ilmestymisnopeudessa, mikä johtaa vaikutelmaan pelin nykimisestä, vaikka keskimääräinen ruudunpäivitysnopeus olisikin riittävän nopeaa. Esimerkiksi kaksi eri kokoonpanoa voivat tuottaa erilaisen pelikokemuksen, jos ruudunpäivitysnopeus on toisella koneella vähemmän säännöllinen, vaikka molempien keskimääräinen päivitysnopeus olisi 24 ruutua sekunnissa.

Alla olevassa taulukossa Järjestelmä A:n ruudunpäivitysnopeus pysyy tasaisena, kun taas Järjestelmä B:n päivitysnopeus on epätasaista.



Taulukossa näkyy, että järjestelmä B:llä on neljä ruutua, joiden renderöimisessä kestää merkittävästi muita ruutuja pidempään, kun järjestelmä A valmistaa ruutuja tasaisella tahdilla. Ongelma on helppo havaita, kun katsotaan ohi keskimääräisen ruudunpäivityksen ja tarkastellaan yksittäisiä ruutuja sekunnin ajalla. Tarpeeksi suuren datamäärän saamiseksi grafiikkatestejä ajetaan kuitenkin yleensä huomattavasti pidemmän aikaa kuin sekunnin verran (yleensä vähintään minuutin), mikä tarkoittaa jo vähintään 3600 datapistettä 60 FPS nopeudella. Dataa siis kertyy paljon enemmän, kuin mitä taulukkoon on järkevää mahduttaa. Tietysti voisimme tarkastella vain osaa testidatasta, mutta miten sitten valitaan koko testin kannalta relevantti osa datasta? Ongelmaan ei valitettavasti ole olemassa yksinkertaista ratkaisua.

Me pyrimme aina esittämään datan yksinkertaisessa ja tarkoituksenmukaisessa muodossa, joka on helppo ymmärtää ja analysoida. Emme siis paneudu yksittäisten ruutujen nopeuteen, vaan tarkastelemme erotusta niissä ajoissa, joka kuluu peräkkäisten ruutujen esittämiseen.

Pelkkä ruutujen renderöintiin kulunut aika ei vielä kerro kaikkea suorituskyvystä, sillä suurilla ruudunpäivitysnopeuksilla myös renderöintiin kulunut aika on lyhyempi ja hitaammilla aikaa kuluu luonnollisesti enemmän. Me pyrimmekin tarkastelemaan viivettä, joka esiintyy peräkkäisten ruutujen välillä. Tässä testissä käyttöön otettu taulukko esittää keskimääräiset erotukset peräkkäisten ruutujen välillä, erotukset 75 prosentissa tapauksista ja erotukset 95 prosentissa. Prosenttiosuudet paljastavat kokonaistilanteen isomman datamäärän sisällöstä. 75 prosentin osuus kertoo pisimmät viiveet, joita esiintyy 75 prosentissa tapauksista ja sama pätee 95 prosentin taulukkoon.

Alla oleva taulukko kuvastaa miten uusi esitysmuoto voisi tuoda esiin erot Järjestelmä A:n ja Järjestelmä B:n tapauksessa.



Taulukko ei siis kuvasta varsinaisia ruudunpäivitysnopeuksia eikä se ole edes sen tarkoituskaan, sillä jatkamme ruudunpäivitysnopeuksien mittausta entiseen tapaan. Uudella testillä on kuitenkin tarkoitus saada parempi kokonaiskuva suorituskyvystä.

Uuden mittauksen tavoitteena on saada vertailtavaa dataa eri prosessoreiden välillä, jotta havaitsemme ongelmat eri mallien välisissä latenssieroissa. Kuten seuraavien sivujen tuloksista huomataan, myös eri peleillä on keskimäärin erilaiset latenssit.