Kicsivel több mint egy éve mutatkozott be a TressFX technológia, ami elsőként használta a grafikus processzor erejét a haj fizikai szimulációjának megvalósítására. Azóta az algoritmus már a 2.0-s verziót is megélte, mely főleg a teljesítményre volt pozitív hatással, ám idén nem csak egy szimpla ráncfelvarrás készül, hanem egy komplett továbbfejlesztés, így a haj szimulálása mellett a szőr és a fű is szerepet kap. Erre az AMD szerint azért van lehetősége, mert a szimuláció szempontjából nagyjából ugyanazokat a problémákat kell megoldani az előbbi három esetben. Bár ezek megvalósítása így is különbözik, az alapok ettől még megegyeznek. Természetesen a komplexitás szempontjából a haj szimulálása a legnehezebb, míg a szőr és a fű tulajdonképpen a hajra használt algoritmus kvázi butításával oldható meg.
A TressFX a hajra vonatkozóan továbbra is fontos szerepet kap, így a rendszer a 2.0-s verzióhoz képest további optimalizálásban részesült. Többek között az effekthez használt két UAV mostantól RWTexture2D objektumot alkalmaz, ami a gyorsítótárak hatékonyabb használatához vezet, ezzel tovább nő a teljesítmény. Az optimalizálásokat az AMD átmentette a szőrre és a fűre is, így ezek szimulációja is az aktuális leggyorsabb kóddal valósulhat meg. A leképzés esetében a K puffert is optimalizálás érte. Itt alapvetően arról van szó, hogy a számos fragment adatot megfelelően kell feldolgozni annak érdekében, hogy a haj-, szőr- és fűszálak leképzése jó sorrendben történjen. Ez a rendszer legkritikusabb része. Összességében jó lenne, ha az egész folyamat nem csak hibátlan eredményt adna, de gyorsan végezne a számításokkal, viszont ez nem ilyen egyszerű, mivel a leképzéshez szükséges fragment adat csak akkor határozható meg, ha a program minden fragmentet megvizsgált. Ez komoly terhelés a hardvernek, így az AMD egy fontos változásra szánta el magát, mivel bevezettek egy úgynevezett mutex-alapú zárolási sémát, ami biztosan kétes fogadtatásban részesül majd.
TressFX a Lichdom: Battlemage című játékban [+]
A fentieket egyszerűbb megérteni akkor, ha a mutex-alapú zárolási séma lényegét elemezzük. Ez egy olyan koncepció, amely a grafikus API-n belül a shadereket próbálja várakoztatni, illetve elzárja az erőforrásokat, így azokba csak meghatározott esetben írhatnak a shaderek. A TressFX-re lebontva lényegében az történik, hogy a hardver rendkívül agresszív módszerekkel próbálja úgymond kierőszakolni az egyes elemek jó sorrendben történő leképzését. Gyakorlatilag az AMD koncepciója megpróbálja elkerülni a sok erőforrást felemésztő sorba rendezést, és relatíve kis erőforrás befektetésével megszerezni a kívánt adatot. Elvben ezzel semmi gond nincs, hiszen egy olyan eljárásról van szó, amely elméletben ugyanazt az eredményt adja, csak éppen sokkal gyorsabban.
A gond ott kezdődik, hogy az elmélet sokszor nem ültethető át a gyakorlatba. A mutex-alapú zárolási séma a DirectX API-ban egy nem ajánlott megoldás az egyes problémákra, mivel nem mondható stabilnak. Bizonyos hardvereken esetleg működhet, de hiába a szabványos kód, magának a DirectX-nek a része az a megkötés, mely szerint minden shader akkor futhat, amikor arra lehetőség adódik, és csak a felfüggesztésükre van mód, ha esetleg egy adatra várnak, így ilyenkor más shadereket futtathatnak a hardverek, amíg a szükséges adat meg nem érkezik. Szándékosan akadályozott feldolgozás mellett nincs arra garancia, hogy minden egyes hardveren tökéletes lesz a működés, függetlenül attól, hogy a mesterséges korlátozások bevezetése a futtatásra vonatkozóan most a jó ügyet, azaz a gyorsabb feldolgozást szolgálják. Esetlegesen jön a Battlefield 4-ből ismert üzenet, mely szerint az erőforrás eltűnt a program alól (DXGI_ERROR_DEVICE_HUNG), ami jó indok arra, hogy mutex-alapú zárolási sémával miért nem ajánlott PC-s programot kiadni.
TressFX szimuláció a szőrre
A fentiek mellett persze alternatívát képezhetnek az aktuális DirectX-nél modernebb API-k, mint a Mantle és a két konzol megoldása, melyek szerencsére nem az évek óta elavult feldolgozási koncepciókat erőltetik az alapvetően rendkívül modern hardverekre. Ez azonban nem oldja meg a DirectX alatti problémát, így a fejlesztők számára fontos kérdés lesz, hogy engedélyezik-e a mutex-alapú zárolási sémát használó effektet az összes hardverre, vagy inkább nem kockáztatnak. Elvi szinten nem olyan kritikus a helyzet, de a Battlefield 4-ből látjuk, hogy a játék megjelenése után lehetnek stabilitási gondok, amelyekre a tesztelés során nem derült fény, de önmagában a fejlesztők számára is rendkívül kellemetlen lehet, hogy nem ajánlott eljárásokhoz kell nyúlni a jobb sebesség érdekében.
A fű szimulációja szempontjából érdekes kérdés lesz még a környezettel való interakció. Ez a haj és a szőr szimulálása során nem túl lényeges szempont, így elég az adott karaktermodellre lekorlátozni a rendszert, de a fű esetében a legtöbb játékelemre érdemes ütközésdetektálást végezni. Utóbbi természetesen kihagyható, de nélküle nem lesz igazán szép az eredmény, noha kétségtelen tény, hogy a játékmenetre nincs hatással. Ezzel kapcsolatban az AMD dolgozik egy olyan koncepción, mely teljes mértékben része a játéknak, így tulajdonképpen minden fizikai hatás a szimuláció része lehet. A nehézséget az adja, hogy a TressFX esetében a szimuláció a grafikus vezérlőn történik, vagyis technikailag a jelenet számítása után. Az elsődleges ötlet, hogy a szimuláció legyen része a jelenetnek, ahogy azt például a Crysis 3-ban láthatták a játékosok. Viszont ilyenkor rendkívül sok adatmásolás szükséges a CPU és a dedikált GPU között, ami lényegében rosszabb sebességet ad, mintha a CPU egymagában kiszámolná az egészet. Nem véletlen, hogy a Crytek sem a GPGPU-t választotta. Az AMD ezt úgy gondolta tovább, hogy a szimulációt elvégezhetné a legtöbb processzor mellett megtalálható IGP. Ez egyrészt rengeteg számítási kapacitást koncentrálna egy feladatra, így a szimuláció minősége jelentősen javulna, másrészt az IGP személyében egy jellemzően kihasználatlan erőforrásról van szó, tehát a sebességvesztés sem lenne túlzottan komoly, illetve felszabadulna az erőforrás a processzor oldalán, amit fel lehetne használni másra.
HSA-s TressFX szimuláció a fűre [+]
A fentiekre vonatkozóan készül egy technikai demonstráció, mely a fű szimulációját a Kaveri APU-n oldja meg a HSA segítségével, míg a grafikai számításokat egy dedikált GPU ugyanúgy elintézi, ahogy korábban. A HSA-s rendszer előnye, hogy legacy módban ugyanaz a kód bármilyen szimpla processzoron működőképes, hiszen az SSE2-nél modernebb utasításkészletek támogatásán túl, automatikusan generál AVX, illetve AVX2 kódot is. A számítási kapacitásnak persze meg kell lennie a processzor oldalán, de a szimuláció minősége állítható, így opcionálisan az ezzel járó kalkulációk is csökkenthetők.
Lényeges adat még, hogy az alaposan továbbfejlesztett TressFX forráskódja továbbra is nyílt lesz. Ennek az új generációs konzolok szempontjából fontos szerepe van, mivel így a fejlesztő felhasználhatja a rendszert az Xbox One-hoz és a PlayStation 4-hez is. Ezeket az AMD direkten nem támogatja, de a forráskód teljes ismeretében a portolás jóval kisebb munka, mint nulláról elkezdeni a kutatásokat.
