A Valve projektjének kritikus része a Proton, amely biztosítja azt a Wine-alapú kompatibilitási réteget, amivel a Windows játékok egyáltalán elindíthatók Linux alatt, ezen belül is SteamOS-en. A Proton egyik fő komponensének a VKD3D-Proton számít, ez teszi lehetővé a DirectX 12 API-t használó címek, Vulkan API-n való futtatását.
Hirdetés
Ennek a komponensnek érkezett most meg a 3.0-s verziója, amelyen belül a Valve-nak először sikerült integrálnia egy AI felskálázót. Itt konkrétan az AMD-féle FSR 4-ről van szó, amit átdolgoztak, ugyanis a hivatalos gyári kód az AGS-en keresztül használja a WMMA intrinsics funkciót, vagyis nem szabványos formában van megírva. A Valve azonban az FSR 4-et a VK_KHR_cooperative_matrix és a VK_KHR_shader_float8 kiterjesztéseken keresztül implementálta, ami már szabványos, vagyis papíron minden olyan hardveren működik, amely támogatja az előbbi két kiterjesztést.
A gyakorlatban ugyanakkor nehezebb a helyzet, mert shaderek az AMD dizájnjára vannak szabva, többek között olyan mátrixelrendezést használnak, ami nehezen működik a konkurens hardvereken, a fenti kiterjesztések ellenére is. Ez az AI megoldások tipikus hátránya manapság, hiába vannak az API-n belül szabványos lehetőségek, a GPU-k optimális működése sokszor specifikusan viselkedő kódot igényel, vagyis jelenleg nem igazán lehet olyan shadert írni, ami minden hardvernek jó, mivel az egyes részletek szabványosítása elképesztően nehéz.
Az előző bekezdésben kifejtett gond az oka például az AMD és a Sony együttműködésének az Amethyst kódnevű projekten belül, ahol a két cég vállalta, hogy egymásra szabja a kódjait. Hiába van ugyanis az API-kban szabványos lehetőség a neuronhálót feldolgozó hardverek elérésére, ha azok sokszor egészen eltérő mátrixelrendezést igényelnek a shader kódokban. Kvázi ugyanezzel küzd most a Valve is, így hiába implementálták szabványosan Vulkan API-ra az FSR 4-et, a kód teljesen az AMD RDNA 4 dizájnjának mátrixfeldolgozójára van szabva. A konkurens GPU-k persze elvben képesek futtatni, de jelentős teljesítményt veszítenek ezáltal.
A Valve készített még egy alternatív, amolyan hackelt verziót is 8 bites integer és 16 bites lebegőpontos adattípusra optimalizálva. Ez az RDNA 2 és 3 dizájnokhoz optimális, hiszen ezek nem támogatják a 8 bites lebegőpontos formátumot, de magát az FSR 4-et képesek futtatni, ha az említett adattípus nem követelmény a kódban. Ez viszont szintén jár némi sebességvesztéssel, illetve a neuronháló alapvetően 8 bites lebegőpontos formátumra van optimalizálva, így enyhébb mértékben a képminőség is romolhat, ha nem ezen történik a feldolgozás.
A vállalat a VKD3D-Proton 3.0-s kiadását az FSR 4 szempontjából egyelőre lekorlátozták az RDNA 4 architektúrát használó Radeonokra, mivel ezzel garantálható a jó sebességű és minőségű eredmény. Viszont az alábbi GitHub oldalon elérhető kódban a további implementációk is elérhetők, tehát ha valaki lefordítja a megfelelő flagekkel, akkor megkapja az FSR 4 működését a többi hardveren is, nyilván a fentebb említett limitációkkal. A Valve elvileg dolgozik egy olyan megoldáson is, ami az FSR 4-et a jelenleginél jobb módon engedélyezné a többi GPU-ra, de erről még semmit sem tudni.
