Extrák a Keplerben
Az NVIDIA a Kepler bemutatásával párhuzamosan több újdonságot is bevezet a driverben. A rendszer az anizotropikus szűrés szempontjából nem változik. A vállalat még mindig nem alkalmaz teljesen szögfüggetlen algoritmust, de ezt a játékokban egyszerűen lehetetlen kiszúrni, így ezen a ponton nem volt értelme fejleszteni. Változik viszont az élsimítás. Az eddigi módok mellett bemutatkozik egy TXAA nevű megoldás. Ez egy temporális mintavételezéssel dolgozó, MSAA-ra épülő algoritmus, ami az egyes képkockáknál máshonnan mintavételez. Hasonló az elv, mint amit anno az ATI vezetett be a Radeon X800 megjelenésével, csak azóta a technológia feledésbe merült, mivel a mai deferred rendert alkalmazó motorok már nem szívlelik az MSAA-t. Az NVIDIA éppen ezért nem is veti be a driverben a TXAA-t, hiszen úgysem működne egy driveres implementáció a játékok többségében, de a játékfejlesztőkkel együttműködnek, hogy támogassák a technológiát.
Nincs AA, 8xMSAA és TXAA [+]
Sokkal érdekesebb azonban az FXAA bevetése, mely a vállalat első, driverből aktiválható post-process élsimítása. Ez a már említett, MSAA-val nem kompatibilis, deferred rendert alkalmazó motorok miatt egyre sürgetőbb volt, hiszen az AMD már két generációval korábban reagált erre a problémára az MLAA-val. Az FXAA-ról egy korábbi hírben már részletesen írtunk, így a működést nem részleteznénk újból. A 300-as sorozatba tartozó GeForce driverbe épített FXAA gyakorlatilag minden DirectX és OpenGL API-ra épülő programmal kompatibilis, ami az algoritmus post-process jellege miatt nem meglepő. Természetesen az MLAA-hoz hasonlóan az FXAA is a motorba építve, extra információkkal segítve mutatja ki igazi erejét, így a driverbe épített megoldástól csodát nem lehet várni. Az algoritmus a végső képkocka alapján dönt az élsimításról, és ez túl kevés információ a tökéletes eredményhez. Mindenesetre a semminél így is több, hiszen a driveres MSAA-t számos játékban nem lehet alkalmazni, ráadásul ezek jó része semmilyen beépített élsimítást nem kínál, és ilyenkor a driverből aktiválható post-process megoldások sokat segíthetnek.
Nincs AA és FXAA [+]
Újszerű vertikális szinkron
Az NVIDIA a Keplerrel bevezet egy újszerű vertikális szinkront, mely az Adaptive Vsync nevet viseli. A vertikális szinkron lényegét valószínűleg minden olvasónk ismeri, de röviden azért taglaljuk, hogy miről is van szó. Az egész rendszer azt a célt szolgálja, hogy a kijelzőn megjelenő képkocka ne törjön meg. A monitorok állandó képfrissítéssel dolgoznak, miközben a képkockák számítása a program futtatása során közel sem állandó. A probléma ott keletkezik, amikor a frame bufferben található információ a kijelző frissítése közben változik, ugyanis ilyenkor a megjelenítő felső részében a régi, míg az alsó részében az új képkocka információja látható valahol egy töréssel a képen, ami esetenként igencsak zavaró lehet. Erre találták ki a vertikális szinkront, ami összehangolja a rendszer működését, így a kijelzőre kikerült tartalom mindig egy képkockáról származik. Ezzel addig a pontig nincs is probléma, amíg a program futtatása során a képkockák számításának sebessége magasabb a kijelző képfrissítésénél. Előfordulhat azonban, hogy a számítás során időnként nem lesz kész időre az új képkocka, ekkor a monitor kénytelen újból kirakni az előzőt. Ez konkrétan azt jelenti, hogy egy képkocka duplaannyi időt töltött a monitoron, mint kellett volna, és ez esetleg egy apró akadást jelenthet. Ez ellen jól lehet védekezni a tripla puffereléssel, ami a frame buffer mellé két back buffert is bevezet, így a képkockák számítása gyorsabb lehet. Ettől függetlenül még így is előfordulhat az előbb részletezett helyzet.
Az Adaptive Vsync lényegében erre jelent némi gyógyírt. A technológia mindaddig aktívnak tekinti a vertikális szinkront, amíg a képkockák számítása gyorsabb a kijelző frissítésénél. Ha ez az állapot megszűnik, akkor a vertikális szinkront azonnal kikapcsolja a rendszer, így a frame buffer, illetve a back buffer megcserélésénél a rendszer nem vár a kijelző frissítésére. Az Adaptive Vsync alkalmazásával nagyobb az esély arra, hogy ugyanaz a képkocka nem kerül ki a kijelzőre kétszer, ezzel együtt azonban a vertikális szinkron inaktiválása azt is jelenti, hogy a kikerülő képkocka megtörhet, ami természetesen hátrány, hiszen a vertikális szinkront pont azért alkalmazná a felhasználó, hogy a képtörést elkerülje. Ezenkívül az Adaptive Vsync az apró akadásokat nem tünteti el, csak csökkenti azokat, mivel ezek nem a vertikális szinkrontól következnek be, hanem pont a teljesítmény visszaesésétől, amire a grafikai részletesség csökkentésén kívül semmilyen gyógyír nincs.
Valójában legyen szó Adaptive Vsyncről vagy hagyományos vertikális szinkronról, rég rossz, ha a program futtatási sebessége a kijelző frissítése alatt van. Ettől függetlenül az Adaptive Vsync használható opció lehet, bár a tripla pufferelés melletti hagyományos vertikális szinkron továbbra is a legátfogóbb megoldás a problémára, noha ezt nem mindegyik program támogatja. Szintén érdemes kiemelni, hogy a WDDM 1.1-es felület a DirectX 10-től kezdve a vertikális szinkron vezérlését a fejlesztők kezébe adta, így a driveres Vsync megoldások főleg a DirectX 9 és az OpenGL API-k mellett működnek jól. A DirectX 10 és 11 esetében némi hackkel meg lehet kerülni a WDDM 1.1-es felület korlátozásait, de ez nem várt eredményeket is szülhet az adott motor működésében.
Bemutatkozik az NVENC
Multimédiás tudásban a Kepler nem lépett előre a Fermihez képest, így a videók gyorsítását továbbra is ugyanaz a PureVideo felület végzi. Ez azonban kiegészült az NVENC technológiával, ami lényegében a H.264-es videók transzkódolását gyorsítja fel. Az egész rendszer hasonló céllal született meg, mint az Intel Quick Sync Video vagy az AMD Video Codec Engine, ugyanis maga a transzkódolás tipikusan jól párhuzamosítható folyamat, de az entropy encoding algoritmus kivétel ezalól, így ezt megéri egy célhardverre bízni. Az NVENC motor 4096x4096 pixeles anyagokkal is megbirkózik, emellett támogatja az MVC-t is, ami a sztereó 3D-s videók esetében fontos szempont.
Az NVENC kihasználásához az NVIDIA a legújabb Cyberlink MediaEspresso programot ajánlja, de a vállalat a többi céggel is együttműködik a támogatással kapcsolatban. Általánosan elmondható, hogy a multimédiás programok fejlesztői tipikusan vevők az újdonságokra, így ebből a szempontból az új multimédiás képességek kihasználásával nem igazán szokott probléma lenni.
A cikk még nem ért véget, kérlek, lapozz!
