Gigantikus driverteszt, avagy mit rejtenek a meghajtók

Az eszközillesztők a grafikus vezérlők kenőolajai, de vajon lehetnek többek is ennél?

Energiagazdálkodás okosan a Chill-lel

A végére hagytunk egy igen érdekes képességet, ami nagyjából egy éve mutatkozott be Radeon Chill néven. Ennek alapja az a Chill nevű alkalmazás, amit az ötletgazdának számító HiAlgo fejlesztett, amíg be nem olvadtak az AMD-be, azóta pedig azon dolgoztak, hogy a legfőbb hiányosságot, vagyis a támogatott játékok igen korlátozott számát megnöveljék. Végül az egy hónapja megjelent Radeon Software Adrenalin Edition bevezetett egy új Chill verziót, amely immáron majdnem minden játékot támogat, így lényegében általánosan működik.

Maga a Chill egy rendkívül bonyolult fejlesztés. A HiAlgo lassan öt éve kezdett dolgozni a koncepción, tehát rendkívül sok munka van benne. Persze az időpontokból nehéz kiindulni, mert a HiAlgo régen nem kapott hozzáférést egyik grafikus meghajtó forráskódjához sem, ami természetesen akadályozta a munkájukat. Végül aztán rájöttek, hogy külsős cégként túl nehéz dolguk van, így elkezdtek egyre inkább közeledni a gyártókhoz, amíg aztán az AMD úgy nem döntött, hogy megéri megvenni ezt a kis céget. Innentől a Chill fejlesztése felgyorsult, viszont a működése ekkortól már sajnos a Radeonokra korlátozódott.

A rendszer alapvetően a képkockaszámítás eddig ismert és elterjedt módját értelmezi újra. A HiAlgo régebben felismerte, hogy többek között a késleltetésnek egyáltalán nem tesz jót, ha a meghajtó a processzor által számolt jeleneteket egy parancslistába fűzi fel. Ez a modell arra szolgál, hogy az adott konfiguráció a lehető legjobban legyen kihasználva, a tesztekben a lehető legmagasabb képkockasebességet adja, nem törődve azzal, hogy közben ennek van-e látható előnye vagy rontja-e a késleltetési értékeket.

Hirdetés

A Chill egy gyakorlatiasabb megközelítést használ. A legfőbb kérdés az, hogy miképp lehet biztosítani a felhasználóknak egy olyan feldolgozási modellt, amelynél a kritikus helyzetekre adott késleltetési értékek a lehető legkisebbek, miközben a rendszer fogyasztása csökken és a kapott élmény is egy szinten marad a pazarlóbb feldolgozási modellel. A titok igazából a meghajtóba épített, vezérelhető parancslista, ami lehetővé teszi, hogy a jelenetszámítás során a beérkező adatok egyenletes időközönként jussanak el a grafikus vezérlőhöz. Kicsit olyan ez, minta a két (vagy több) GPU-s, AFR elven működő rendszereknél az úgynevezett frame pacing. Mint ismeretes, frame pacing nélkül két GPU egyszerűen nem egyenletesen jeleníti meg a képkockákat, míg frame pacing alkalmazásával a megjelenítést kiegyenlíti a meghajtó. A Chill hasonlót csinál, csak a jelenetek oldalán, ezért is utalnak rá néha scene pacing technikaként.

Amennyiben a jelenetek biztosítása egységes, akkor igazából a parancslista nem is kell. Ez persze nem igaz, valahol azért azt az egy jelenetet is tárolni kell, de a lényeg az, hogy a hardver mindig az aktuális jelenethez tartozó képkockát számolja, méghozzá teljes erőbedobással. Ez garantálja azt, hogy ugyanolyan képkockasebesség mellett a Chill gyorsabban végez ugyanazzal a számítással a hagyományos feldolgozási modellhez képest, mert biztosan nincs ott parancslistában a következő jelenet, aminek a számítását elkezdené a GPU, ráadásul még azelőtt, mielőtt az aktuális képkockát teljesen befejezné.

Az egyenletesség a késleltetés csökkentésén túl más előnnyel is jár. A rendszer képes lesz bizonyos külső tényezőkhöz alkalmazkodni, például reagálni lehet a bemeneti adatokra. A hagyományos feldolgozás során nincs különbség aközött, hogy a felhasználó mozog-e vagy sem. A parancslista ugyanúgy él, a hardver ugyanúgy próbálja biztosítani a lehető legnagyobb képkockasebességet, még akkor is, ha a játékos gyakorlatilag ugyanazt a képet látja újra és újra. Ennek kiszámítása folyamatosan megtörténik, ráadásul a lehető leggyorsabban. A vezérelhető parancslistában viszont pont az a jó, hogy alkalmazkodhat a körülményekhez. Ha folyamatos akció van, azaz a játékos aktívan mozog és lövöldöz, akkor a meghajtó megpróbálja a lehető legnagyobb tempó mellett biztosítani a képkockákat, betartva persze az egyenletességet. Ha viszont az akció alábbhagy vagy esetleg megszűnik, akkor megfigyelhető, hogy a bemeneti adatok is ritkábbak lesznek. Ilyenkor a meghajtó lecsökkenti a futtatási sebességet, mert lassúvá válik a mozgás, vagyis ugyanolyan élményhez nem szükséges a leggyorsabb feldolgozás, ezzel pedig a rendszer energiát takaríthat meg, ugyanis amint kiszámításra került az aktuális képkocka, a GPU leveheti az órajeleit, amíg be nem fut a következő jelenet.

Az energiagazdálkodás egyébként nem szerves része a Chillnek, hanem csak egy felhasználható mellékhatása a vezérelhetőségnek. Emiatt is van a meghajtóban egy sebességtartományra vonatkozó csúszka a telepített játékokra létrehozott profilokon belül, amivel 30 és 300 fps között bármilyen tartományt beállíthat a felhasználó.

A Chill működését a Far Cry Primal programban teszteltük, méghozzá úgy, hogy egy percig játszottunk az alkalmazással. Az első harminc másodperben aktívan mozogtunk és lövöldöztünk, míg a fennmaradt időben csak álltunk, hogy lássuk mennyit lehet megtakarítani a koncepcióval extrém körülmények között – persze az útvonal ugyanaz volt. Az alábbi két videó prezentálja, hogy a tesztnél mit mutatott a fogyasztásmérő a teljes gép energiaigényére.

Far Cry Primal normál módban, Radeon Chill nélkül

Chill nélkül lényegében nem számított, hogy mit csinálunk a programon belül, a rendszer mindig a lehető legmagasabb teljesítményt biztosította, még akkor is, ha lelassítottunk vagy megálltunk. Akármit is tettünk, a fogyasztás 380 és 390 watt között alakult.

Far Cry Primal aktív Radeon Chillel

Chill mellett már egészen más volt a helyzet. Még az aktív mozgással töltött első fél percben is 210-280 watt között alakult a fogyasztás, leginkább 220-230 watt körül, míg pihenésnél visszaesett 144-145 watt közé, mindez természetesen halkabb és hűvösebb működéssel is járt.

A különbség jelentős, miközben ha valaki nem mondja el, hogy mikor aktív a Radeon Chill és mikor nem, akkor azt pusztán a kijelzőn megjelenő tartalomból nem lehetne megállapítani. Mozgásnál ugyanis továbbra is nagy a sebesség, míg mozgás nélkül nem látszik, hogy ugyanazt a képet a kijelző alacsony vagy magas képkockasebesség mellett frissíti.

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények

Hirdetés