Gå til innhold

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


Anbefalte innlegg

Videoannonse
Annonse

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!

 

Jeg er personlig veldig glad at Linux og Opengl nå har greid å hentet inn ytelseforskjellen , om MS ikke våkner nå og fortsetter som vanlig antar jeg at det ikke skal så mye til før mange selskap går over til Opengl siden det vil da være enklere å utvikle spill som kan spilles på flere operativsystem med langt mindre "tilpassninger".

  • Liker 2
Lenke til kommentar

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!Jeg er personlig veldig glad at Linux og Opengl nå har greid å hentet inn ytelseforskjellen , om MS ikke våkner nå og fortsetter som vanlig antar jeg at det ikke skal så mye til før mange selskap går over til Opengl siden det vil da være enklere å utvikle spill som kan spilles på flere operativsystem med langt mindre "tilpassninger".

 

Bare synd at OpenGL er et ganske dårlig API. Det har ikke tålt tidens tann veldig bra.

  • Liker 3
Lenke til kommentar

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!

Valve har bekreftet at bildekvalitet er minst like god på linux, og at alle effekter er de samme. De har også kjørt OpenGL versjonen på windows (altså samme grafikk kodesti som på linux), og havner bak linux-versjonen, men foran D3D på windows.

 

Sprokket, driverstøtten er nå faktisk ganske god. Alle de tre store (ATI, Nvidia og Intel) kan kjøre denne uten problemer. Kanskje du kan være litt mer konkret og fortelle hvilke problemer du ser for deg?

 

Geirgrusom, artikkelen motsier ditt noe forutsigbare utsagn. OpenGL nådde funksjon paritet med D3D versjon 10/11 allerede ved versjon 3.2. I dag er OpenGL vs. D3D mest en smakssak for spillprogrammering. For andre formål er OpenGL mer funksjonsrikt. Det er i dag svært få grunner igjen til å bruke D3D.

Endret av Del
  • Liker 6
Lenke til kommentar
Gjest Slettet+5132

Jeg tror det er en liten feil i artikkelen. Dere skriver nemlig:

Da Valve innså at maskinvaren faktisk kunne yte mer enn de hadde trodd da de jobbet med DirectX, tok de en runde med maskinvareprodusentene, og fikk presset DirectX-tallet opp til 303,4 bilder i sekundet.

 

Men kilden (Valve-bloggen) sier:

Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration.

 

Slik jeg forstår det er det ikke Direct3D-implementasjonen de har fått til å kjøre på 303.4 FPS i Windows, men OpenGL-implementasjonen, de understreker dette videre med:

This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7?
Lenke til kommentar
Linux-versjonen er altså et godt hakk raskere enn Windows-versjonen. Testriggen til Valve skal ha bestått av en Intel Core i7 3930K-prosessor' date=' GeForce GTX 680-skjermkort og 32 GB minne. Det var nok for å presse ut hele 315 bilder i sekundet ved hjelp av OpenGL på Linux, mens i Windows 7 med DirectX fikk de "bare" 270,6 bilder i sekundet. Det er en ytelsesforskjell på omtrent 16 prosent.[/quote']

 

Lattelig å bruke så kraftig maskinvare, til linux uten i det heletatt teste ut SLI?

Hvordan er sli/crossfire driverne til linux? Men uansett så er dette positivt.

 

Vurder å prøve steam på Opensuse 11.2 RC 2 i første omgang og se selv hvordan HD7850 virker her.

 

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

Endret av LMH1
  • Liker 1
Lenke til kommentar
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!
Valve har bekreftet at bildekvalitet er minst like god på linux, og at alle effekter er de samme. De har også kjørt OpenGL versjonen på windows (altså samme grafikk kodesti som på linux), og havner bak linux-versjonen, men foran D3D på windows.Sprokket, driverstøtten er nå faktisk ganske god. Alle de tre store (ATI, Nvidia og Intel) kan kjøre denne uten problemer. Kanskje du kan være litt mer konkret og fortelle hvilke problemer du ser for deg?Geirgrusom, artikkelen motsier ditt noe forutsigbare utsagn. OpenGL nådde funksjon paritet med D3D versjon 10/11 allerede ved versjon 3.2. I dag er OpenGL vs. D3D mest en smakssak for spillprogrammering. For andre formål er OpenGL mer funksjonsrikt. Det er i dag svært få grunner igjen til å bruke D3D.

 

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. 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)

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)

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.

 

En annen grunn til å rbuke 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 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.

 

OpenGL 3.2 hadde ikke tesselation støtte, så det nådde ikke D3D11, og ikke full funksjonalitet med OpenGL 4.2 (4.1 manglet bruker-definert rendertargets som støttet forskjellige output format, som dukket opp i OpenGL 4.2 som glBindFragDataLocation. MRT før dette var ganske plundrete)

 

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

Endret av GeirGrusom
  • Liker 5
Lenke til kommentar

Kan være enig at mellom 270 og 303 fps ikke er så enorm forskjell.

 

Men tenk deg hvis man da har 4 x full hd skjermer eller flere 2560x1600 hvordan vil det da bli?

 

Så selv små som 33 FPS kan gjøre at skjermkort blir mye raskere.

 

Men jeg stiller spørsmåltegn med crysis (Crysis 2) vil disse spillene få et nytt liv i linux?

Hadde vært gøy å klare en 303 fps med entualist setings og 16QAA antilasing. Men da må man lage OpenGL 4 arketektur basert på crytek 2 og det vil nok bli komplisert.

Endret av LMH1
Lenke til kommentar

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)

Her er du inne på noe, men igjen er det nok slitsomt for folk å følge deg, det blir usammenhengende oppramsing hvor mye må tolkes mellom linjene.

 

Du sikter antagelig til flertråding på CPU. Som du sikkert vet er dette fullt mulig:

http://www.opengl.org/wiki/OpenGL_and_multithreading

og støttet ved design. Valve ser ikke ut til å ha noen problemer med dette selv ved versjon 2.1 av OpenGL. Flertråding på CPU er generelt en krevende øvelse. I stedet for å slenge ut en abstraksjon har Khronos her brukt mye tid på hvordan dette skal håndteres.

En annen grunn til å rbuke 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.
Som jeg vet at du vet er OpenGL ikke ment å dekke noe annet bruksområde enn det gjør, aksellerering av grafikk på drivernivå. Du vet utmerket godt at det du etterlyser 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.

 

Gladnyhet, OpenGL har sluppet versjon 4.3 i dag:

http://www.khronos.org/news/press/releases/khronos-releases-opengl-4.3-specification-with-major-enhancements

  • Liker 5
Lenke til kommentar

270 til 303 fps er en "merkbar forskjell"??? LOLSett opp alt til maks så du får 26,7 vs 30 fps, eller 53,4 vs 60 fps så er det kanskje merkbart. Det som er mest merkbart er fps drops, ikke en 10-15% forskjell i snitt FPS dersom den er betydelig over 60.

 

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

  • Liker 1
Lenke til kommentar

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.

  • Liker 3
Lenke til kommentar

Jeg må si dette ikke var noe forundrende resultat i det hele! Ta Windows 7 for et eksempel. Etter en boot (og du har nok installert noen program, ja), så er det ikke usansynlig at ram-bruken ligger på rundt en gigabyte.

 

Windows er jo som kjent et stort operativsystem som tar 4,3 GB (eller noe der omkring. DVD størrelse, hvertfall). Ubuntu som det her er snakk om, er ett komplett operativsystem som tar ca 700MB (CD-størrelse). som seg sier, er betraktelig mye mindre.

 

Bruk av CPU kraft har jeg ikke så mye referanser til, men jeg vil absolutt tenke meg at linux stikker av her også.

 

Jeg har hatt en maskin som kjører Arch-linux en stund. kort sagt, du starter med kommandolinje, og bygger deg ut derifra. Med grafisk grensesnitt på plass, var det snakk om 30-50MB RAM usage!!

 

All min respekt til Valve som går foran, og går veier ingen andre (for øyeblikket) går!

 

 

 

 

 

 

 

 

 

 

  • Liker 3
Lenke til kommentar

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)

Her er du inne på noe, men igjen er det nok slitsomt for folk å følge deg, det blir usammenhengende oppramsing hvor mye må tolkes mellom linjene.

 

Du sikter antagelig til flertråding på CPU. Som du sikkert vet er dette fullt mulig:

http://www.opengl.or..._multithreading

og støttet ved design.Valve ser ikke ut til å ha noen problemer med dette selv ved versjon 2.1 av OpenGL. Flertråding på CPU er generelt en krevende øvelse. I stedet for å slenge ut en abstraksjon har Khronos her brukt mye tid på hvordan dette skal håndteres.

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.

Hvis et GL program er multi-threaded, så bruker det to tråder: en til å rendre, en til å laste teksturer/modeller. Noe utover det og man begynner å gå på tynn is.

 

En annen grunn til å rbuke 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.
Som jeg vet at du vet er OpenGL ikke ment å dekke noe annet bruksområde enn det gjør, aksellerering av grafikk på drivernivå. Du vet utmerket godt at det du etterlyser 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.

 

Gladnyhet, OpenGL har sluppet versjon 4.3 i dag:

http://www.khronos.o...or-enhancements

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!

  • Liker 1
Lenke til kommentar

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.

  • Liker 2
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...