Az AMD az előző év végén mutatta be a GPUOpen kezdeményezést, amely az idei GDC-n is téma volt, és a vállalat felvázolta, hogy a közeljövőben milyen frissítések várhatók. A koncepció egyes elemei iránt egyre nagyobb az érdeklődés, de az AMD szerint ennél is fontosabb, hogy a fejlesztők kihasználják a MIT licenc biztosította lehetőségeket, ugyanis enélkül nem születhetett volna meg a TressFX-ből a LABS által kidolgozott PureHair effekt, vagy például a GeometryFX-ből a Forstbite Team újszerű, korábbi opcióknál sokkal hatékonyabb kivágási rendszere.
A következő körben a játékfejlesztők igényei teljesülnek. Az AMD már a GPUOpen bemutatásakor elmondta, a piac legnagyobb baja az, hogy a PC-s és a konzolos fejlesztés a multiplatform címeknél elkülönül. Ez nagyrészt annak köszönhető, hogy a két fő platformra elérhető grafikus API-k által kihasználható képességek sokszor döntően különböznek egymástól. Bár a GPUOpen a kezdetben ennek leküzdésére nem tett semmit, de a tavasszal, ezen belül is várhatóan áprilisban érkező frissítés elérhetővé teszi a fejlesztők által legtöbbet használt konzolos képességeket.
Két alapvető újítás érkezik, méghozzá a ReadFirstLine és a Ballot. Az előbbi egy fontos kiegészítés, amivel a fejlesztők képesek redukálni a vektorregiszterek használatát. Ezt az Xbox One és a PlayStation 4 esetében sokat használják, mivel a GCN architektúra esetében a regiszterhasználat határozza meg, hogy mennyi wavefront futhat az adott CU vektorfeldolgozóin. Az ideális kihasználáshoz feldolgozónként hétnél több wavefront kell (leszámítva pár egyedi esetet), és a ReadFirstLine segít ennek elérésben, méghozzá úgy, hogy elmondható a fordítónak, hogy mely értékek állandók az adott wavefronton belül, amely ezeket a skalár regiszterbe is betöltheti. A Ballot szintén hasznos extra a nagyon egyenletes folyamatirányítási esetekben, ahol jelentősen növeli a végrehajtási tempót.
Az AMD a frissítést két csoportba sorolja. Egyrészt a Vulkan API mellett ott van a SPIR-V, amely alapból tartalmaz az előbbi bekezdésben taglalt képességeket. Ezeket csupán használni kell, akár a véglegesítés alatt álló új GLSL specifikációk alapján, vagy egy más shader nyelvhez írt egyedi SPIR-V fordítóval. A DirectX 11 és 12 API-k esetében már bonyolultabb a helyzet, mivel a ReadFirstLine és a Ballot nem definiálja a HLSL és a D3D bájtkód sem. Emiatt az említett DirectX API-khoz az AMD elérhetővé tesz egy-egy HLSL kiterjesztést, amely kihasználhatóvá teszi a ReadFirstLine és a Ballot funkciókat. Ezeket a vállalat úgy írja meg, hogy az Xbox One konzolra megírt speciális HLSL kódokat eleve elfogadja, vagyis a fejlesztőknek csak szállítani kell ezeket a PC-s portba és a meghajtóba épített shader fordító elintézi a többit.
Az AMD a fentiek mellé még további extrákat fog biztosítani, így például PC-n is elérhető lesz a konzolokon sűrűn használ SIMD lane swizzles, valamint az SV_Barycentric. Előbbi egy olyan indexet kínál a fejlesztő számára, amely által módosítható a SIMD-ben található adatok sorrendje, míg utóbbi lehetővé teszi a GCN interpolációjának vezérlését, így PC-re is implementálhatóvá vállnak azok az analitikai élsimítási metódusok, amelyeket a fejlesztők az Xbox One-on használnak. Ezek a funkciók is az Xbox One shader modelljéhez igazodnak, így kvázi módosítás nélkül áthozhatók a fejlesztések.
Az egyes új kiterjesztésekkel frissül a GeometryFX is. Többek között kap egy klaszteres kivágási fázist, valamint implementálásra kerül a Ballot.
Ez az irány már nem csak elméletben, hanem a gyakorlatban is összevonhatóvá teszi a PC-s fejlesztést a konzolossal. Mindemellett a vállalat már dolgozik azon, hogy a DirectX 11 és 12 API-hoz készülő kiterjesztéseik specifikálva legyenek. Ez azért fontos, hogy ne csak GCN architektúrára épülő Radeonokon futhassanak az ezekre épülő eljárások és effektek, ugyanis bizonyos funkciók más gyártó termékein is elérhetők lennének. Ennek érdekében a módosításokat a Microsoft már megkapta, így semmi akadálya annak, hogy megkezdődhessenek a tárgyalások a szabványosításról.
