Az elmúlt héten számoltunk be arról, hogy az AMD, Radeon Rays nevű ray intersection megoldásának 4.0-s fejlesztése a korábbi trendekkel szembemenve nem nyílt forráskóddal jelenik meg, ami például elég nagy probléma a Steam Audio 2.0 számára, hiszen a Valve a hangszámítás GPU-n történű, valós idejű szimulációjára vonatkozó hátteret erre a rendszerre építette fel.
Friss fejlemény azonban, hogy az AMD nemrég bejelentette, hogy a Radeon Rays 4.0 nagyrészt mégis nyílt forráskódú lesz. Arról nem írt a cég, hogy miért gondolták meg magukat, de valószínűleg egyáltalán nem tetszett az eredeti fejlemény a Valve-nak, illetve a Steam Audio 2.0-t erősen támogató videojáték-motor (Unity és Unreal Engine) esetében a fejlesztőknek. Az érintettek egyszerűen már túl sok erőforrást öltek az egészbe, hogy visszaforduljanak, így gyakorlatilag az egész koncepció létkérdésévé vált, hogy a DirectX 12, a Metal, illetve a Vulkan API-kat natív támogató Radeon Rays rendszert milyen formában kapják meg.
Tudni kell azonban, hogy a Radeon Rays 4.0 így sem lesz úgy elérhető, ahogy a Radeon Rays 2.0. A rendszer nagy része ugyan nyílt forráskódúvá válik, de az AMD a zárt modulokat csak egyedi igény esetén teszi hozzáférhetővé. Mindez valószínűleg elég a Valve, illetve a további partnerek számára, mivel így legalább nincsenek rákényszerítve arra, hogy saját kézbe vegyék a problémát, és elkezdjék vadul átírni a Radeon Rays 2.0-t. Ugyanakkor az egyes új modulok láthatóan zártak maradnak, vagyis ezeket az AMD alapvetően zárt könyvtárakban szállítja, az érdeklődők pedig SLA-val (Service Level Agreement) kérhetik a forráskódot. Itt úgy tudjuk, hogy a fixfunkciós Radeon IP-kre szabott BVH gyorsítóstruktúráról, illetve az egyedi AABB hierarchiáról van szó. Na most a jó hír, hogy alapvetően ezek nélkül is működik a Radeon Rays 4.0, annyi különbség lesz, hogy a sugárkövetés során nem használja majd a fixfunkciós részegységeket, de a hangszámítás tekintetében az erre vonatkozó terhelés eléggé kicsi, tehát a mai izmos GPU-kon játszva megoldható a probléma egy-két multiprocesszor erejéből. Ha egy fejlesztő mégis szeretne hardveres gyorsítást az RDNA 2 architektúrára épülő Radeonokra, akkor nyilván ez a zárt modulokkal megoldható.
Arról nincs adat, hogy az érintett modulok miért lesznek lezárva. Lehetséges, hogy tartalmazhatnak olyan kódokat, amelyek a Microsoft, illetve a Sony konzoljaira is vonatkoznak, így az adott konzolgyártónak, esetleg mindkettőnek direkt beleszólása van, hogy ezek milyen licenc mellett érhetők el. Mindezeken túl, viszont az is elképzelhető, hogy az AMD nem szeretné, ha a konkurens Intel és NVIDIA beépítené a Radeon Rays 4.0-ba az ilyen jellegű moduljait. Utóbbi oka pusztán üzletstratégiai szempont lehet: az AMD túl sok pénzt és energiát fordított arra, hogy 3D-s hangzás legyen PC-n, és számukra ennek akkor van értelme, ha az RDNA 2 architektúrára épülő Radeonokon mehet a hardveres gyorsítás, míg a konkurens grafikus vezérlőkön nem, vagy ha engedik, akkor is kontrollálni szeretnék a kinyerhető teljesítményt.
Végeredményben valamelyest javult a helyzet, hiszen a változásokkal a Valve, illetve a nagy partnernek számító Unity és Unreal Engine videojáték-motorok fejlesztői építhetnek a Radeon Rays 4.0-ra, annak zárt moduljait pedig majd eldöntik az egyes stúdiók, hogy beépítik-e vagy sem.
