Miért jó az alacsony latency?

Aki kellően idős ahhoz, hogy még analóg vagy ISDN modemem keresztül használt netes játékokat, az tudja, hogy mennyire bosszantó volt az időnként extrém méreteket öltő késleltetés, vagy más szóval lag: nyomhattuk az egérgombot, mintha nem lenne holnap, mire a képernyőn megjelenő figura elsütötte a rakétavetőt, az ellenfél már nemcsak megkerült minket, de fegyvereinket is elvette. Ezek az idők ma jobbára elmúltak, a modern netkapcsolatoknál ezzel nincs probléma, a kompetitív környezetben használt Ethernetnél pedig még kevésbé okoz ez gondot. Ezért kerülhet előtérbe két másik komponens, amelyből végső soron összeáll a gomb lenyomása és a képernyőn megjelenő történés között eltelt idő: az egyik a kontrollerhez, a másik a grafikus alrendszerhez köthető késleltetés. Az előbbivel egeres tesztjeinkben szoktunk foglalkozni, az utóbbi viszont eddig még nem nagyon került szóba.

Jelentős javulást ígér az AMD (forrás: AMD) [+]

Pedig bizony az operációs rendszer oldalán is keletkezik késleltetés, nem is kicsi. Ebben vastagon benne van az adott grafikus API által biztosított feldolgozási mód, illetve a grafikus meghajtók erre vonatkozó implementációi, kiegészítve az operációs rendszer ide vonatkozó moduljaival. A legnagyobb átok ebből a szempontból az, hogy a jelenlegi grafikai futószalagok minimum két jelenet feldolgozására szabott munkavégzést követelnek meg, vagyis egy jelenetnek legalább kell lennie a parancslistában. Ennek igen prózai oka van: így lehet normálisan etetni a GPU-kat. Ezeket a hardvereket ugyanis masszívan adatpárhuzamos végrehajtásra fejlesztették ki, így kritikus fontosságú, hogy mindig legyen valamilyen munka, amivel dolgozhatnak, ha az egyes feldolgozandó folyamatok éppen az adatok memóriából való betöltésére várnak.

(forrás: NVIDIA) [+]

Az előbbi módszerrel egy GPU vertikális szinkron nélkül akár két jelenet alapján számolt képkockával is feltöltheti a képkockapuffert egy frissítési ciklus alatt. Nagyon gyakorlatias példával leírva az egész úgy néz ki, hogy az első jelenetből a GPU a frissítési ciklus idejének a felében kiszámolja a képkocka felét, de ekkorra már befut egy második jelenet is, amiből a maradék rész születik meg. Végül ez a tört képkocka megjelenik a kijelzőn.

A grafikus meghajtók még ma is többféle módon működnek. Az AMD ragaszkodik az egy szem jelenet parancslistába való betöltéséhez, míg az NVIDIA alapértelmezett módban inkább hárommal dolgozik. Az egész valójában az egyensúly keresése a késleltetés és a teljesítmény között, de itt ne gondoljunk arra, hogy extrém különbségek fognak születni, pusztán arról van szó, hogy a tipikus konfigurációk esetében az AMD megoldása nagyobb eséllyel eredményez alacsonyabb késleltetést, de ennek esetenként teljesítményveszteség lehet az ára. Ezzel szemben az NVIDIA rendszerénél a teljesítményveszteség ritkább lehet, de nagyobbak az esélyei a rosszabb késleltetési értékeknek.

Maga a parancslista megléte azonban mindenképpen késleltetést eredményez. A legjobb eredményt az adná, ha a bemeneti adatokból kiszámolt jelenet alapján a GPU azonnal megkezdené a képszámítást. Ez így nagyon jól hangzik, de nem ilyen egyszerű a történet. Ahhoz ugyanis, hogy ez a modell igazán jól működjön, tökéletesen kell szinkronizálni a jelenet- és képszámítást, ami nem éppen könnyű feladat, részben ezt a szinkronizációt biztosítja maga a parancslista.

Az AMD és az NVIDIA is kidolgozott egy-egy megoldást arra, hogy miképpen lehetne a késleltetést a két jelenet feldolgozására szabott munkavégzéshez képest tovább csökkenteni. Az AMD ezt Radeon Anti-Lagnak, míg az NVIDIA Low Latency Mode-nak hívja. Utóbbi esetben fontos megjegyezni, hogy ennek szimpla bekapcsolása nem elég, mivel az a fentebb említett kétjelenetes modellre állítja a meghajtó működését, a minimális késleltetésű opció az úgynevezett Ultra beállítás.

A támogatott API-k szempontjából az NVIDIA megoldása a DirectX 9-es és 11-es játékokat kezeli, míg az AMD ezek mellett a Vulkan API-ra írt programokat is elfogadja.

Csökkentik a késleltetést, de hogyan?

A technológiai alapok tekintetében az NVIDIA Low Latency Mode-jának Ultra beállítása egy kifejezetten egyszerű ötleten alapszik: egyszerűen nem engedik az új jelenetet a parancslistában pihenni, még egy kicsit sem, hanem azonnal ráerőltetik a GPU-ra. A legfőbb gondot az jelenti, hogy ebből egyáltalán előnyt lehessen kinyerni. Az NVIDIA elsődlegesen azért vette ki régebben a maximum pre-rendered frames opció 0-s beállítását, mert az 1-es paraméterhez képest nem volt ténylegesen érezhető pozitív hatása, miközben számos problémát eredményezhetett. A Microsoft 2012-től nem is írt alá olyan grafikus meghajtókat, amelyek kényszerítik az azonnali jelenetátadást. Ezt még nagyon régen azzal magyarázták, hogy a funkciónak semmi értelme nincs, és potenciálisan olyan feldolgozásbeli gondokat generál, amelyek akadásokhoz vezethetnek.

[+]

A GeForce driver Low Latency Mode-jának Ultra beállítása a technikai működés tekintetében nem különbözik attól, amit anno a 0-s maximum pre-rendered frames eredményezett, de van egy fontos tényező, amiben mégis több: az NVIDIA közvetlenül kezeli azokat a problémákat, amelyek működésbeli hibákat okoznának. A Microsoftnak így már nincs különösebb gondja ezzel, hiszen anno a tiltást azért vezették be, hogy a rossz felhasználói élményt elkerüljék, de ha a lehetséges gondok valamilyen más módon ki vannak szűrve, akkor a redmondiak részéről is rendben van a technika alkalmazása.

Az AMD egy alternatív megközelítést alkalmazott a problémára. Nagyon leegyszerűsítve a Radeon Anti-Lag egy módosított Radeon Chill. Utóbbi egy energiagazdálkodásra kifejlesztett funkció, vagyis a jelenetek átadásának ütemezését a felhasználótól származó bemeneti információkhoz köti. Ha például nincs bemeneti adat, azaz nem mozdul az egér, illetve nincs billentyűlenyomás sem, akkor a jelenetek átadása lelassul, ellenkező esetben pedig gyorsul, viszont az egyenletesség minden esetben megmarad. Nyilván az elvi minimális és elvi maximális képkockasebesség beállítható, tehát a rendszer ennek megfelelően szabályozza majd a kalkulációt.

[+]

A Radeon Anti-Lag az elvi módszert tekintve ugyanabból indul ki, amiből a Chill, vagyis akkor a legalacsonyabb a késleltetés, ha egyszerre csak egy jelenethez tartozó képkocka számítása történik. Az Anti-Lag ugyanakkor nem felhasználó által generált bemeneti adathoz mérten szabályozza a jelenetszámítást, hanem belső méréseket végez, és arra koncentrál, hogy mikor kell átadni a jelenetet a GPU-nak, hogy az abból számolt képkockára vonatkozó késleltetés a lehető legkisebb legyen.

A fentebb leírtak miatt van az is, amiért a Radeon Anti-Lag GPU-limites szituációban működik igazán, mert akkor van lehetőség a jelenetszámítást megfelelően szabályozni. CPU-limit esetén ugye eleve arról van szó, hogy a GPU vár az adatra, tehát nincs nagyon esély arra, hogy a rendszer megtalálja az optimális jelenetátadási pontokat.

Tesztkörnyezet, szoftverek

Tesztünket grafikus kártyák mérésére használt platformunkon végeztük, amely nemrég esett át némi modernizáción, a korábbi ASUS ROG Crosshair VII Hero alaplapot ugyanis lecseréltük egy MSI MEG X570 Godlike modellre, ami kihasználhatóvá teszi a PCI Express 4.0-s szabványt is. Erre most persze nem volt szükség, a többi paraméteren pedig nem változtattunk.

A tesztek két grafikus kártyán futottak, az AMD oldaláról a Sapphire Pulse RX 5600 XT, az NVIDIA oldaláról pedig a Gigabyte GeForce GTX 1660 Ti GAMING OC 6G szállt a ringbe. A szándékunk természetesen nem az volt, hogy ezt a két VGA-t vagy akár a GPU-kat hasonlítsuk össze, hiszen ezt megtettük már korábban. Azt mindenesetre megjegyeznénk a Sapphire kártyája kapcsán, hogy ez már „gyárilag” a tuningolt órajelekkel érkező modell, tehát mind a processzor, mind pedig a memória emelt órajelen üzemel. Egyébként a beállításokat egyik esetben sem módosítottuk, alapértelmezett értékeket használtunk, egyedül az AMD Radeon Anti-Lag, illetve az NVIDIA Low Latency üzemmódját kapcsoltuk ki és be a mérések között.

Gigabyte GeForce GTX 1660 Ti GAMING OC felül, Sapphire Pulse RX 5600 XT alul [+]

A hardver mellé egy „butított” játékcsomagot vetettünk be. Mivel a vizsgálandó szolgáltatások egységesen működnek DirectX 11 alatt, így ezt az API-t használtuk az alábbi táblázatban szereplő játékoknál.

Mérések: AMD Radeon Anti-Lag

Az eredményeket az OCAT segítségével rögzítettük, ez alapján számoltuk a késleltetés és az FPS értékeit is. A késleltetési adatokat növekvő sorrendbe rendeztük, így jobban látszanak a különbségek, az átlagok számításakor pedig a szélsőséges, alsó és felső egy százalékba eső eredményeket nem vettük figyelembe. Lássuk akkor először az Sapphire kártyájával kapott adatokat!

Első ránézésre is látható, hogy az Anti-lag beállítás működik, és nem is kicsit, magas minőségi beállítások (alacsony képkockasebesség) mellett közel felére is csökkenhet a késleltetés. Mivel itt egyetlen képkocka is körülbelül 20-40 ms időt tölt a képernyőn, számok szintjén mindenképpen látványosnak tűnik a változás. Kevésbé drasztikus viszont a hatás alacsony minőségi szinten: magas képkocka/másodperc értéknél a pár ezredmásodpercig felvillanó képeknél az Anti-lag nem sokat tudott javítani.

Mérések: NVIDIA Low Latency

Következő mérési sorozatunkban az NVIDIA Low Latency üzemmódjának Ultra beállítását vizsgáltuk.

Érdekes módon a zöldek késleltetéscsökkentő funkciója esetünkben jóval kevésbé bizonyult hatékonynak, egyedül a Metro: Exodus alatt, magas minőségi beállításoknál produkált kimutatható javulást, a többi esetben nem sokat ért.

Összegzés

Ahogy a görbéken, illetve az alábbi összegző diagramon is látható, az illesztőprogramokba épített, késleltetést csökkentő megoldások jobbára működnek – az AMD-nél úgy tűnik, valamivel megbízhatóbban. Eddig tehát rendben is lennénk, a gond az, hogy attól még, hogy valami működik, nem biztos, hogy értelme is van! És jelen esetben úgy érezzük, hogy inkább nincs...

Mint a diagramokon is látszik, a késleltetés csökkentése főleg magas minőségi beállítások és alacsony képkockasebesség mellett hoz látványos eredményt. Ez nem is túlságosan meglepő, azonban a késleltetésre érzékeny felhasználók nem ilyen beállításokkal fognak játszani, mert kompetitív környezetben inkább a gyorsaságra helyeződik a hangsúly. Az alacsony felbontás és részletesség mellett viszont alig látszik a hatásból valami.

Ezzel párhuzamosan el kell viselnünk némi tempóveszteséget – szerencsére ez jobbára minimális maradt. Az eredményekhez hozzátennénk, hogy ezúttal a két kártya direkt összehasonlítása nem túl szerencsés. Persze meg lehet tenni, de leginkább azt kell figyelembe venni, hogy az adott meghajtó alacsony késleltetésű módja mennyit javít a normál működéshez képest a futtatott program alatt.

A fentieket figyelembe véve, némi gyakorlati tapasztalattal a hátunk mögött úgy gondoljuk, hogy annyira nem érdemes sokat bajlódni ezekkel a beállításokkal: aki magas részletességgel, de nem versenyszerűen játszik, keveset profitál belőle, a sebességcsökkenés viszont zavaró lehet. Ezzel szemben, ha valaki kompetitív játékos, akkor valószínűleg kevésbé érinti majd a lassulás, ám ott meg a szolgáltatás hatása lesz elenyésző. És ezek mindkét rendszerre igazak. Ettől függetlenül a szóban forgó funkciók ingyen érhetők el a grafikus meghajtókban, talán egy próbát megérnek, és az alapján mindenki a saját tapasztalatára építve eldöntheti, hogy alkalmazza-e őket vagy sem.

Wombath, Abu85

A Sapphire Pulse RX 5600 XT videokártyát az AMD biztosította.