Togl är bara en presentation inte vad exakt de kör. Inte sagt heller att de kör Wine men de gör samma sak, en wrapper som hämtar upp D3D calls och gör om dessa till OpenGL. Shaders kompilerar de vid startup och ibland vid runtime dock är detta ganska prestandakrävande i OpenGL då det skapar stalls.
Detta gör att du har ett extra lager av overhead, inte tal om kod som egentligen inte är anpassad för OpenGL vilket ger ganska dålig spelupplevelse.
Skrivet av Curik:
Vad menar du med gränssnitt? Det lager som brukar sitta ovanför APIt? För det är ju i princip ingen som anpassar motorn för ett specifikt API (ja, förutom Valve verkar det som nu). Både Unreal, Torque, IDTech och Unity gör likadant och det är att man skriver ett lager ovanför grafik-APIt så denna är lätt byta ut mot ett annat API utan att man behöver göra några ändringar i koden som anropar lagret. Men det kanske var det du syftade på.
Hur som helst så tycker jag det låter märkligt med 25% försämrad framerate för att man använder en wrapper. Det är ju inte idioter som jobbar på Valve och Wine använder ju precis som du säger också en wrapper men utan samma prestandaproblem. Det är inte raketforskning direkt och det går ju inte att göra på så otroligt många olika sätt. Och kunde Dynamix göra det på 90-talet med ytterst begränsade resurser så borde fasen Valve kunna det också. Nä, luktar beta-release lång väg.
Tack för länkarna!
Detta händer bara på pappret. Sedan har du specifika calls för olika D3D versioner, olika OS samt olika hårdvara för att exempelvis gå runt problem i drivrutiner eller optimera för hårdvara. IDTech kör OpenGL rakt av vad jag kan minnas även på Windows.
Wrapper gör att den väntar på ett call för D3D och försöker sedan göra något liknande för OpenGL. Problemet är att du inte får direkt anpassad kod för hur OpenGL vill ha det. D3D hanterar och följer sin väg och OpenGL sin egen. Det kräver olika shaders samt hanterar dessa på olika sätt. Sedan har du också att företag kör en target på OpenGL 3.0 istället för senare då det är ett säkert kort för att fungera både på Linux men också Mac.
Exempelvis D3D tycker om att kompilera shaders on the run, gör du något liknande i OpenGL så kommer du få stalls och stuttering. Det är nu när Linux fått lite slag på axeln där det kommer mer platformagnostiska grafikmotorer allt tidigare har varit hårt knutet mot D3D. Unity har fortfarande uselt stöd för OpenGL och är också orsaken till den dåliga prestanda man ser på alla Unity spel på Linux. Unreal Tournament 4 kör på senaste Unreal motorn men fortfarande är exempelvis bara OpenGL 3.x som standard istället för 4 samt mycket efter D3D versionen när det kommer till prestanda.
Sedan kan du lägga på grafikdrivrutiner där alla senaste spel som kommit till Linux (Alien Isolation, Shadow of mordor, mm) kommit med disclaimers att de inte har stöd för AMD drivrutiner utan bara Nvidia, vilket är också resultatet varför alla Steam Machines är Nvidia baserade för inte nog att OpenGL är lite annorlunda mot D3D så har du också problemet att OpenGL skiljer sig mellan AMD, Intel, Nvidia. Skriver du kod så kan den funka på Nvidia men inte på tidigare och tvärtom.
Sedan för att ta upp igen, Wine har extrema prestandaproblem. Wine har fortfarande bara stöd för D3D9 (10an borde bli klar mot slutet av året). Wine är väldigt CPU tungt och har ingen trådning alls när det kommer till OpenGL, CSMT (Commandstream multithreading) var ett steg men stannade av då de behövde skriva om ganska mycket för D3D10+ lär komma efter. Hjälper inte heller att det är bara ca 2 personer som sitter på D3D programmeringen, vilket också är svaret varför de är så efter.
http://boilingsteam.com/codeweavers-on-dx11-in-wine-steam-mac...
Skrivet av anon5930:
Jag är överlag positiv till det mesta som gynnar Linux-distros spelmässigt så Valves Linux-satsning har jag inget emot, även om jag personligen föredrar GOG tack vare DRM-fria stödet. De som hyllar Valve för att de "räddar" Linux gör det på lite osäkra grunder i mitt tycke, ett öppet system borde inte räddas av en låst mjukvarulösning.
Min kritik gäller främst SteamOS och speciellt Steam Machine. Steam Link tycker jag är vettig då det istället är en extender för befintlig dator som kör Steam. Relativt riskfri produkt.
När vi ser till Linux-distributioner där användaren väljer att köra Steam och vill spela så är inte ansvaret helt Valves längre. Men då de troligen kommer gynnas mest av att fler börjar använda Linux så har de fortfarande ett stort ansvar att se till att allt fungerar som förväntat. Jag tycker ändå att tre år borde vara tillräckligt för att ha fått bättre stöd bland spelföretag och hårdvaruutvecklare men detta lämnar ändå en hel del att önska. Samtidigt kan det väl bara bli bättre med förstås.
Valve har haft en vana att låta andra göra jobbet. De marknadsför inte Steam speciellt mycket utan det får spelföretag som publicerar sina spel på tjänsten istället göra. Valve skapar nya sätt att tjäna pengar men jobbet utförs oftast av andra medans Valve drar in pengarna. Spelutvecklingen har mer eller mindre avtagit helt. Vill de ha något spel låter de någon extern studio göra jobbet. En del projekt är lovande, Linux-satsningen är jag egentligen för även om jag inte gillar låsta system vilket Steam trots allt är. VR-satsningen är också lovande. Steam Link känns vettig om man ser den som en extender till befintlig speldator.
SDL har inget med Valve att göra vad jag kan se, förutom att den som varit med och skapat det senare började jobba för Valve.
Vad gäller Vulkan ligger nog AMD bakom mycket av arbetet då det grundar sig på Mantle. Men Valve har garanterat varit delaktiga i någon mån med såklart.
Min kritik står kvar och fyllt ut lite ovan då det var lite otydligt kanske exakt vad jag kritiserade. Men jag tycker ändå att man kan förvänta sig mer av Valve då tre år ändå är ganska lång tid och att de borde ha insett redan från början att spelföretagen och hårdvarutillverkarna kommer bli svåra att få med sig när det inte finns någon marknad. Resultatet ser vi idag, även om det finns lite mer AAA-titlar än jag räknade med när SteamOS / Steam Machine presenterades.
Jag körde för övrigt Linux (främst Ubuntu/Kubuntu) primärt från 2004 till 2008 då jag tillslut gav upp och återvände till Windows. "Year of Linux"-snacket under alla år och insikten om att inget händer fick mig att ledsna, dual-bootade ett tag och blev helt Windows sen. Vill gärna ha tillgång till spel.
Nu ser det lite bättre ut nu men inte en chans att jag byter tills den dag vi får ett bredare spelstöd i Linux-distros och då också spel utanför Steam. Men vem vet vart vi är tre år framåt förvisso.
Problemet ligger så som jag ser det att spelutvecklare väljer Linux väldigt sent i utvecklingen. Dying Light portades av _2_ personer några månader innan lansering och WB tyckte att det bra nog och släppte klossen på Steam. (spelet startar inte sen launch för mig). Alla spel vi ser på Steam för Linux är i princip Unity där utvecklaren allt behöver göra är "press x to release for Linux". Resterande spel är Witcher 2 (som är princip wine) och sedan Feral Interactive som fick upp ögonen för Linux pga Valves satsning och börjat göra ports, även om med bara Nvidia stöd men också kanske inte bästa prestandan.
Utvecklare gör spel för Windows som är D3D baserade, 70% in i utveckling hör sedan chefen Linux buzzwords och tydligen väldigt lätt att porta för. Här står de inför 3 val. Snabb portning inhouse, Dyr portning inhouse eller bara låta någon annan göra jobbet. Vi vet själva vilket händer.
Kort som jag ser problemet på Linux;
Drivrutiner som hamnar efter (speciellt AMD som hinner knappt efter på D3D i Windows).
Företag ser svårt att utveckla för Linux då distros är förvirrande.
Linux inte lönsamt att porta till.
Hur dåliga är drivrutinerna?
Nvidia; har ingen SLI support, deras Optimus stöd har bara börjat (kräver in/ut loggning för att aktivera kortet). Överclockning fanns inte fram till något år sedan. Kontrollpanelen för Nvidia saknar allt som Windows varianten kommer med. De tar även bort stöd för fler än 3 skärmar för att Windows versionen inte klarade av detta. Tearing är något Nvidia ger upp då deras hårdvara är "annorlunda" och går inte fixa.
AMD; Klarar knappt av att lansera drivrutiner för att ha support för Ubuntu (som släpps vart 6e månad), Crossfire är att glömma, OpenGL support finns bara på pappret då det knappt klarar av att köra desktop utan att hänga sig och hela systemet i infinite loops. Mouse corruption som vi hörde så många år sedan på Windows var kvar för något år sedan jag senaste testade multiskärm med AMD.
Körde du en OpenGL kodsnutt på Nvidia och sedan körde samma på AMD så hängde sig datorn plötsligt.
Artiklar om AMD drivrutiner:
http://www.phoronix.com/scan.php?page=news_item&px=MTg1MzM
https://www.gamingonlinux.com/articles/looks-like-shadow-of-m...
http://news.softpedia.com/news/alien-isolation-to-land-on-lin...
Vad har hänt de senaste 3 åren sen första Linux satsningen från Valve.
Valve börjar satsa på Linux, första de gör är skapa Steam Runtime som kommer med programvara tillsammans som alla spel kan använda, detta gör att speltillverkare siktar mot Steam istället för att bry sig om olika distar.
Valve samt flera ser att OpenGL har sina problem som dras efter begynnelse och behöver kapa sin bakåtkompatibilitet och börja färskt. AMD lär aldrig få igång deras OpenGL prestanda lika bra börja från nytt där drivrutinerna inte spelar så stor roll längre. Mantle goes Vulkan.
Valve går med Khronos group samt börjar sponsra OpenSource projekt (LunarG) för att förbättra situatuionen för mesa.
AMD lägger fram Mantle i Khronos group som blir starten för Vulkan, som riktar sig mot prestanda medans OpenGL blir för utvecklare som inte vill skriva 700 rader kod för att visa ett simpelt fönster.
Valve ser att det finns stora problem när det kommer till utvecklarverktyg för OpenGL mot exempelvis D3D och börjar samarbeta med Rad Games för att implementera först program för OpenGL men nu senare verktyg som följer med Vulkan SDK.
Valve lanserar en "spelkonsol" vilket får upp ögonen för andra spelföretag om att kanske ta upp Linux i mötesrummet ännu en gång.
