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.
A cikk még nem ért véget, kérlek, lapozz!
