Azzal, hogy a tegnapi nap során bemutatkozott az új Steam Machine, felmerült az a lehetőség, hogy most már a SteamOS lassan általánosan alkalmas lesz PC-re, hiszen már nem csak kézikonzolhoz használja a Valve.
Bár ez bizonyos szempontból nem annyira kritikus, mert aki Linuxon szeretne játszani, az megoldhatja például a Bazzite disztribúcióval, de a SteamOS-nek azért lényegesen nagyobb a marketingereje, ami segítené a Windows 11-ről való váltást. A kérdés tehát az, hogy mikor lesz olyan állapotban a Valve operációs rendszere, hogy általánosan kiadható legyen, figyelembe véve a bármelyik PC-re való telepíthetőséget.
Hirdetés
A helyzet sajnos nem olyan egyszerű, hogy ezt csak úgy meg lehessen lépni. Technikailag a Valve mondhatja azt, hogy itt van a rendszer, és mindenki használhatja, de a cél az lenne, hogy minden ügyfél jó élményt kapjon vele. Ez pedig már a Bazzite disztribúcióval is látható, hogy jelenleg teljesíthetetlen.
Valójában nem is a gyártókról van szó, mert alapvetően az AMD, az Intel és az NVIDIA driverek is kellemes működést biztosítanak. Persze a Valve számára fontos a nyílt forráskódú komponensek használata, ahol főleg az AMD és az Intel tekinthető erősnek, de már az NVIDIA is belátta, hogy ennek jelentős értékei vannak, így elkezdtek rohanni ebbe az irányba. Eközben vannak zárt gyári meghajtók, tehát a terméktámogatás oldalán azért nem annyira rossz a helyzet, inkább csak lehetne jobb is.
Egy jelentős probléma van, amin jelenleg nagyon nehéz átlépni, ez pedig a Proton kompatibilitási réteghez kapcsolódik, ami Linuxon a Windows operációs rendszerre optimalizált játékok futtatását biztosítja, így a SteamOS-nek is a fő komponense. Ennek a rendszernek a része a Valve által menedzselt VKD3D-Proton, ami specifikusan a DirectX 12 API-t használó játékok futtatását oldja meg Vulkan API-n, illetve a kapcsolódó gyártói implementációkon.
A működést tekintve nincs nagy gond azzal, ahogy a VKD3D-Proton dolgozik, a probléma inkább ott keletkezik, hogy az elérhető hardverek eltérően oldják meg az API-kon belül definiált erőforráshalmazok kezelését. Persze itt felkiállthatunk, hogy eleve az a dolga az API-nak, hogy a különbségeket elfedje, ami tökéletesen igaz, de amikor a programfuttatás nem natívan történik, hanem egy kompatibilitási rétegen keresztül, akkor a nagyon specifikus, natív implementációval is eleve nehezen kezelhető eltérések esetenként nagyon nem fognak optimálisan működni.
A VKD3D-Proton esetében ezt látjuk, hogy a rendszer elég jól dolgozik az AMD és az Intel grafikus vezérlőinek alapvető hátterével, de bizonyos körülmények között gondjai vannak az NVIDIA oldalán, amit elsődlegesen az idéz elő, hogy a VKD3D-Proton a DirectX 12 memóriablokkokat egyetlen nagy leírókészletként emulálja, amit a Vulkan API ugyan jól kezel, de az így generált leírókészletek fizikailag túl nagyok ahhoz, hogy beleférjenek egyetlen uniform pufferbe, ami sokat lassít az NVIDIA GPU-inak teljesítményén. És ez egy hardveres tényező, mivel az NVIDIA zárt meghajtója mellett a nyílt NVK is ugyanilyen problémába fut bele.
Itt felmerül a kérdés, hogy mi a megoldás? Nos, már dolgoznak az érintettek rajta, ugyanis az NVIDIA GPU-knak alapvetően csak az okoz gondot, hogy a specifikusan működő hardverük rosszul reagál arra, hogy a DirectX 12 API működése egy ponton csak a fentebb megemlített módon illeszthető rá optimálisan a Vulkan API-ra. Éppen ezért a Vulkan a jövőben egy új leírómodellt kap, és ez jobban fog illeszkedni ahhoz, amit a Microsoft definiált a Directx 12-ben. Ezzel pedig a DirectX 12 API működése ebből a szempontból jobban ráilleszthető a Vulkan új lehetőségeire a VKD3D-Proton kompatibilitási réteg szempontjából.
A SteamOS tehát jelenleg okkal nem érhető el univerzálisan, mert gyakorlatilag olyan minőségben, amit a Valve jelenleg elvár, PC-s szinten csak az AMD hardvereivel működik, és bizonyos problémák az NVIDIA oldalán nem oldhatók meg pusztán egy nyílt forráskódú driverrel, de szerencsére a háttérben pont folynak azok a fejlesztések, amelyek hosszabb távon ezt az operációs rendszert mindenki számára használhatóvá tehetik.
