Amikor az AMD bemutatta a Radeon Software-t, akkor nem is meghajtónak, hanem konkrétan mini OS-nek hívta. Ennek akkor az ég világon semmi értelme nem volt, mert valójában nem volt más, mint egy eszközillesztő, ugyanakkor mára látszik valami, hogy mi is volt a célja a cégnek a korábbi felület leváltásával. Bekerültek ugyanis olyan dolgok, amelyek konkrétan külső segédprogramok funkcióit biztosították integrálva. Ilyen volt a Radeon ReLive, ami kiváltotta az OBS, illetve a Raptr felvevő és streamelő moduljait, de a Radeon Chill is konkrétan egy Chill nevű alkalmazás továbbfejlesztése, immáron beépítve a meghajtóba.
Mindkettőt okkal csinálta az AMD, mivel integrálva sokkal jobb munkát lehet végezni. Erről leginkább a Chillt fejlesztő HiAlgo tudna mesélni, akik a saját programjukkal csak DirectX 9-re tudtak támogatást írni, annak ellenére, hogy nagyon sokáig dolgoztak az újabb DirectX-es programok kezelésén, de állításuk szerint egyetlen gyártó sem volt hajlandó megosztani velük a meghajtók forráskódját. Az AMD azonban felismerte a Chillben a lehetőséget, és megoldotta a problémát azzal, hogy felvásárolta a HiAlgo nevű céget. Azóta a Radeon Chill működik DirectX 10, 11 és 12 API-ra írt alkalmazással is, tehát a fejlesztők viszonylag gyorsan el tudták készíteni az alapszintű támogatást, miután láthatták az implementációk forráskódját.
Az integrálásnak tehát alapvető előnyei vannak, és úgy néz ki, hogy ez a folyamat az AMD oldalán nem áll le. Készülnek ugyanis új meghajtók, amelyek lassan feltűnnek a partnereknél, és látható, hogy milyen modulokat tartalmaznak. Az egyik ilyen újdonság a beépített teljesítménymonitorozót és OSD felületet lesz, amit korábban már leleplezett a cég, tehát friss hírként aligha lehetne tálalni. Kiderült azonban a fejlesztés oka, ami a DirectX 12 és a Vulkan API-ra írt applikációk, amelyek nagyon érzékenyek ezekre a külső segédprogramból erőltetett OSD felületekre. Bár az érintettek ezen próbálnak javítani, de valamilyen szintű instabilitás megmarad, amire máig panaszkodnak a játékfejlesztők.
Az OSD felület előzetese a Redux kódnevű meghajtóból [+]
A probléma nagyjából ugyanaz, mint a Chill esetében. A harmadik féltől származó programok fejlesztői nem ismerik az adott gyártó meghajtóimplementációját, és tulajdonképpen esélyük sincs arra, hogy megkapják a forráskódot, arra pedig aztán végkép semmi lehetőség, hogy ennek ismerete nélkül maguk írjanak kiegészítéseket a gyártók meghajtóiba. A potenciális instabilitás viszont csak így üthető ki, tehát jelen helyzetben az tűnik a legjobb megoldásnak, ha integrálásra kerül egy OSD felület a meghajtóba.
Újdonság, hogy ennek része lesz egy beépített teljesítménymérő is, mivel a DirectX 12 és a Vulkan API-ra írt alkalmazások ismét csak azzal küzdenek, hogy külső programmal nehéz mérni a sebességüket. Gyakorlatilag az OCAT az egyetlen olyan alkalmazás, amely multi-engine környezetű feldolgozás mellett is pontosan mér, de ez a legkevésbé sem felhasználóbarát, bár kétségtelen, hogy az esetek többségében elvégzi a dolgát, és aktívan fejlesztik. Valószínű azonban, hogy a játékosok valami egyszerűbbre vágynak, és emiatt az AMD azon dolgozik, hogy integráljon egy átláthatóbb megoldást a problémára.
A harmadik modul, ami feltűnt, nehezebben értelmezhető, de van benne ráció: viszonylag sok PC-s játékos szeret használni különböző shader injektálással dolgozó segédprogramokat. Ilyen például a ReShade vagy az ENBSeries, ezek azonban nem üzemképesek a DirectX 12 és a Vulkan API-ra írt alkalmazásokkal. Bár a fejlesztők próbálkoznak az implementálással, egyelőre igen komoly falakba ütköznek. Sajnos mára kiderült, hogy normális minőségű támogatást csak akkor tudnak nyújtani, ha ismerhetik a meghajtóimplementációk forráskódját, és kiegészíthetik azt. És eljutottunk ugyanahhoz a sztorihoz még egyszer, ezt a gyártók nem fogják nekik biztosítani, ami elég sok fejhasználót fog szomorúsággal eltölteni. Van egy réteg ugyanis, amely elsődlegesen azért szereti a PC-t, mert utólagosan konfigurálható a megjelenítés a közösség által készített shaderekkel.
Az AMD azonban dolgozik egy olyan injektor modulon, amely kiváltja az előző bekezdésben említett segédprogramokat, és tulajdonképpen felkínálja ezek funkcionalitását, immáron integrálva. Ennek az elsődleges haszna nyilván a DirectX 12 és a Vulkan API-ra írt játékok támogatása, máshogy ugyanis ezek az injektált shaderek nem erőszakolhatók rá a programra.
A shader injektáló modul egyébként a fenti újítások között is viszonylag frissnek számít, tehát bőven elképzelhető, hogy a következő nagyobb frissítés csak az OSD felületre és a beépített teljesítménymérőre koncentrál. Az irány azonban egyértelmű, az új API-k mellett bizonyos korábban megszokott segédprogramok üzemképtelenek, vagy instabilitást okoznak, emiatt a sokak által használt szolgáltatásaikat ki kell váltani integrált megoldásokkal. Utóbbi előnye, hogy olyanok írják meg a kódot, akik ismerik a meghajtó explicit API-khoz írt implementációinak a forráskódját, illetve tetszőlegesen ki is tudják egészíteni azt, ha erre szükség lenne, ellentétben azokkal a programozókkal, akik külső segédprogramot fejlesztenek. Ennek pedig komoly jelentősége van, visszautalva a második bekezdésben taglalt Chill programra, ahol a HiAlgo, külsős fejlesztőként aligha tudott volna túllépni a DirectX 9-en. És nem azért, mert rossz programozók, hanem leginkább azért, mert olyan rendszerek működését próbálták befolyásolni, amelyeknek nem ismerték a forráskódját.
A külsős fejlesztők számára az AMD hozzáállása azonban problémás. Gyakorlatilag azzal, hogy a cég eldöntötte ezt az integrálós irányt, elszívja előlük a levegőt. Továbbá a konkurens NVIDIA jó eséllyel követni fogja az AMD-t, ugyanis gyári szinten mindenből jobb minőséget lehet biztosítani, főleg úgy, hogy DirectX 12 és Vulkan API alatt másképp nem is nagyon működnek bizonyos korábban kedvelt, mondhatni igen speciális szolgáltatások. Öröm az ürömben persze, hogy a gyári szintű integrációkhoz garancia is jár, tehát az egyes hibákra többet nem mondhatják boci szemekkel és széttárt karokkal a cégek, hogy nem ők fejlesztették a segédprogramot.
