Valve: Left 4 Dead 2 er raskere på Linux enn på Windows

[Mannen med ljåen]

http://www.digi.no/8...enger-smutthull

 

Jeg frykter at PCer blir som mobiltelefoner, og du ikke kan bytte operativsystem på laptopen din om du heller vil ha Linux.

Om Microsoft skal plante kode i EFI på maskinene sånn at kun Windows kan kjøre på dem, blir det mye vanskeligere å være Linux-bruker.

 

 

Men da er det gledelige nyheter at Linux er i ferd med å bli tatt alvorlig av spillindustrien.

Det blir vanskelig for Microsoft å gjennomføre sine onde planer hvis det finnes flere ivrige Linux-brukere.

Endret 6. august 2012 av Mannen med ljåen

[FylleSpillern]

Forskjellen ville sikkert blitt enda større med et dårligere system, gitt at linux bare bruker en brøkdel av resursene som windows krever. FPS'en ville sikkert blitt 1000% høyere på en pc med 1 Ghz CPU, 1Gb RAM og et gammelt skjermkort.

[xSotte]

Kan dette spillet ha fått støtte for flere CPU tråder under Linux (versjonen) enn Windows etter å ha blitt portert?

[Del]

Tja, det er støttet, men av design var det ikke det i utgangspunktet. Du må opprette kontekstet med Shared Display Lists, som før OpenGL 3.0 også var et ganske forvirrende API (det er mye bedre i GL 3.0)

De fleste omgår problemet ved å bare ikke bruke multi-threading. Det er strengt tatt ikke nødvendig. Men state-machine designet til OpenGL er ikke mutli-threading vennlig i utgangspunktet.

Ikke mange klager på flertrådingbiten. De fleste utviklere er enige om at den vesentligste mangelen ved API'et nå er funskjoner for direct state access. Dette har vært tilgjengelig gjennom utvidelse fra Nvidia siden OpenGL 2.1, og støttes av AMD/ATI siden Catalyst 10.7. ref. http://www.opengl.or...tate_access.txt

SDL har vel ikke GL3 støtte i stable?

Det er vel totalt irrelevant for rendering av fonter? Når det er sagt er SDL2.0 visstnok rett rundt hjørnet, så å kode mot SDL1.3 er antagelig rimelig safe bet nå. Det er fordeler med å kode mot OpenGL 3.0 også, i dag støtter *alle* drivere for Intel/AMD/Nvidia 3.0. Selv OSX henger igjen på 3.2.

 

Les mer om SDL 2.0 her (det er mye snacks der):

http://www.phoronix....item&px=MTE0MDU

Endret 6. august 2012 av Del

[raid2]

Det er ingen tvil om at mange bruker Windows fordi det er eneste måten å få spilt på, deriblant meg selv. Nå har jeg riktignok brukt Linux på sekundær-PC-ene mine i mange år, og kjører nå Linux på samtlige PC-er fordi Windows nekter å boote på primær-PC-en.. Hadde vært enormt deilig å kunne kvitte seg med Windows 100%. Spill er den eneste PC-oppgaven som står igjen for min del (mediasenter og nettsurfing er de to andre tingene jeg hovedsaklig bruker PC til, og disse oppgavene klarer Linux mer enn bra nok).

 

Steam er den største distributøren av spill digitalt, og hvis de får til en suksessfull port hvor mesteparten av spillbiblioteket kjører like bra som i Windows tror jeg Linux vil se en stor vekst. Det at Apple og MacOS har hatt en så enorm vekst de siste årene vitner jo om at folk er interessert i noe nytt og annerledes. En vekst for Linux vil også legge mer press på hardware-produsentene og driverutviklingen hos disse.

 

Har nok litt store forhåpninger, men Valve har allerede en Mac-klient og har såvidt meg bekjent holdt på med Linux-klienten siden 2010.

[fudun]

Kult at Valve står ved sitt og har et kraftig horn i siden til MS!

 

 

MS sin applikasjonsbutikk for Win 8 kommer selvfølgelig til å gå rett i stupen på Steam. For ikke lenge siden, gikk jo Valve ut og sa at de gjerne ville bytte plattform, så spam/propaganda-filteret mitt slår inn, men jeg ser likevel positivt på at Valve er villige til å lage litt bråk. MS trenger denne utfordringen.

[007CD]

Som nevnt tidligere, HW.no sin artikkel har en feil, testen hvor Windows kom 300 noe FPS var med OpenGL, IKKE directX.

 

Dette blir nok også en make or break sak for ventilen også (Valve) om dette prosjektet går i dass så vil det skremme vekk andre fra å satse på Linux som en spillplattform for en god del år framover i tid.

Men Valve ser også på dette som en langtids investering, og med deres holdning til Win 8 og den generelle holdningen til Win 8, så kan dette bli innertier og ett slag under beltet for Microsoft.

[SVD]

Half-life 3 som Linux only neste da:p

[Del]

Jeg er enig det kan godt tenkes jeg vil velge linux isteden for windows hvis spill og videoredigering blir billigere og bedre.

Videoredigering er da vel bra dekket med Kdenlive. Hva savner du der, og hvilken videoeditor bruker du nå?

[Kakebakelate]

Synd at det ikke står noe om når valve skal gi ut steam for linux. Valve er jo ikke akkurat kjent for å være raske (men når det først kommer, så fungerer det somregel).

[Delta_hf]

Half-life 3 som Linux only neste da:p

om ikke linux only hadde det vært rått om de ga det ut til linux 2 uker før windows. Se hvor mange som installerer linux

[Turgon]

Er openGL versjonen nyutviklet mens directx versjonen gammel?

En nyutvikling kan ha nytt godt av erfaringer fra den første runden utvikling.

 

Hva slags funksjoner fra apiene brukes i l4d2?

Optimalisering av funksjonalitet som allerede har god nok ytelse er lite nyttig.

 

Kjøres spillet på en oppløsning der spillet er cpu bundet?

Med så høy framerate er dette en mulighet. Da tester vi jo egentlig ikke grafikkbiblioteker.

[Del]

Spillet er portet over fra D3D og windows til OpenGL windows og linux. Det er snakk om versjon 2.1 av OpenGL.

 

Tallene stammer fra test med NVIDIA GeForce GTX 680 grafikkort, og Intel Core i7 3930K prosessor.

 

Poenget er ikke å vise at OpenGL og linux er kjappere enn windows, poenget er å vise at de på et par måneder har gått fra 6fps til 300fps, men andre ord de har fått det til. Budskapet her er at linux+opengl gjør jobben helt fint, og det er en overkommelig jobb å få ting til å funke der. Når man leser hva en del poster om Windows+D3D vs. Linux+OpenGL, så er det klart at dette var et viktig budskap å få frem. Det snakkes så mye tull rundt på nettet at man av og til kan gå av hengslene.

[AllFather]

Folk flest er ikke "nerder" og kommer sannsynligvis aldri til å installere Linux.

Men kjekt for de få prosentene som bruker og kommer til å bruke det

[Del]

Ifølge Ubuntu vil drøyt fem prosent av PC'er i verden komme med Ubuntu ferdig installert det kommende året. Her i Norge driter vi oljepenger ut av rævva, i India og Kina er folk litt mer fornuftige. Dropp windows og maskinen dropper drøyt 500,- i pris. Når du kan få en ny PC til drøyt 2.000,- så er det betydelig.

 

Selv i Europa glir linux sakte inn i samfunnet, i Norge derimot har vi politikere som gjør hva de kan for å holde fri programvare langt unna.

[Dunsay]

Det er en semantikk diskusjon ja, kverulering er bare for å være vrang. Jeg synes det er dumt å si at noe er en merkbar forskjell når du faktisk ikke vil merke forskjellen... Da er det bedre å bruke andre ord. Jeg liker å bruke ord så betydningen av det blir brukt slik det er definert.

 

Stemmer. Det er en tydelig/klar/ikke ubetydelig/målbar/etc. forskjell, men den er ikke merkbar/observerbar når det produseres ~300 fps.

[efikkan]

La meg rydde opp i et par ting her.

Linux krever mindre systemresurser en Windows 7 og da har Linux mere resurser til overs som kan brukes til spill.

Dette er en veldig vanlig misforståelse. Det er svært uvanlig i dag at CPU-ytelsen er den store flaskehalsen for spill, og selv om CPUen bruker 100% på 1-2 kjerner så betyr ikke dette at en kraftigere CPU vil gi høyere grafikkytelse. Det er vanlig at rendering-thread kontinuerlig kaller på driveren, og IO-thread bør kontinuerlig polle for events for minimal responstid.

Folk flest er ikke "nerder" og kommer sannsynligvis aldri til å installere Linux.

Men kjekt for de få prosentene som bruker og kommer til å bruke det

Ubuntu er langt lettere å installere enn f.eks. Windows, i de fleste tilfeller er installasjonen rett frem.

Kan dette spillet ha fått støtte for flere CPU tråder under Linux (versjonen) enn Windows etter å ha blitt portert?

Som jeg har sagt mange ganger før på forumet her, flere threads gir ikke høyere grafikkytelse. Dagens GPUer støtter ikke samtidige load- og render-operasjoner (dog. har nVidia søkt patent på det, så det kommer i fremtiden), og driveren kjører uansett bare i én enkelt thread. Multithreading i spill handler om å fjerne overhead og latency, ikke om parallelisering på GPU, dette tar GPUen seg av internt med hundrevis av threads. Både OpenGL og Direct3D tillater flere threads som bruker GPUen, men det skjer ikke samtidig. Jeg har laget en illustrasjon for å forklare forskjellen:

 

Det Valve ikke sier noe om er om bildekvaliteten er akkurat den samme i Linux som i Windows , men jeg antar at den er det og derfor er det imponerende å se et slikt ytelsehopp!

Bildekvaliteten er den samme.

Kan være raskere, bedre kvalitet og yte bedre på interne tester så mye de bare vil, men når driverstøtten er så dårlig som den er på grafikkort hjelper det lite.

Nvidia er de eneste som leverer drivere med "enterprise"-kvalitet for Linux.

"Merkbar" i betydningen "en ikke ubetydelig ytelsesforskjell", ikke i betydningen at du faktisk ser denne forskjellen, slik jeg tolker det. Kverulant.

16% er signifikant, men om det er merkbart kan diskuteres. Isåfall er ikke et relativt tall nok, siden andre faktorer som skjermfrekvens må betraktes.

Uansett vil jeg foretrekke OpenGL siden det kan bli mindre hakking (stuttering) pga. implementasjonen av trippel bufring.

-----

Så må jeg ta hånd om den vanlige remsen med OpenGL-myter; "opengl er gammelt", "opengl støtter ikke multithrading", "opengl er full av utrangert dritt", "opengl er ustabilt", "opengl er tregt", "opengl er funksjonelt underlegent Direct3D" osv...

Vel, det finnes en funksjon: glVertexAttribPointer... og glVertexAttribIPointer. Den ene BURDE vært fullstendig overflødig, men den nesten usynlige I-en inni der gjør API-et mer tungvint å benytte seg av.

i, f, fv osv. er for å spesifisere datatyper, så slipper driveren å trenge en ekstra parameter for datatype og konvertere disse hver gang, det spares ganske mange CPU-sykler på dette. Hvorvidt løsningen er elegant eller ikke er en smaksak, men hvis dette virkelig er et stort problem for deg så har du lite å sette fingeren på.

 

Det er også et salig rot med state.machine og objekt-modell (glEnable -&--#62; State machine, glBindBuffer -&--#62; objektmodell på toppen av en state machine)

En state-machine er det som befinner seg under panseret. Den kan pakkes inn men vil da introdusere overhead. En fordel med OpenGL er at det er enkelt å kode i C. Binding (f.eks. av teksturer) har Direct3D også, og Nvidia har derfor laget utvidelser for OpenGL som kalles "bindless graphics" som kan eliminere en stor flaskehals.

Av design er det ikke støtte for multi-threading. Du må lage flere kontekster for dette, og selv da er det en del gotchas (Direct3D11 er dette ikke et problem)

Dette har vi vært gjennom mange ganger, og det er også nevnt ovenfor. OpenGL støtter, og har i lang tid støttet delte context og flere contexts for både Windows og Linux, lenge før DirectX 10.

glTexImage funksjonene baserer seg på state-machine modellen, og inneholder info om størrelsen på bildet. Dette burde vært objektmodell som buffer. Selv om du bare skal endre pixel-data må du også oppgi størrelsen på bildet. I verste fall fører dette til at hele minneområdet forkastes og opprettes på nytt. Dette er et problem først og fremst for skjermkortdriveren. Det var en stund en abstraksjon på toppen av dette for å binde flere teksturer til state-machinen, som var krevd for multi-texturing. Dette var ekstremt rotete, men med shader-støtten nå funker det mye bedre.

Dersom minneområdet forkastes og "opprettes på nytt" har du brukt funksjonen feil. Du har muligheten til å oppdatere eller bytte ut en del av en tekstur.

En annen grunn til å bruke Direct3D er at det følger med alt du trenger av API-er for å laste teksturer, modeller, skeletal animation, matte. Med DirectWrite og Direct2D får du også utmekret hardware aksellerert rendring av tekst, som er noe som er fullstendig fraværende i OpenGL, og en ikke-triviell oppgave å implementere.

Jeg må minne om at OpenGL er en spesifikasjon, ikke et biliotek. Det finnes en rekke biblioteker for dette, og teksturlasting, modeller og matte er ikke noe problem å finne gode alternativer for. Personlig bruker jeg stort sett egenkomponerte biblioteker, med til og med optimaliseringer i assembly. DirectX har med mange nyttige ting i pakken, som er kraftige og noe tunge. Dette er både fordeler og ulemper. For det første slipper nybegynnere å lete etter biblioteker, men samtidig er noen av disse svært omfattende og overveldende. For større prosjekter er problematikken med å finne biblioteker mer neglisjerbar, det er ikke der utviklerne bruker tiden sin.

Jeg bruker OpenGL selv, fordi man har ikke egentlig noe alternativ til det. Direct3D funker ikke på andre plattformer enn Windows, så man kan ikke bruke det andre steder. Derfor bruker jeg OpenGL; ikke fordi jeg synes OpenGL er så bra, for det er det ikke.

La meg snu på det, hvorfor bruke Direct3D når du kan bruke OpenGL? Det beste argumentet for Direct3D vil være at det fungerer bedre for AMD- og Intel-drivere.

Hva er grunnen til å forsvare OpenGL, annet enn at det ikke er Direct3D?

Jeg har en rekke grunner:

- Mest funksjonalitet.

- Lik eller bedre ytelse enn Direct3D.

- Støtte for mange plattformer.

- Åpen spesifikasjon.

Utviklere som velger Direct3D 10/11 må lage en ekstra render-path for å inkludere XP-brukere, og da vil et enkelt renderpath i OpenGL 3.x+ kunne dekke alle disse plattformene pluss flere.

... her er trivielt tilgjengelig i andre biblioteker, hvor det hører hjemme, nemlig SDL. Merk at SDL er tilgjengelig også på iOS og Android, i tillegg til Windows OSX og linux.

Bare som en kommentar, SDL har riktignok utrolig mye funksjonalitet, men er veldig utdatert (6 år) og "gjør ingenting bra". SDL mangler støtte for overnevnte threading og har ganske stor overhead på en del API-kall. Jeg har debugget en del hvordan disse kallene går gjennom en rekke av abstraksjonslag og til tider kan gå i løkker. Mange API-kall er implementert plattformuavhengig, der platformspesifikke kall gjøres flere lag under dette. Det høres kanskje elegant ut, men det blir veldig klussette når plattformene som SDL støtter er veldig forskjellige, det blir tid tider et "felles maksismum" av alle platformene. De som har jobbet tett på Windows og X11 vet at disse er svært forskjellige i vindushåndtering og events. Personlig foretrekker jeg heller å bruke en

#if defined(__unixlike_X11__)
(...)
#endif
#if defined(__windows__)
(...)
#endif

inne i en generell funksjon.

 

SDL har vel ikke GL3 støtte i stable? Dette har ikke FSML heller, så jeg bruker dev-versjonen i håp om at stable snart dukker opp. SDL har vært 1.2 stable i mange, mange år nå.

OpenGL 4.3: Yay! Compute shaders!

Stemmer, SDL støtter bare OpenGL 2.1, pluss at for hver nye spesifikasjon eller extension må du som utvikler vente til noen (Sam Lattenga) legger det til i SDL, med mindre du legger det til selv da. Det verste er at dette skyldes en prinsippiell "design-feil", der SDL bruker sine spesielle headerfiler for OpenGL. I likhet med andre alternativer til SDL, bruker mitt bibliotek en vilkårlig headerfil, f.eks. Khronos offisielle filer som oppdateres mange ganger årlig. Hvis OpenGL 5.0 kommer ut i morgen og fremdeles bruker samme profil-system som 3.2+, så trengs det ingen oppdateringer til biblioteket mitt.

OpenCL har vært tilgjengelig lenge.

Foreløpig er det ikke noe voksende marked for spill på Linux. Jeg tror Linux sitter i en ond sirkel når det gjelder dette. Ingen lager spill til linux fordi ingen bruker linux. Ingen bruker linux fordi ingen lager spill til Linux.

Litt kjip sak å komme seg ut av. Jeg tror Linux må få et større markedssegment før utviklere ser det som økonomisk forsvarlig å utvikle samt drive support for Linux utgivelser.

HumbleIndieBundle er et eksempel på at Linux er et stort marked bare det blir markedsført riktig. At Valve som dominerer digital distribusjon av spill kaster seg på Linux-plattformen vil påvirke mange selskaper i det lange løp.

[LoveAmiga]

Morro at Linux brukere som er så opptatt av at alt skal være så åpent er så glad for å få Steam DRM. Litt selvmotsigende kanskje?

Endret 6. august 2012 av LoveAmiga

[Del]

Ingen selvmotsigelse i å ønske å kjøre lukkede programmer på et åpent system med åpne drivere. Så lenge åpne spill ikke er bra nok, har jeg få problemer med å kjøre proprietære spill.

[nieh]

Morro at Linux brukere som er så opptatt av at alt skal være så åpent er så glad for å få Steam DRM. Litt selvmotsigende kanskje?

 

Richard Stallman har allerede gitt en kommentar på akkurat dette. Valve bruker DRM i Steam, noe som er negativt og burde vært unngått. Men med Steam og ett stort utvalg av spill til GNU/Linux vil brukermassen øke. Dette vil igjen føre til at andre utviklere og investorer følger etter. Dette vil igjen øke antallet utviklere og brukere av åpenkildekode programvare.