Gabe Newell: "Linux är framtiden för spel – ny hårdvara på ingång"

Kör dual boot och använd bara Windows för de spel som inte funkar i Linux så minimerar du tiden du måste lida i Windows. Då hinner du lära dig och förbereda dig inför den eventuella framtid då alla spel du behöver funkar i Linux. På köpet får du en mycket roligare dator.

Upplevde själv när jag bytte till Linux att datorn blev rolig att använda igen. Det var ungefär när Vista kom jag bestämde mig att Windows har ingen framtid, det passar inte mig längre (gjorde mina första försök tidigt 2008). Ju fortare jag lär mig Linux desto bättre. Visst det tog några år innan jag slängde ut Windows helt (2011 ungefär) men det var det värt. Var beredd på viss frustration i början när det inte funkar som man är van men så småningom kanske man lär sig om man bara ger det lite tid.

Bara för att ge den andra sidan på myntet en chans.

Personligen har jag det tvärt om, gick från Diverse OS till Windows, och gillar OSet mer och mer för varje version i princip, med några undantag iofs.
Kört Linux i flera år men insåg tillslut att det inte var hållbart och att jag faktiskt fick en roligare dator, utan linux. Diverse seriösa kernelbuggar och brist på stöd vid bekymmer hjälpte inte direkt heller. Antalet fördelar för mig personligen med Linux idag är väldigt få, men visst finns de.

Har kört allt från OS X, Mac OS 6-9, BeOS, Linux etc hemma. Men jag föredrar för enkelhetens skull windows, jag vill få mitt arbete gjort och att all tillgänglig programvara, drivrutiner för udda saker, spel, färgprofiler och sådant bara ska fungera. Vilket det också gör.

Nej, det ryktas vara BSD-baserat och är definitivt ingen GPL-baserad GNU/Linux-kärna. Det är t o m mer än ett rykte då de hänvisar till att de forkat FreeBSD i början av 2005. Playstation 4 har troligen också ett FreeBSD-baserat OS. De använder inte mycket till userland så de behöver inte en komplett Linux-dist eller särskilt mycket mer än en kernel, de skriver egna APIer och drivrutinsmodeller. Byggmiljön körs ju på Windows och det är GCC med pthreadsstöd och köret. BSD passar där, licensieringen är enkel och det gör vad de behöver. De skulle även kunna köra något RTOS säkert, mycket är specialutvecklat och kommer bara höra hemma på deras produkt. Den är inte beroende av någon OSS-miljö eller av att publicera källkoden, de skulle inte använda nya modeller för drivrutiner eller uppdatera kerneln om de körde Linux så behovet är väldigt litet för något sådant och de kommer definitivt inte köra standardapier eller X/Wayland ändå.

SteamOS är något helt annat, det är en Linux-distribution. Det blir precis så bra eller dåligt som deras partners som ska implementera det hela gör det till.

OpenGL används inte på Playstation alls, PS3 har via PSGL stöd för OpenGL ES 1.0 + Cg (shader) plus några ES 1.1 extensions och annat. Så det motsvarar snarare OpenGL 1.5 + Cg. Fast det är mycket vanligare att köra LibGCM eller PhyreEngine i spelmotorerna. PS4 har GNM och GNMX, PhyreEngine och lite annat som byggs på nativeapierna GNM/GNMX. PS4as shaderspråk PSSL är eget, men är liknande HLSL det är alltså inte HLSL men kompatibelt nog för att kunna portera. Du kan portera HLSL till GLSL för den delen med, och OpenGL ser till att vara featurekompatibel och går ibland (fortfarande) före D3D med nya features. Även med native-apierna på lägre nivå kan du göra samma saker och få motsvarande resultat, så apierna ska man definitivt inte hänga upp sig på. Spelutvecklarna skriver spelen för motorerna, motorerna har ofta egna shaderspråk och renderingensvägen och liknande går att byta ut.

Nej, men det finns delvist öppen information som sagt, både från konsolutvecklarna och spelutvecklarna och det är ju det normala då det behandlas inom akademiska cirklar så väl som proffs som håller föredrag inom branschen. Det stämmer även om konsoltillverkarna håller ganska hårt på sin information.

DX eller OGL på en PC är ju en extra abstraktion från drivrutinen som har funktioner för allt internt, som abstraherar från hårdvaran. Konsoler brukar ha APIer som är något mellanting av dessa så väl som mer hårdvarunära, mellan den interna funktionen i drivrutinerna och APIer med ganska stor overhead. Eftersom funktionerna finns där både i hårdvara och drivrutin och man kan till stor del med maskinkraft skriva om kod och översätta den till andra format t ex shaderkod så blir det inte så viktigt vilket api det handlar om. Shaderkod måste t ex drivrutinen kompilera om för hårdvaran, därför konsoler tillåter där prestandan flaskar att man går runt detta och ibland skriver gpu microcode direkt och då hoppar över ett steg (två om motorn omvandlar eller genererar shaderkoden du behöver inte generera shadern, shadern behövs inte göras om till maskinkod, och är optimerad för hårdvaran direkt vilket drivrutinen kanske inte alltid kan på samma sätt).

Spelen kan visserligen främst vara utvecklade för HLSL och DX, men de som utvecklar modeller inom spelet har ju inget att göra med DX utan de använder sina modelleringsverktyg och spelutvecklarnas egna verktyg. Många spel kör också egna shadingspråk och måste iaf konvertera detta till vad plattformen kör inuti motorn. Renderingsdelen går ofta att implementera så gott som identisk med ett annat API, samma funktioner och effekter finns ju där oftast både i API och hårdvara, och det finns alltid tillägg till apierna på skrivbordssidan för funktioner som inte kommit med vid standardiseringen av API:t. På konsolerna kan man implementera allt som hårdvaran klarar, teknikerna blir i slutänden det samma oavsett API så vida det inte är något specifikt som är ett specialfall. Att skriva en ren wrapper brukar vara en dålig idé så det brukar bli något mellanting, ett lågnivå-api har ju inte samma automatik så vissa av delarna behöver man implementera själv oavsett om de emulerar beteendet av orginalmålet eller inte.

Blir alltid bättre när de lägger ner jobb på spelmotorn istället för att försöka ta en genväg. En wrapper för ett helt system som WINE eller Cider är inte att rekommendera någonstans, men kan fungera. Att göra samma sak för enbart D3D är inte heller någon bra idé utan man måste in och ändra lite också. Fast det är inga gigantiska resurser, t ex som 3 personer som arbetar med porten till PS4-versionen på ett spel som förhoppningsvis säljer miljoner exemplar. Finns också spelmotorer som stödjer olika plattformar bra nog för att den av samma team ska kunna utvecklas till olika plattformar parallellt, även indieutvecklare klarar t ex Mac och Windows-släpp om de använder en motor som är mogen på båda, motsvarande med konsolerna även om det brukar krävas lite mer specialkunskaper där beroende på hur hårt man pressar dem.

Det finns ju en anledning till att Gabe vågar släppa en Steam-plattform som bara är en GNU/Linux-dist med Nvidiagrafik, tyvärr räcker inte riktigt det för att Nvidia och andra ska skärpa sig på grafikkortssidan och lite mer för att standardisera borde de göra. Blir plattformen (operativet) underhållen blir den inte sämre än något annat och det ger en kanal in på den plattformen. Fast det blir såklart till stor del beroende av att spelmotorer som deras egna Source möjliggör det hela.

Det beror också på i vilket avseende man anser att just Nvidia ska skärpa sig. Prestandamässigt levererar Nvidia likvärdiga drivrutiner. Följande information om samarbete mellan Red Hat och Nvidia kan kanske ge Nvidia några klappar på ryggen. Kanske övertolkar jag nyhetsflödet, men det tycks som att en hel del börjar falla på plats för Valve.

Inte riktigt, syftade på kvalité och underhåll, använda samma öppna komponenter som andra och ligga mer inline med förändringarna i kerneln och underhåll än att förse binärer som implementerar egna varianter och inte kommer vara kompatibelt med särskilt många Xorg-versioner varken nya eller gamla som därför inte kommer fungera med alla distributioner. Proprietära drivrutiner kommer inte fungera med Wayland och liknande, de använder inte KMS eller kommer vara integrerade med kerneln på något vettigt sett. Grafikkort blir snabbt värdelösa och oanvändbara med nuvarande modell tillsammans med de stängda drivrutinerna. Sådana som Canonical backportar inte Xorg eller drivrutiner. Det kommer vara svår att hålla off the shelf-hårdvara rullande med det hela. Att inte lägga ner mer på plattformen och inte tvinga partners att göra det blir att det egentligen inte blir något speciellt av det. På Android måste partnern se till att drivrutiner fungerar osv, här blir det väldigt flytande och det finns inte tryck på Nvidia alls när de använder binära drivrutiner de laddar ner från deras hemsida. Det finns ingen uttalad miniminivå. De hade kunnat krävt stöd på API-nivå, de kommer inte ha något stöd för patenterad video i sin distribution och kommer t ex inte kräva OpenMAX. På Android är det något telefontillverkarna behöver betala tiotals miljarder för att bara spela upp video.

Fast nu är du inne på drömscenariot Petterk! Jag tror inte ens Gabe förväntar att Nvidia och AMD i nuläget öppnar upp på det sätt du beskriver. Innan du kan rulla motståndaren måste du fått in greppet.

Samarbetet mellan Nvidia och Red Hat gynnar alla oavsett öppna eller stängda drivrutiner. Ett steg i taget. Vad gäller Wayland har faktiskt senaste drivrutinerna från Nvidia delvis stöd för EGL, så någonting är på gång.

Visst, jag håller med dig om att nuvarande upplägg är stökigare. Fast det är ju lite kul att fortfarande se meddelandet "module license 'NVIDIA' taints kernel"! Dessutom är det bara spekulationer, ifall du inte har någon konkret information om vilka förhandlingar som förs mellan Valve och Nvidia (och andra).

Är Linux bättre än Windows för prestanda?

http://arstechnica.com/gaming/2013/09/analysis-can-steamos-dr...

http://arstechnica.com/gaming/2012/08/valves-optimizations-ma...

Linux + OpenGL 315 fps
Win7 + OpenGL  303 fps
Win7 + DX11    271 fps

Bedöm själva.

Med rätt optimerade spel kan nog Steams konsol göra bra ifrån sig