Hirdetés

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?

Az AMD, az Intel és az NVIDIA szoftverei

A PC-piac nagy gyártótriójának számító AMD, Intel és NVIDIA hardvereinél jellemzően csak a teljesítményt és a legfontosabb szolgáltatásokat szoktuk elemezni tesztjeinkben. Ugyanakkor észrevehető, hogy az említett cégek grafikus vezérlőikhez már komolyabb szoftvercsomagot mellékelnek, így ezek már rég túlléptek a szimpla eszközillesztő státuszon. Az AMD például a mini OS jelzőt szokta emlegetni, ami nyilvánvalóan badarság, viszont tény, hogy a szállított kód komplexitása az operációs rendszerekkel vetekszik, és ez nem csak a különféle rutinokkal biztosított alkalmazásspecifikus optimalizálások miatt van így, hanem a jelentős extra szolgáltatások is hozzájárulnak ehhez.

A fentiek miatt érdemes megnézni, hogy manapság mit is tartalmaznak a grafikus eszközillesztők, nem csak pusztán az alapvető működés szintjén vizsgálva a rendszert, hanem megtekintve a játékosokat célzó funkciókat, illetve letesztelve azokat, ha képekkel nem lehet bemutatni előnyeiket.

Még mielőtt azonban a tettek mezejére lépnénk, érdemes egy kicsit átnézni az érintett cégek meghajtóinak felhasználói felületét. Ezen lényegében a vezérlőpultot értjük, amelyekkel elérhetők az egyes extra funkciók. A dizájn tekintetében a különbségek már ránézésre is nagyok.


Az AMD grafikus vezérlőpultja Az AMD grafikus vezérlőpultja Az AMD grafikus vezérlőpultja Az AMD grafikus vezérlőpultja Az AMD grafikus vezérlőpultja Az AMD grafikus vezérlőpultja
Az AMD grafikus vezérlőpultja [+]

Az AMD Radeon Settings felülete rendkívül modernnek hat. Ez nem véletlen, ugyanis a vállalat két éve cserélte le a sokáig szolgáló Catalyst vezérlőpultot, tehát már a tervezés szintjén is alapvetően a modern vonások számítottak.


Az NVIDIA grafikus vezérlőpultja Az NVIDIA grafikus vezérlőpultja Az NVIDIA grafikus vezérlőpultja Az NVIDIA grafikus vezérlőpultja Az NVIDIA grafikus vezérlőpultja
Az NVIDIA grafikus vezérlőpultja [+]

Az NVIDIA Control Panel, azaz vezérlőpult már jóval régebbi fejlesztés. Annyira, hogy fejből már az idejét sem lehet tudni a megjelenésének, de majd 15 éves alapokra épül. A zöldek azonban egy alternatív vezérlőpultot is kínálnak GeForce Experience programon belül, amely különböző specifikus szolgáltatások elérésére szolgál, és ez már jóval modernebbnek hat.

Az NVIDIA GeForce Experience program Az NVIDIA GeForce Experience program Az NVIDIA GeForce Experience program Az NVIDIA GeForce Experience program Az NVIDIA GeForce Experience program Az NVIDIA GeForce Experience program
Az NVIDIA GeForce Experience program [+]

Az Intel grafikus vezérlőpultja is kellemes összhatást kelt, ami szintén nem véletlen, mivel az alapjai 2013-ból származnak, vagyis alig öt évesek.


Az Intel grafikus vezérlőpultja Az Intel grafikus vezérlőpultja Az Intel grafikus vezérlőpultja Az Intel grafikus vezérlőpultja Az Intel grafikus vezérlőpultja
Az Intel grafikus vezérlőpultja [+]

Egyik gyártó felhasználói felületét sem fogjuk értékelni szubjektív szempontok alapján, hiszen a lényeg az, hogy működnek, minden elengedhetetlen dolgot meg lehet találni bennük, még akkor is, ha néha egy-egy beállítás talán túlságosan is el van rejtve. Aki viszont használja magát a rendszert, idővel tudni fogja, hogy mi hol található. Objektíven vizsgálva azonban nem lehet elmenni szó nélkül amellett, hogy mennyire gyorsan reagálnak az egyes felhasználói interfészek. Ebben jelenleg az AMD a legjobb, amiben persze hatalmas szerepe lehet annak is, hogy a Radeon beállítások felület nagyon újnak számít. Az Intel és az NVIDIA vezérlőpultjain azért érződik az idő, sajnos viszonylag lassan töltenek be, viszont a különálló GeForce Experience igen kellemesen működik ebből a szempontból.

Szintén kiemelendő, hogy az NVIDIA felülete egyáltalán nincs hozzáigazítva az érintőkijelzőkhöz, amivel együtt lehet élni, de nem feltétlenül szerencsés. Az Intel megoldása ebből a szempontból annyiban jobb, hogy nagyobbak a menüpontok, az AMD által alkalmazott dizájn viszont kifejezetten kedvez az érintésre érzékeny megjelenítőkkel dolgozó gépeknek.

Hirdetés

Extrák összevetve

A jobb összehasonlítás érdekében egy táblázatot készítettünk az AMD, az Intel és az NVIDIA meghajtókban elérhető főbb szolgáltatásokról.

A PC-n elérhető grafikus meghajtók képességei
Gyártó AMD Intel NVIDIA
Több kijelző kezelése
van (Eyefinity) van (Collage Display) van (Surround)
Kijelzők száma grafikus vezérlőnként 6 4 4
Kijelzők maximális száma 12 4 5
Keretkorrekció van van van
Független hangátvitel a kijelzőkhöz van - -
Miracast képtovábbítás van van van
Sztereó 3D támogatás van van van
HDR támogatása
van van van
Egyedi felbontások támogatása van van van
Videolejátszás minőségének javítása opcionális opcionális opcionális
Videók rázkódásának kiegyenlítése van (Steady Video) - -
Mozgásinterpoláció van (Fluid Motion Video) - -
Variálható frissítési frekvencia van (FreeSync) - van (G-Sync)
Vertikális szinkron támogatása van van van
Adaptív vertikális szinkronizáció - - van
Speciális szinkronizáció van (Enhanced Sync) - van (Fast Sync)
Virtuális felbontás támogatása van (VSR) - van (DSR)
Élsimítás utófeldolgozással van (MLAA) van (CMAA) van (FXAA)
Élsimítás többszörös mintavétellel van van van
Adaptív többszörös mintavételezés van (EQAA) - van (CSAA)
Több képkockás mintavételezés - - van (MFAA)
Élsimítás szupermintavétellel van (SSAA+AutoLOD) - -
Élsimítás hibrid mintavétellel - - van (TrSSAA)
Anizotróp szűrés támogatása van (2x-16x) van (2x-16x) van (2x-16x)
Shader gyorsítótár van van van
Tesszelláció egyedi kontrollálása van -
-
Képkockasebesség korlátozása van (30-200) -
-
Tripla pufferelés kényszerítése van
-
van
Flip queue alapértelmezett mérete 1 3 3
Konfigurálható flip queue - - van (1-8)
Több GPU támogatása van (mGPU) - van (SLI)
Frame pacing több GPU-val van (kikapcsolható) - van
Gyári tuningmodul van (WattMan) - -
Hűtés konfigurálhatósága van - -
TDP-keret gyári konfigurálhatósága van - -
Scene pacing modul van (Chill) - -
Gyári felvevő- és közvetítőmodul van (ReLive) - van (ShadowPlay)
Kooperációs játékmegosztás - - van (GameStream Co-op)
Integrált ambient occlusion - - van (HBAO)
Speciális utófeldolgozások - - van (Freestyle)
Játékok grafikájának konfigurálása - - van
Képkockasebesség kijelzése van - van
Teljes Overlay modul van (Overlay) - -
Meghajtót frissítő modul van - van
Vezérelhetőség mobil eszközről van (Link) - -
Külsőleg bekötött GPU támogatása van (XConnect) - van

A táblázat önmagáért beszél, de pár dolgot azért érdemes hozzáfűzni. Többek között ki kell emelni, hogy bizonyos funkciók hardverfüggőek, tehát a fentiek csak a szoftverre vonatkoznak, de például a HDR támogatása az Intelnél csupán a Core sorozatú processzorokba épített IGP-kkel érhető el, illetve alapvetően az új hardverek meglétéhez van kötve. Hasonlóan fontos kiemelni, hogy az NVIDIA Maxwell és Pascal architektúra már nem támogatja a CSAA-t, viszont a második generációs Maxwell és Pascal esetében van MFAA és Fast Sync, a többi NVIDIA GPU-n ugyanakkor nincs.

NVIDIA Freestyle
NVIDIA Freestyle [+]

Érdekes dolognak számít az NVIDIA oldalán a képkockaszintű ambient occlusion effekt, amely pár játékban aktiválható. Ez régebben került bele a driverbe, azóta a fejlesztése leállt, mert a mai játékoknak ez már eleve a része, így nincs értelme pénzt ölni egy meghajtó oldali implementációba. Új dolog azonban a Freestyle, amely különböző utófeldolgozással működő effektet kínál meghatározott játékokhoz, azaz ezt sem lehet mindenen alkalmazni.

Végül a Miracast képtovábbítás is eléggé hardverfüggő szolgáltatás, illetve a Thunderbolt interfészen bekötött GPU-k esetében számolni kell azzal, hogy a régebbi grafikus vezérlők nem működnek. Ezekről az érintett gyártók weboldalán mindig részletesen lehet tájékozódni.

Szinkronizáció több formája

Az extra szolgáltatások közül kiemelendők a szinkronizációs lehetőségek. Legtöbb olvasónknak talán a vertikális szinkron neve az ismerős, amely lehetővé teszi egy bosszantó probléma, nevezetesen a képtörés kezelését.

AMD és NVIDIA szinkronizáció nélkül – képkockasebesség alakulása AMD és NVIDIA szinkronizáció nélkül – képkockasebesség alakulása
AMD és NVIDIA szinkronizáció nélkül – képkockasebesség alakulása [+]

Kicsit az elméleti alapokat megerősítve a rendszer a képszámítás során alapértelmezetten két pufferrel dolgozik. Az egyik a képkocka-, míg a másik a háttérpuffer. A kijelző számára a képkockapufferből jeleníthetők meg az adatok, amelyek frissítése pixelsorról pixelsorra történik. A következő képkocka a háttérpufferben készül, és ha a számítások befejeződtek, akkor a háttérpuffer lesz az új képkockapuffer, ahonnan a kijelző meg is jelenítheti az adatokat.

Ez tökéletes modell lenne, ha minden szinkronban működne, azaz csak akkor történne meg a háttérpuffer és a képkockapuffer felcserélése, ha a kijelző is végzett a saját függőleges szinkronizációjával. A valóság azonban ennél sokkal bonyolultabb, így problémát jelent, ha a számítógép lassabban vagy gyorsabban dolgozik, mint a kijelző frissítése, ez ugyanis biztos képtörést eredményez, hiszen többször is akkor fog elkészülni a következő képkocka, amikor a megjelenítő még nem rajzolta ki az előzőt. A rendszer azonban ezzel nem törődik, az éppen aktuális háttérpuffert kinevezi képkockapuffernek, és a kijelző a következő pixelsor kiolvasásánál már egy másik képkockához tartozó adatot kap. Ezzel meg is tört a kép.

A vertikális szinkron ezen a problémán úgy segít, hogy a képkockapuffer és a háttérpuffer cseréjével megvárja, amíg a kijelző frissít. Ennek az az előnye, hogy mindig csak teljesen összefüggő képkockák kerülnek megjelenítésre, és végeredményben a felhasználó is ezt akarja látni, de vannak azért bosszantó hátrányok is. Például gondot jelent, ha az adott szinkronablakon belül nem készül új kép. Ez könnyen előfordulhat, ha a képkockasebesség kisebb a kijelző függőleges frissítésénél. Ebben az esetben nincs más választás, újból meg kell jeleníteni az előző képkockát, ami egy apró akadás formájában nyilvánul meg.

AMD és NVIDIA vertikális szinkronnal – képkockasebesség alakulása AMD és NVIDIA vertikális szinkronnal - képkockasebesség alakulása
AMD és NVIDIA vertikális szinkronnal – képkockasebesség alakulása [+]

AMD és NVIDIA vertikális szinkronnal – az egyes képkockák elkészültének ideje AMD és NVIDIA vertikális szinkronnal – az egyes képkockák elkészültének ideje
AMD és NVIDIA vertikális szinkronnal – az egyes képkockák elkészültének ideje [+]

Az akadások jól láthatók a vertikális szinkron gyakorlati működését prezentáló két grafikonunkon, ami mellé még további két eredményt rajzoltunk fel, ahol az egyes képkockák elkészültéhez szükséges, ezredmásodpercben mért idő elemezhető. A méréseknél szándékosan úgy alakítottuk az AMD Radeon Vega 56 és az NVIDIA GeForce GTX 1070 teljesítményét, hogy a Far Cry Primal játékon belül, a teszt ideje alatt, egy rövid ideig 60-nál kevesebb képkockát számoljanak. Ehhez persze minimumra, vagyis 50%-kal csökkentenünk kellett a Radeon Vega 56 TDP-keretét, de a cél szentesíti az eszközt.

Az egyes képkockák elkészültének ideje és a képkockasebesség alakulása NVIDIA adaptív vertikális szinkronnal Az egyes képkockák elkészültének ideje és a képkockasebesség alakulása NVIDIA adaptív vertikális szinkronnal
Az egyes képkockák elkészültének ideje és a képkockasebesség alakulása NVIDIA adaptív vertikális szinkronnal [+]

Az NVIDIA az akadásokra az adaptív vertikális szinkronnal reagál. Ez gyakorlatilag kikapcsolja magát a szinkronizációt, ha a konfiguráció képkockasebessége a megjelenítő frissítési frekvenciája alá esik. Ennek persze az lesz a nyilvánvaló hátránya, hogy visszatér a képtörés, így nem nevezhető ideális megoldásnak.

A fentiek mellett a vertikális szinkronról még általánosan elmondható, hogy az egész rendszer alapja a várakozás, ebből már kitalálható, hogy a késleltetésre igen kedvezőtlen hatással van, így a felhasználók a beviteli eszközön kiadott parancsok eredményét később láthatják a kijelzőn.

Az AMD és az NVIDIA a tipikus problémákat elemezve kidolgozott olyan speciális szinkronizációkat, amelyek ha nem is tökéletesek, de elég jól működnek ahhoz, hogy alternatívát biztosítsanak a vertikális szinkron különböző módjaival szemben.

Az AMD Enhanced Sync és NVIDIA Fast Sync a működés koncepcióját tekintve rendkívül hasonló. Ugyanúgy megvan a rendszerben a képkockapuffer, illetve a háttérpuffer, viszont közéjük kerül egy speciális tároló, amely az utolsó elkészült képkockát tartalmazza. Ezzel a szinkronizációs folyamat háromlépcsőssé válik. Nem jelent tehát gondot, ha a kijelző még nem fejezte be az aktuális képkocka megjelenítését, ugyanis a háttérpuffer lesz az új speciális puffer. Ezzel a következő kép számítása megkezdődhet, miközben a kijelző ráér végezni a saját feladatával. Ha ez megtörtént, akkor a speciális puffer lesz az új képkockapuffer, vagyis a tartalma mehet a megjelenítőre.

Az Enhanced Sync és a Fast Sync előnye, hogy nagyon kevés extra késleltetést ad hozzá a rendszerhez, illetve eliminálja az apró akadásokat is. Hátrányuk viszont, hogy a képtöréseket bizonyos képkockasebesség mellett nem képesek eltüntetni, de alapvetően kellően jól működnek ahhoz, hogy ezt a felhasználók csak minimális mértékben érezzék. Mindemellett a futtatott játék megőrzi a sebességét is, ami jól látható az alábbi diagramokon.

AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – képkockasebesség alakulása AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – képkockasebesség alakulása
AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – képkockasebesség alakulása [+]

AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – az egyes képkockák elkészültének ideje AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – az egyes képkockák elkészültének ideje
AMD (Enhanced) és NVIDIA (fast) speciális szinkronnal – az egyes képkockák elkészültének ideje [+]

Persze a legjobb szinkronizációnak az AMD FreeSync és az NVIDIA G-Sync, azaz összevont néven a variálható frissítési frekvenciát biztosító lehetőségek számítanak. Ilyenkor lényegében a monitor igazodik a konfigurációhoz, de ehhez ugye speciális kijelző is kell, ami támogatja ezt a lehetőséget. Ha van rá mód, akkor mindenképpen ezt érdemes választani, sőt kifejezetten ajánlott az új rendszerek vásárlásakor a FreeSync vagy a G-Sync lehetőségét mérlegelni, mert elképesztően sokat javítanak a kapott élményen.

ReLive és ShadowPlay

Manapság az egyik legfontosabb szolgáltatásnak számítanak a felvevő- és közvetítőmodulok, hiszen rengeteg felhasználónak van valamilyen oldala, csatornája valamilyen közösségi platformon. Okvetlenül fontosnak találják tehát a gyártók, hogy ezt az igényt lefedjék, de ahogy látszik a második oldalon, az Intel ilyen funkciót nem épít meghajtójába annak ellenére sem, hogy a megfelelő hardver ott van integrált grafikus vezérlőikben. Ehelyett a harmadik féltől származó megoldásokat támogatják, vagyis alternatívát ők is kínálnak, ugyanakkor az AMD és az NVIDIA felismerte, hogy itt egy gyári szolgáltatás biztosításával nagyon sokat lehet nyerni.

Az AMD a ReLive, az NVIDIA pedig a ShadowPlay modult kínálja, amelyek bár ugyanarra valók, de sok szempontból eltérnek egymástól. Ezt a legjobban ismét egy táblázattal lehet bemutatni.

A gyári felvevő- és közvetítőmodulok PC-n
Gyártó AMD ReLive NVIDIA ShadowPlay
Videókódolás típusa H.264 vagy H.265 H.264
Audiókódolás típusa MPEG AAC
Rögzítés támogatott felbontásai 360p, 480p, 720p, 1080p, 1440p, 2160p, játékban beállított
Rögzítés támogatott sebessége 30 vagy 60 fps
Rögzítési profilok alacsony (5 Mbps)
közepes (10 Mbps)
magas (30 Mbps)
alacsony (15 Mbps)
közepes (21 Mbps)
magas (50 Mbps)
Beállítható bitráta általánosan 1-100 Mbps 1440p-ig 10-50 Mbps
2160p-ben 30-130 Mbps
Felvétel hossza 15 másodperctől egészen 20 percig
Gyorsbillentyűk támogatása van van
Asztal rögzítése van van
Visszajátszásszerű rögzítés van van
Rögzítési tartomány teljes képernyő vagy kijelölt régió csak teljes képernyő
Hang mintavételi rátája 48 kHz
Választható bitráta a rögzített hangnál 32, 64, 96, 128, 160, 192, 256, 320 kbps -
Közvetítés támogatott felbontásai 360p, 480p, 720p, 1080p, 1440p YouTube: 360p, 480p, 720p, 1080p, 1440p
Facebook: 360p, 480p, 720p
Twitch: 360p, 480p, 720p, 1080p
Közvetítési profilok általánosan:
alacsony (1,5 Mbps)
közepes (2,5 Mbps)
magas (3,5 Mbps)
nagyon magas (6 Mbps)
egyedi (1-20 Mbps)
YouTube:
alacsony (2 Mbps)
közepes (6 Mbps)
magas (9 Mbps)
nagyon magas (18 Mbps)
egyedi (1-18 Mbps)
Facebook:
alacsony (1 Mbps)
közepes (2 Mbps)
magas (4 Mbps)
egyedi (1-4 Mbps)
Twitch:
alacsony (1 Mbps)
közepes (2 Mbps)
magas (3,5 Mbps)
nagyon magas (9 Mbps)
egyedi (1-18 Mbps)
Közvetítés támogatott sebessége általánosan:
30 vagy 60 fps
YouTube:
30 vagy 60 fps
Facebook:
30 fps
Twitch:
30 vagy 60 fps
Választható bitráta a közvetített hangnál 32, 64, 96, 128, 160, 192 kbps -
Archivált közvetítés van -
Webkamera overlay támogatása van van
Kamerakép átlátszósága van (0-100%) -
Kamerakép elhelyezése teljesen definiálható csak a sarkokba
Kamerakép mérete teljesen definiálható -
Chroma Key támogatás van -
Modul elérhetősége opcionálisan az eszközillesztőből külön programból (GeForce Experience)
Modul működésének előfeltétele nincs regisztráció szükséges

Teljesítmény tekintetében nincs igazán hátránya az AMD ReLive és az NVIDIA ShadowPlay használatának, aminek az az oka, hogy fixfunkciós blokkokon futnak. Persze egy nagyon csekély lassulással számolni kell, mivel a videomemóriát mindkettő terheli, így igényelnek némi memória-sávszélességet.

Teljesítmény ShadowPlay nélkül és ShadowPlay mellett Teljesítmény ShadowPlay nélkül és ShadowPlay mellett
Teljesítmény ShadowPlay nélkül és ShadowPlay mellett [+]

A méréseink szerint az AMD ReLive 3-4, míg az NVIDIA ShadowPlay 6-7 százalékot lassít, de ez nagymértékben függ a kiválasztott alkalmazástól, sok esetben inkább csak 1-3 százalék közötti a teljesítményveszteség. Megpróbáltunk olyan játékot és beállítást választani, ami nagyon leterheli a memóriabuszt, hogy lássuk a legrosszabb eshetőséget. Az biztos, hogy a processzort terhelő opciókhoz viszonyítva még így is sokkal kedvezőbb mindkét megoldás.

Teljesítmény ReLive nélkül és ReLive mellett Teljesítmény ReLive nélkül és ReLive mellett
Teljesítmény ReLive nélkül és ReLive mellett [+]

A képességekben nincs nagy különbség a két megoldás között. Ha tartalmak rögzítése a cél, akkor nem lehet igazi győztest hirdetni, persze helyenként picit eltér a ReLive és a ShadowPlay, de a gyakorlatban ezt nem fogják észlelni a felhasználók. Közvetítés esetén viszont a ReLive sokkal rugalmasabb a webkamera kezelésében, illetve archiválási lehetőséget is kínál. Azt külön nem értékelnénk, hogy a ShadowPlay nincs gyárilag benne a meghajtóban, illetve használata regisztrációhoz kötött, mert ez valakinek hátrány, valakinek pedig nem.

Élsimítás és virtuális felbontás

Az élsimítással kapcsolatban kevés olyan dologról lehet beszélni, ami igazán újdonság. Pár éve írtunk egy cikket erről, és azóta nem is nagyon változott a helyzet. Sőt, a mai játékok videojáték-motorjai a driverből kényszerített MSAA-val, illetve ennek a speciális formáival gyakorlatilag egyáltalán nem kompatibilisek. Persze öröm az ürömben, hogy erre a fejlesztők is rájöttek, így ma már tényleg gondolnak erre a problémára a játékokon belül. Ennek köszönhetően szinten minden program tartalmaz egy megfelelően kialakított élsimítási eljárást, amit lehet használni.

A meghajtóba viszont az Intel is beépített egy utófeldolgozásos elgondolást, így már mindhárom cég támogat egy olyan élsimítási formát, ami akármelyik programmal kompatibilis. Itt nevezetesen az Intel a CMAA 1.3-as verzióját használja, míg az AMD leragadt az MLAA 2.0-nál, az NVIDIA pedig az FXAA 3.11-nél. Az alábbi képek mutatják be ezek képességeit.

Intel CMAA, NVIDIA FXAA, AMD MLAA Intel CMAA, NVIDIA FXAA, AMD MLAA Intel CMAA, NVIDIA FXAA, AMD MLAA
Intel CMAA, NVIDIA FXAA, AMD MLAA [+]

Jelen formában az Intel CMAA tűnik a legjobbnak, de megvannak ugyanazok a hátrányai, mint az MLAA és az FXAA duónak, így a betűknél ez is homályosít egy picit, bár kétségtelenül nem annyira, mint a konkurens megoldások. Mindemellett a meghajtóból kényszerített, utófeldolgozásra épülő élsimítási formák alapvető hátránya, hogy temporálisan nem stabilak, vagyis mozgás mellett apró, de zavaró képi torzulásokkal jár a kapott eredmény, ami azért van, mert csak a végső képkocka szolgáltatja a számításhoz tartozó összes információt, ami elég kevés.

A fentiek mellett elmondható, hogy az AMD, az Intel és az NVIDIA algoritmusa is nagyjából négy éves, vagyis erősen túlkorosnak számít. Ugyanakkor egyik cég sem törekszik arra, hogy javítson rajtuk, aminek az lehet az oka, hogy a mai játékokba minimum egy, utófeldolgozásra épülő élsimítást integrálnak. Dolgozzon ez bárhogy is, biztosan jobb képet állít elő, mint a meghajtóból aktiválható verzió, ugyanis a számítás segíthető szubpixel adatokkal is, illetve a jellemzően külön rétegen megjelenített szövegeket nem torzítja el az eljárás. Ma már tehát kevés jelentősége van ezeknek az élsimítási formáknak, de a régebbi játékokban esetleg jó szolgálatot tehetnek.

Sokkal érdekesebb lehetőség a virtuális felbontások kezelése, amelyre az AMD és az NVIDIA is ad egy-egy megoldást. Az előbbi cég a VSR-t (Virtual Super Resolution), míg az utóbbi a DSR-t (Dynamic Super Resolution) biztosítja. Mindkettő célja ugyanaz: lehetővé tenni olyan virtuális felbontások elérhetőségét, amiket az adott kijelző nem is támogat.

A funkciókat aktiválva ki lehet választani pár extra felbontást az asztalon vagy az adott alkalmazáson belül, így például egy Full HD-s kijelzőn is elérhetővé válik a 4K. Persze nem natív formában, hiszen az adott monitor ezt képtelen lenne megjeleníteni, de maga a leképezés valóban 4K-ban fog megtörténni, majd ez a képkocka le lesz skálázva Full HD-be, és úgy megy ki a megjelenítőre.

A skálázás gyártófüggően van megoldva. Az NVIDIA DSR erre a shadereken futtatott egy megfelelő algoritmust, míg az AMD VSR ezt a folyamatot a kijelzőmotor fixfunkciós egységére bízza. Igazából mindkettőnek megvan a maga előnye és hátránya. Mivel az NVIDIA szoftveresen oldja meg a problémát, így gyakorlatilag nem csak a tipikus felbontások állíthatók be, hanem azok között elég sok átmenet is lehet. Az AMD esetében a skálázás behatárolja a támogatható felbontásokat, így azok csak olyanok lehetnek, amilyeneket a kijelzőmotor képes kezelni, cserébe maga a skálázás egyáltalán nem terheli a shadereket, így gyakorlatilag 4K-s VSR mellett olyan teljesítményt adnak le az egyes Radeonok, mintha tényleg natívan 4K-s kijelzőre számolnának. Az NVIDIA esetében a skálázást is bele kell kalkulálni a teljesítményveszteségbe, így a 4K-s DSR mód a natív 4K-s leképezésnél nagyjából 5-7%-kal lassabb.

AMD VSR és NVIDIA DSR AMD VSR és NVIDIA DSR
AMD VSR és NVIDIA DSR [+]

A VSR és a DSR minősége a fenti két képen hasonlítható össze. Mindkét esetben 4K-ban történt meg a számítás, és az eredmény Full HD-be lett visszaskálázva. Radikális különbség nincs, legalábbis a gyakorlatban aligha figyel majd fel a játékos ilyen apró eltérésekre.

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.

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.

Ez is egy szempont

Oldalunkon megjelenő tesztjeinkben természetesen továbbra is a teljesítményre fókuszálunk, amikor értékelünk egy hardvert, ám úgy gondoltuk, hogy nem lehet elmenni az AMD, az Intel és az NVIDIA meghajtói mellett, ugyanis ez is egy szempont, még ha egy kevésbé objektíven értékelhető tényező is. Sokkal egyszerűbb lemérni pár grafikus vezérlőt, felvázolni a képkockasebességet a grafikonokon, majd értékelni azt. Jelen cikk tehát inkább csak bemutató, és emiatt egzakt értékelés sem lesz.

Ha a meghajtók minőségét tekintjük, akkor az AMD és az NVIDIA megoldásaival régóta nincs gond. A szolgáltatások is kellemesek, sok esetben hasonlóak, persze azért vannak bennük egyedi lehetőségek.

Az Intel némileg le van maradva a két konkurens mögött, meghajtójuk minősége még nem éri el azt a szintet, amit a Radeon Software vagy a GeForce driver, ettől függetlenül pozitívan értékelhető, hogy az utóbbi időben legalább próbálkoznak. Egyre több játékot profiloznak, viszonylag hamar kiadják az egyes új alkalmazásokhoz a megfelelően optimalizált eszközillesztőt, azaz lehet benne reménykedni, hogy jó irányba lépked a cég. A felzárkózás tehát tart, az igazi kérdés, hogy erre előbb vagy inkább utóbb kerül majd sor.

A Kaby Lake-G vezérlőpultja. Ismerős?
A Kaby Lake-G vezérlőpultja. Ismerős? [+]

Meg kell még említeni, hogy az Intel a Kaby Lake-G esetében az AMD egyes meghajtómoduljait sajátjaként fogja feltüntetni. Ezt egyelőre nem vettük számításba, mivel egyrészt nem tudni, hogy mik lesznek ebben a szoftvercsomagban, másrészt a Radeon márkanevet fogja használni a Santa Clara-i óriáscég, tehát bármennyire is nem írják rá a termékekre az AMD nevét, ettől még ők szállítják bele a hardvert.

A jó ötletekre szabvány kellene

A jövő tekintetében talán érdemes lenne a Microsoftnak és a Khronos Groupnak azon dolgoznia, hogy bizonyos ötleteket valahogy szabványosítsanak. Ilyen például az NVIDIA Fast Sync és az AMD Enhanced Sync. Rendben van, hogy ezek működnek az egyes gyártók meghajtóiban, de nagyon kellemes lenne, ha a játékokon belül feltűnnének, méghozzá hardverfüggetlenül aktiválható formában. Nem is lenne ezt túl nehéz megoldani.

Hasonlóan értékes gondolat a Radeon Chillt szabványos formába önteni, mert ez egy annyira hasznos szolgáltatás, amiből mindenki csak profitálna. Persze kétségtelen, hogy nem könnyű megvalósítani, de legalább egy próbát megérne.

Mikor lesz sok a jóból?

Az biztos, hogy a gyártók a szoftver oldali támogatásban komoly értéket látnak, így az extra szolgáltatások száma csak nőni fog – nagy kérdés viszont, hogy hol van az a határ, ahol ez még elfogadható. Az AMD például aktuális szavazásán egy olyan funkciót említ meg, mint az alapszintű videószerkesztő a ReLive modulban. Kétségtelen, hogy ez is értéket képvisel, és valakinek lehet, hogy fontos, ugyanakkor látni kell azt is, hogy lassan elképesztően bonyolulttá válnak az eszközillesztők vezérlőpultjai, és ez nem feltétlenül előnyös.

Az egyik népszerű mondás nem véletlenül fogalmaz úgy, hogy jóból is megárt a sok. Bár egyelőre a meghajtók még jól működnek, viszont a növekvő szolgáltatásokkal nő a hibalehetőségek száma is, amit remélhetőleg egyik érintett cég sem hagy figyelmen kívül.

Abu85, icon

Hirdetés

Azóta történt

Előzmények

Hirdetés