LiquidVR a Radeon Software-ben
Az AMD a hónap elején számolt be arról, hogy abszolút reformot hajt végre a Radeon grafikus vezérlők meghajtóján, ami végérvényesen elveszíti a Catalyst márkanevet, helyette jön a Radeon Software jelzés. Ez is mutatja a radikális újításokat, amelyek közül a legnagyobb a teljesen új vezérlőközpont lesz.
Az AMD a változások előtt elárult pár apró részletet, hogy mi is az új csomag alapja, illetve azt sem titkolták el, hogy milyen névválasztási stratégiát dolgoztak ki a jövőre nézve, melyekről az alábbi hírben be is számoltunk. Az itt leírtakat nem ismételjük meg, ugyanakkor a Radeon Software Crimson Edition 15.11-es verziójáról számos dolgot csak most árult el a cég, és ezeknek a hatását is részletezték, amire viszont jelen cikkünkben térünk ki.
A legfontosabb funkcionális újítás, hogy a Radeon Software már tartalmazza a márciusban bemutatott AMD LiquidVR első publikus verzióját, amely az Oculus SDK (0.7 vagy újabb) képességeit egészíti ki, de más VR fejlesztőkörnyezethez is bevethető. Az Oculus SDK-ra való figyelem szokás szerint egyfajta koncepció, mivel ha a VR eszközök terjedni kezdenek, akkor PC-n egyértelműen az Oculus Rift lesz a piacvezető a felkínált szoftveres alap miatt, amelyet a többi konkurens egyelőre nehezen követ le.
[+]
A LiquidVR pár rendkívül fontos extra képességet kínál az alapvető VR fejlesztőkörnyezetekhez. Az egyik legfontosabb funkció a több, egészen pontosa két GPU-s leképzés a virtuális valósághoz, amely az AMD tálalásában Affinity Multi-GPU névre hallgat. Mint ismeretes, a virtuális valóság szempontjából a két szem számára a két képkockát két külön grafikus vezérlő is leképezheti, ami rendkívül hasznos, mert a megjelenítéshez szükséges munkát két külön GPU végzi el a leggyorsabban és a legkisebb késleltetéssel. Ez egyébként a hagyományos értelemben nem tekinthető CrossFire-nek, tehát nem is érdemes úgy gondolni rá.
Az Affinity Multi-GPU érdekessége, hogy az AMD a Mantle API-t használja fel az egyes képkockákhoz tartozó parancsok szegmentálására. Az aktuális szabványos grafikus API-k esetében problémát jelent, hogy tervezésüknél sosem gondoltak arra, hogy a virtuális valóság valaha is létezni fog, így a sztereó 3D-s kép előállítását a processzor oldalán nem szegmentálják. Persze önmagában az nem baj, ha a rajzolási parancsok nem szegmentálva érkeznek meg a grafikus vezérlők felé, de ilyen formában a virtuális valóság két GPU-ra való kiosztása csak úgy oldható meg, ha mindkét GPU kiszámol bizonyos részleteket. Ez némileg korlátozza az elérhető gyorsulást, vagyis leginkább 50-70%-os extra lehetséges a szabványos API-kkal. Az AMD az Affinity Multi-GPU esetében a Mantle API bevetésével képes majdnem kétszeres sebességet elérni, mivel már a parancskiadásnál is ténylegesen elszeparáltan történik a két képkocka számítása.
A másik fontos funkció az asynchronous timewarp, amelyhez a vállalat a GCN és GCN2 architektúra esetében durvaszemcsés, míg a GCN3 architektúránál finomszemcsés preempciót használ. Mindkét esetben elég jól biztosított a timewarp számításának prioritása, de a GCN3 előnye ebből a szempontból vitathatatlan, mivel bármilyen aktuálisan futó feladatot képes ideiglenesen megszakítani, ha egy magasabb prioritású feladat érkezik.
A harmadik fontos extra a Latest Data Latch nevű funkció, amely a fejpozíció kinyerésén javít. Az Oculus SDK szabványos API-kat használ, és ezek nem engedik meg, hogy a jelenetszámításnál használt kamerapozíció megváltozzon a jelenethez tartozó képkocka esetében. Az AMD emiatt először a Mantle API-nak adja át a kamerapozíciót, és a szabványos API-k azt fogják hinni, hogy az a jelenethez használt pozíció volt, így elfogadják azt. Ennek a koncepciónak az előnye, hogy az úgynevezett "motion-to-photon" késleltetés durván a felére csökkenthető, mivel a képkocka számításához felhasznált fejpozíció nem a jelenet kalkulációjának megkezdésekor született meg, hanem pont a jelenetszámítás befejezésekor. Ezzel gyakorlatilag a rendszer mindig a lehető legfrissebb fejpozícióval számol.
A LiquidVR fontos funkciójának tekinthető még a Direct to Display is, amely az Oculus SDK Direct To Rift koncepciójához képest a késleltetés további csökkentését kínálja fel a natív Front Buffer Renderinggel. A LiquidVR futtatási környezet egyelőre Windows 7 és 10 operációs rendszereken érhető el Hawaii, Grenada és Fiji kódnevű GPU-kra épülő Radeonokkal. A virtuális valóság tényleges startjáig a támogatás természetesen bővülni fog.
FreeSync újítások és egyéb nyalánkságok
A Radeon Software javít a FreeSync támogatásán is. Egyrészt ez mostantól minden lehetséges konfigurációra kiterjed, így akármilyen grafikus API-ra írt programmal, akármennyi Radeonnal, akármennyi kijelzővel üzemképes lesz, persze az elméleti lehetőségeken belül maradva. Ehhez kapcsolódik a Radeon Software új funkciója, amely az LFC, azaz a Low Framerate Compensation névre hallgat. Ez a megfelelő konfigurációkon automatikusan aktiválódik, és akkor segít a jobb élmény elérésében, ha a képfrissítés kisebb, mint a FreeSync kijelző változó frissítési tartományának minimuma.
FreeSync LFC (Low Framerate Compensation) [+]
Az LFC az AMD elmondása szerint egészen pontosan akkor aktiválódik, ha a FreeSync technológiát támogató Radeonra olyan kijelző kerül, ahol a változó frissítési tartomány maximuma két és félszer nagyobb, mint a tartomány minimuma. Például ha a FreeSync minimális frissítése 40 Hz, akkor az LFC aktív lesz, ha a monitor maximális frissítése 100 Hz-nél több.
A Radeon Software számos DirectX 9, 10 és 11 API-n futó játékon is javít valamilyen módon. Többek között a CrossFire rendszerek esetében lesz hasznos a Frame Pacing 3.0, amely DirectX 10 és 11 mellett már DirectX 9 API-val is tökéletesen működik és nagyon kiegyenlített megjelenítést kínál kettő vagy több GPU-val is.
Frame Pacing 3.0 [+]
Lényeges extra lesz a shader cache manuális vezérelhetősége. Maga a shader cache régóta része a meghajtóknak, de az adattárolón elfoglalt méretet az AMD egyénileg paraméterezi az egyes játékokhoz. Ilyen formában a driver nem is foglal le nagy területet a rendszerpartícióból, de ma már annyira nagyok a merevlemezek, vagy akár az SSD-k is, hogy abszolút nem baj, ha a meghajtó esetleg 1 GB-nyi területet is elkölt a lefordított shaderekre. A shader cache beállítás aktiválása ugyanis pontosan azt csinálja, hogy az AMD alapértelmezett optimalizálásait figyelmen kívül hagyja, és a futtatott játékok esetében a lefordított shadereket elkezdi lementeni gyakorlatilag limitációk nélkül.
A shader cache hatása [+]
Ilyenkor persze ne lepődjünk meg, ha 80-90 játék futtatása után eltűnik pár száz megabájt szabad hely a merevlemezről vagy az SSD-ről, ugyanis ezt a lefordított shaderek emésztették fel, és ezek birtokában az újrafordítások nem válnak szükségessé. Ez egyrészt gyorsítja az egyes játékoknál a pályák betöltését, másrészt megszünteti a shader újrafordításból eredő akadásokat. A shader cache alapértelmezetten továbbra is AMD-optimalizált állapotban van a meghajtón belül, de ha az adott rendszerpartíción gigabájtokban mérhető a szabad hely, akkor érdemes bekapcsolt állapotra tenni, mivel így jobb lehet a játékélmény. A kikapcsolt állapotot csak akkor célszerű választani, ha a rendszarpartíción a szabad terület kevesebb mint 200-300 MB.
Érdekes változás még, hogy a Radeon Software továbbfejlesztett shader fordítót is kapott, amelyet az AMD már a DirectX 12-ben található Shader Modell 5.1-hez optimalizált. Részben emiatt 10-20%-kal gyorsabb az új meghajtó a korábbi 15.7.1-es WHQL eszközillesztőhöz viszonyítva a Fable Legends és az Ashes of the Singularity című DirectX 12-es programokban.
Esetlegesen a régebbi API-kat használó játékokban is lehet pár százaléknyi gyorsulásra számítani, de ezek nem annyira jelentősek. Főleg amiatt, mert az AMD a Radeon Software Crimson Edition 15.11-es verziójától kezdve alapértelmezetté tette a csupán egy képkockányi késleltetést a Flip Queue Size paraméter esetén. Ez bizonyos gyors reflexeket igénylő játékoknál, mint például a Counter-Strike: Global Offensive, vagy éppenséggel az összes Mantle API-t használó cím DirectX API-n futó verziójában eleve így volt, de a legtöbb játék esetében a késleltetés kettő vagy három képkocka maradt. Ugyanakkor a DirectX 9, 10 és 11 meghajtón végrehajtott optimalizáció, illetve a virtuális valósággal kapcsolatos kutatások hasznosítása lehetővé tette, hogy minden, előbb említett API-kon futó játék és program bemeneti késleltetése a lehető legalacsonyabb legyen.
Flip Queue Size optimalizálás [+]
Ez konkrétan azt jelenti, hogy ha egy játékos a beviteli eszközön megad egy parancsot, akkor annak az eredménye egy képkockával később már látható lesz, így a bemeneti késleltetés felére vagy harmadára csökken a korábbi meghajtókhoz viszonyítva.
Végül javult a nyáron bemutatott Frame Rate Target Control, vagyis az FRTC szolgáltatás is, amelyen belül korlátozható a programok futtatási sebessége, így energiát lehet spórolni. A támogatás a DirectX 10 és 11 után a DirectX 9 API-t használó programokra is elérhető, illetve a PowerTune profilok optimalizálásával az egész rendszer hatékonysága lényegesen javult.
[+]
Példaként említve a Catalyst 15.7.1-es meghajtó esetében az FRTC 60 és 55 képkocka/másodpercre való korlátozása 50 watt megspórolását tette lehetővé a BioShock Infinite, és 90 watt megtakarítást ért a Sniper Elite 3 című játék alatt az AMD Radeon Fury X VGA-val. Ugyanilyen körülmények között a Radeon Software Crimson Edition 15.11-es verziójával már 107 és 190 watt energiát sikerült megspórolni, vagyis lényegesen nőtt a funkció hatékonysága. Emellett az FRTC képességei is javultak, mivel az eddigi 55-95 képkocka/másodperces tartományt az AMD kiterjesztette 30-200 képkocka/másodpercre.
Kijelzőkezelés és multimédia
Sok változás érte még a kijelzőkezelést. Egyrészt a kijelzők inicializálása háromszor gyorsabb lett, illetve mostantól adott a lehetőség az egyéni felbontások, időzítési paraméterek, frissítések, illetve pixelórajelek beállítására is. Utóbbi funkció elsősorban a profi felhasználóknak szól.
[+]
Sokkal érdekesebb azonban az egy évvel korábban bemutatott virtuális szuperfelbontás kiterjesztése. Ez eredetileg csak a játékokra vonatkozott, de a Radeon Software Crimson Edition 15.11 lehetővé teszi a Windows 10 operációs rendszer munkaasztalához való használatát is, ha az adott kijelző képpontsűrűsége legalább 150 ppi, azaz egy hüvelyknyi területen legalább 150 pixel található. Ilyen esetében például úgy is be lehet állítani mondjuk a 2560x1440-es felbontást, ha a kijelző maximum csak 1920x1080 pixelt támogat.
[+]
Mivel a skálázás a Radeonok kijelzőmotorjában történik, az egészből a felhasználó csak annyit vesz észre, hogy megnövekedett a munkaasztal mérete, és ehhez még nagyobb felbontást támogató monitorra sem volt szükség.
Multimédiás szempontból megújult pár videókhoz használt utófeldolgozásos szűrő is. Többek között a dinamikus kontraszt mostantól adaptív, vagyis figyelembe veszi a tartalmat a megfelelő eredmény érdekében. Ehhez azonban GCN3 architektúrára épülő Radeonra lesz szükség, vagyis az újítás csak Radeon R9 285, 380, Nano és Fury sorozatú kártyákkal, illetve az APU-k esetében az új, hatodik generációs termékcsaláddal működik.
[+]
Szintén lényeges újítás a direkcionális skálázás, amely javít a 4K felbontáson lejátszott Full HD-s videók minőségén. Mint ismeretes, a hagyományos skálázással az éleken megjelenhetnek a recék, de az AMD adaptív skálázása ezt segít eltüntetni. Az alábbi kép a lényeget bemutatja, de azt meg kell jegyezni, hogy az AMD ezt bevallottan eltúlozta, hogy a különbség kisebb képen is látható legyen. Valójában a hagyományos skálázással nem ennyire rossz az eredmény. Ezt a funkciót a Radeon R9 Nano és Fury sorozat támogatja.
[+]
Végül a Carrizo SoC APU-ra épülő AMD FX-8800P és A10-8700P esetében új utófeldolgozásos szűrők kerülnek bevetésre, amelyek a korábbi szűröknél lényegesen jobban működnek a képminőség javítása szempontjából.
[+]
A fentiek mellett az új meghajtó támogatja a DisplayPort 1.2a-HDMI 2.0 átalakítókat is, amelyek hamarosan megvásárolhatók lesznek.
A Radeon Software Crimson Edition 15.11-es szoftvercsomag és a hozzá tartozó dokumentáció letölthető az AMD szerveréről. Az új meghajtó csak a GCN architektúrára épülő Radeonokat támogatja. Az AMD a Radeon Software mellé egy új Clean Uninstall Utility szoftvert is kínál, hogy a felhasználók ne a harmadik féltől származó drivertörlő programokat használják, bár a törlés elvégzéséhez továbbra is az Install Manager használata ajánlott.
Abu85
