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

[Del]

edit: hmm ser ut til at jeg tar feil her. Tråder brukes også som uttrykk for flere strømmer med instruksjoner i samme prosessor, men det er ikke det samme.

Men uansett så er det irrelevant for OpenGL og Direct3D hvor mange tråder en GPU er istand til eller ikke, ettersom utvikleren ikke har noen kontroll over dette.

Dette er ikke helt riktig, ihvertfall ikke når man tar den litt utvidede konteksten med GPGPU (altså å bruke GPU til noe annet enn kun å pushe pixler). Ved CUDA og OpenCL blir man eksponert for trådene på GPU.

Det var ikke noen tvil om hva 0stepop mente, så Del sitt innlegg var fullstendig verdiløst.

Vel, jeg foretrekker vel at ostepop selv forteller hva han mente, for setningen hang ikke på greip. Med det samme vil jeg gjerne se tester som viser gevinsten av flertråding på CPU (utover å skille ut rendring i egen tråd). Ikke Wow benken mellom dx9 og dx11, den sauser sammen alt så det er umulig å vite hva ytelsen kommer av.

[GeirGrusom]

Med det samme vil jeg gjerne se tester som viser gevinsten av flertråding på CPU (utover å skille ut rendring i egen tråd). Ikke Wow benken mellom dx9 og dx11, den sauser sammen alt så det er umulig å vite hva ytelsen kommer av.

Mindre byråkrati i koden. Funksjonen som genererer et datasett for GPU-en kan også brukes til å sende datasettet til den, fremfor å måtte delegere dette til tråden som tar seg av rendering.

[SpecialForce]

Andre programvareselskap en Microsoft subsidierer maskinen. Her kan vel symantec, Macafee og mange andre nevnes. Dette er ikke noe nytt.

vi er enige i dette, det var ditt latterlige estimat på at det utgjorde lisensen pluss to tusen kroner i tillegg jeg svarte på. Jeg forklarte deg at dette utgjorde totalt omtrent hundre kroner. Skjønner du det nå?

Da, min gode venn, ber jeg deg rette øynene dine til mitt opprinnelige innlegg. Det er ingenting der som gir den uttalelsen du kommer med. Det jeg påpekte, var at maskinen til 2000 blir dyrere. Så her er det ingen latterlige estimater ennå

Men de kan komme med tiden.

[Del]

Da, min gode venn, ber jeg deg rette øynene dine til mitt opprinnelige innlegg. Det er ingenting der som gir den uttalelsen du kommer med. Det jeg påpekte, var at maskinen til 2000 blir dyrere. Så her er det ingen latterlige estimater ennå

Men de kan komme med tiden.

Beklager, da misforstod jeg posten din.

[Malvado]

Er jo veldig tydelig at både Geirgrusom her og Del har litt peiling på både DirectX og OpenCL /GL , hva synnes dere om potensialet til disse nå og hvilke steg bør de ta for å bli bedre egnet til jobben de er ment til å løse?

[efikkan]

CPU-en har kontekster, ikke tråder.

edit: hmm ser ut til at jeg tar feil her. Tråder brukes også som uttrykk for flere strømmer med instruksjoner i samme prosessor, men det er ikke det samme.

Men uansett så er det irrelevant for OpenGL og Direct3D hvor mange tråder en GPU er istand til eller ikke, ettersom utvikleren ikke har noen kontroll over dette. Det var ikke noen tvil om hva 0stepop mente, så Del sitt innlegg var fullstendig verdiløst.

CPUer kjører threads, det samme gjør GPUen internt, selv om de er noe forskjellige.

Jeg trodde du egentlig siktet til flere CPU-threads som kommuniserte med GPUen for maksimal ytelse, det er ivertfall det artikler sikter til når de snakker om multithreding i Direct3D og OpenGL. Multithreading internt i GPUen er på en måte mer implisitt.

Jeg vil henvise tilbake til mitt innlegg #37 med illustrasjonen om multithreading (se bildet i full størrelse). Dagens GPUer støtter at flere threads kommuniserer med de så lenge bare én gjør det om gangen. Multithreading her handler om å utnytte GPUen optimalt. Vennligst ta deg litt tid og studér tegningen så du forstår den. Jeg tok meg ikke tid til å legge inn forklaringer, så jeg kan forklare raskt:

* De to øverste representerer rendering med to CPU-threads, den nederste med én thread.

* De grønne firkantene betyr at CPU-threaden har tilgang til GPU med context, orange og grå betyr at threaden ikke styrer GPU.

* Tidsaksene indikerer hvor lang tid det tar å rendre et helt bilde.

Legg merke til at GPUen ligger brakk en del av tiden med single thread, mens multithreading utnytter GPUen hele tiden. Relasjonen mellom de to tidsaksene representerer speedup som multithrading vil gi for spillet/programmet. Dette er én av de store "nyhetene" i DirectX 10.

Mindre byråkrati i koden. Funksjonen som genererer et datasett for GPU-en kan også brukes til å sende datasettet til den, fremfor å måtte delegere dette til tråden som tar seg av rendering.

Se over.

Med det samme vil jeg gjerne se tester som viser gevinsten av flertråding på CPU (utover å skille ut rendring i egen tråd). Ikke Wow benken mellom dx9 og dx11, den sauser sammen alt så det er umulig å vite hva ytelsen kommer av.

For alt vi vet kan det være at Direct3D 9-versjonen er helt elendig implementert, noe jeg mistenker sterkt etter egne analyser av spillet. At WoW ikke har mange ganger så høy framerate er egentlig latterlig med tanke på hvor enkel grafikken egentlig er.

0stepop:

Jeg vil gi deg en sjanse til å forklare deg for det du skrev over.

Uansett så har Direct3D 10/11 og OpenGL 3.x+ ekvivalent shader-ytelse for Nvidia, som skyldes at HLSL og GLSL er svært like, så like at Nvidia kompilerer de til Cg. Naturligvis er dermed shader-ytelsen lik. Interessant nok tillater Cg-spesifikasjonen mer enn GLSL-spesifikasjonen, så Nvidia kan faktisk kompilere "ugyldige" GLSL-shadere. De øvrige ytelseforskjellene vil ligge i implementasjonen av de øvrige delene av APIene. Det er en kjent sak at OpenGLs draw-kall er raskere enn Direct3Ds, som vil kunne gi OpenGL noen prosent bedre ytelse avhengig av hvor mange slike kall som blir utført.

[GeirGrusom]

CPU-en har kontekster, ikke tråder.

edit: hmm ser ut til at jeg tar feil her. Tråder brukes også som uttrykk for flere strømmer med instruksjoner i samme prosessor, men det er ikke det samme.

Men uansett så er det irrelevant for OpenGL og Direct3D hvor mange tråder en GPU er istand til eller ikke, ettersom utvikleren ikke har noen kontroll over dette. Det var ikke noen tvil om hva 0stepop mente, så Del sitt innlegg var fullstendig verdiløst.

CPUer kjører threads, det samme gjør GPUen internt, selv om de er noe forskjellige.

Jeg trodde du egentlig siktet til flere CPU-threads som kommuniserte med GPUen for maksimal ytelse, det er ivertfall det artikler sikter til når de snakker om multithreding i Direct3D og OpenGL.

Hverken OpenGL eller Direct3D setter som noe som helst krav at en hardware implementasjon skal benytte seg av flere instruksjonsstrømmer. Derfor er det irrelevant i sammenheng med OpenGL og Direct3D.

Endret 10. august 2012 av GeirGrusom

[Terrasque]

Dagens GPUer støtter at flere threads kommuniserer med de så lenge bare én gjør det om gangen.

 

Takkogfarvel

[Del]

Er jo veldig tydelig at både Geirgrusom her og Del har litt peiling på både DirectX og OpenCL /GL , hva synnes dere om potensialet til disse nå og hvilke steg bør de ta for å bli bedre egnet til jobben de er ment til å løse?

Jeg mener vel at OpenGL nå har initiativet, og er godt posisjonert til å gjøre grovt innhugg i bruken av D3D. I dag er den eneste grunnen til D3D sin eksistens å hindre at koder kan kjøres på tvers av plattformer. Det er kun et lock-in verktøy fra Microsoft.

 

Er det en ting jeg har lært de siste tjue årene, så er det å ikke undervurdere Microsoft sine evner til å sabotere konkurrerende løsninger. Når det gjelder D3D kjemper de med nebb og klør, og har sterke muskler til å fremme D3D. Her er det verdt å nevne at Xbox kun støtter D3D. Beta utgaver av Vista hadde lagt inn snubletråder som hindret opengl å kjøre sammen med aero (altså desktopeffektene i Windows), heldigvis lykkes CAD leverandørene å presse Microsoft til å bøye av, men flere måneder trodde alle at opengl var død teknologi på Windows.Et av de siste grepene er at Microsoft har gått ut å sagt at de ikke vil støtte webgl (standarden for 3D i nettlesere som nå støttes av alle andre, og som er en gren av opengl) i IE. Unnskyldningen er sikkerhet, samme unnskyldning som de bruker på sin nye secure boot løsning for bios som låser maskinvare til å kjøre windows. Som om dette vil ha vesentlig betydning for sikkerheten i windows. Mennesker flest er idioter som gladelig lar seg lure av glitter og stas, så jeg frykter at altfor få vil si ifra. Jeg tror derfor Microsoft har omtrent 50/50 sjanse på å sabotere opengl de neste ti årene også.

 

Det er isåfall synd, for jeg mener det hersker ingen tvil om at opengl nå har langt gått forbi d3d på de fleste områder. D3D fyller på ingen måte det spekteret av anvendelse som OpenGL+CL gjør i dag. Når det gjelder API tror jeg også vi allerede i løpet av et års tid vil se de siste vesentlige brikkene på plass i API'et til opengl (ikke bare som utvidelser). Alt tyder også på at driversituasjonen for opengl er i rask bedring. I dag tilbyr alle de tre store gode opengl drivere. I tillegg har alle tre anstendige åpne drivere, som vil se stor fremgang også det kommende året.

 

Generelt mener jeg det er grunn til å tro at OpenGL vil dra ifra D3D på ytelse (forutsatt at Valve fortsetter satsingen, slik at vi får innsats på driversiden også fremover). Det er to grunner jeg ser til dette, den ene er at OpenGL nå begynner å bli et relativt ryddig API (så vi slipper tregere drivere som følge av kompleksitet). Det andre er at OpenGL er nærmere hardware enn D3D som følge av at standarden i større grad er laget av og for produsentene av grafikkort.

[Tekno Brukeren]

Intel Atom er den som blir brukt i mini-PCer. Så da har du vell enten Windows XP eller Windows 7 Starter da?.

Selv en Atom vil idle på under 1% med Task Manager kjørende i Windows 7 Home Premium

Kan man få tak i Mini-PC med Windows 7 Home Premium da?

[efikkan]

Hverken OpenGL eller Direct3D setter som noe som helst krav at en hardware implementasjon skal benytte seg av flere instruksjonsstrømmer. Derfor er det irrelevant i sammenheng med OpenGL og Direct3D.

Poenget mitt har hele tiden vært at Direct3D og OpenGL er likeverdige her.

 

 

Dagens GPUer støtter at flere threads kommuniserer med de så lenge bare én gjør det om gangen.

 

Takkogfarvel

Hva er det du vil frem til her?

 

 

Generelt mener jeg det er grunn til å tro at OpenGL vil dra ifra D3D på ytelse (forutsatt at Valve fortsetter satsingen, slik at vi får innsats på driversiden også fremover). Det er to grunner jeg ser til dette, den ene er at OpenGL nå begynner å bli et relativt ryddig API (så vi slipper tregere drivere som følge av kompleksitet). Det andre er at OpenGL er nærmere hardware enn D3D som følge av at standarden i større grad er laget av og for produsentene av grafikkort.

1) Jeg vil påpeke igjen at som Nvidia selv sier er det ingen ytelseforskjell mellom core- og compatibilty-profilene. I dag har bakoverkompatibilitet ingen konsekvenser for ytelsen til sammenligning med Direct3D (ivertfall har ingen klart å påvise at det er tilfelle).

BTW: Hadde det vært opp til meg så hadde core-profilen opphørt. En ES-profil og en "full"-profil hadde vært mer enn nok å vedlikeholde.

 

2) Nå kan det være at jeg bare har misforstått deg. Uansett så er både Direct3D og OpenGL utviklet i samarbeid med produsentene, men utviklingen av Direct3D er ledet av Microsoft og designvalg kan derfor påvirkes noe. At Direct3D-APIet er med abstrahert vil jeg påstå er en direkte konsekvens av et prinippielt valg.

 

Men angående ytelsen så vil jeg tilbake til tallene fra artikkelen:

a) Win7 (Direct3D 9): 270,6

b) Win7 (OpenGL 2.1): 303,4 +15.6%

c) Linux (OpenGL 2.1): 315

Nvidias driver er faktisk glimrende til å forklare dette siden jeg vet at driveren er den samme (med unntak av spesialtilpasninger). Intels driver er veldig forskjellig fra Windows og Linux. AMDs er ukjent.

 

Shaderytelsen for Direct3D og OpenGL er ganske lik for SM3 (og er lik for SM4/5), så ytelseforskjellen mellom a) og b) skyldes primært overhead i APIet. Dette gir altså b) 15.6% bedre ytelse, eller mer korrekt a) taper 14.1% ytelse på sitt valg. OpenGL har blant annet raskere draw-kall, og med tanke på at denne generasjonen spill bruker såpass mange kall så blir ytelsetapet en signifikant faktor. Spill som er optimaliserte for SM4/5 vil derimot bruke langt ferre slike kall og ytelsetapet blir faktisk mindre.

 

Ytelseforskjellen mellom b) og c) skyldes primært vindusstystemet og kernel, og denne forskjellen er et gyldig argument i diskusjonen om hvorvidt Linux er egnet som spillplattform. Tallgrunnlaget er ikke godt nok til å hevde det er signifikant forskjell, men det viser i det minste at Linux gjør det like bra eller bedre enn Windows.

 

Dette er typen refleksjoner som har manglet fra samtlige artikler om disse måleresultatene, som hverken Phoronix, Techpowerup eller HW klarte å dekke.

[Brede_Skapstroppen]

Det er jo nettopp slikt som det her som gjør at jeg elsker PC som platform. Store aktører får ikke lov til å kuppe hele markeder uten en reaksjon.

 

Dersom Steam får til dette så presser det frem nytenkning og innovasjon fra MS = bedre for oss.

 

Til de som bekymrer seg for driverstøtte osv : Den kommer så snart det viser seg å være en legitim grunn til å legge ned arbeidstimene i det. Dersom PC-spillerne på STEAM, og Valve begynner å jobbe mot Linux, ja så tror jeg nok man kan regne med store ringvirkninger på utviklingen på forskjellige Linux platformer og støtten av forskjellige HW-produsenter.

 

Gabe Newell er våken, og antakelig lite interressert i at hans selskap skal bli akterutseilt av MS sine kuppforsøk i markedet ....veldig bra. Det siste vi ønsker er at vi får et nytt "Apple", noe jeg mistenker MS å streve etter.

[GeirGrusom]

Men angående ytelsen så vil jeg tilbake til tallene fra artikkelen:

a) Win7 (Direct3D 9): 270,6

b) Win7 (OpenGL 2.1): 303,4 +15.6%

c) Linux (OpenGL 2.1): 315

Nvidias driver er faktisk glimrende til å forklare dette siden jeg vet at driveren er den samme (med unntak av spesialtilpasninger). Intels driver er veldig forskjellig fra Windows og Linux. AMDs er ukjent.

 

Shaderytelsen for Direct3D og OpenGL er ganske lik for SM3 (og er lik for SM4/5), så ytelseforskjellen mellom a) og b) skyldes primært overhead i APIet. Dette gir altså b) 15.6% bedre ytelse, eller mer korrekt a) taper 14.1% ytelse på sitt valg. OpenGL har blant annet raskere draw-kall, og med tanke på at denne generasjonen spill bruker såpass mange kall så blir ytelsetapet en signifikant faktor. Spill som er optimaliserte for SM4/5 vil derimot bruke langt ferre slike kall og ytelsetapet blir faktisk mindre.

 

Ytelseforskjellen mellom b) og c) skyldes primært vindusstystemet og kernel, og denne forskjellen er et gyldig argument i diskusjonen om hvorvidt Linux er egnet som spillplattform. Tallgrunnlaget er ikke godt nok til å hevde det er signifikant forskjell, men det viser i det minste at Linux gjør det like bra eller bedre enn Windows.

Kunne vært viktig at det ble presisert i artikkelen at datagrunnlaget her er ekstremt tynt. I alle andre sammenhenger hadde det vært så dårlig at man hadde sagt at det var irrelevant.

Det har på et testsystem, med et sett med drivere fått høyere ytelse på en ikke-triviell implementasjon.

 

OpenGL er kanskje raskere enn Direct3D, men dette er overhode ikke noe som helst bevis for at det er tilfellet.

[Del]

1) Jeg vil påpeke igjen at som Nvidia selv sier er det ingen ytelseforskjell mellom core- og compatibilty-profilene. I dag har bakoverkompatibilitet ingen konsekvenser for ytelsen til sammenligning med Direct3D (ivertfall har ingen klart å påvise at det er tilfelle).

Jeg har ingen dokumentasjon for hånden, men jeg finner utsagnet merkelig. Det er opplagt for meg at å optimalisere en stor kodebase er tyngre enn å optimalisere en liten og oversiktlig kodebase. Vil tro jeg kan rote frem dokumentasjon på dette i forhold til opengl, men det vil fort ta et par timer.

2) Nå kan det være at jeg bare har misforstått deg. Uansett så er både Direct3D og OpenGL utviklet i samarbeid med produsentene, men utviklingen av Direct3D er ledet av Microsoft og designvalg kan derfor påvirkes noe. At Direct3D-APIet er med abstrahert vil jeg påstå er en direkte konsekvens av et prinippielt valg.

Du har ikke misforstått. Med OpenGL sitter Nvidia og co med begge hender på rattet, med D3D har Microsoft begge hendene på rattet, men er åpne for innspill fra produsentene. Det er vesentlig forskjellig, og har blant annet resultert i økt abstraksjonsnivå som du nevner, altså at opengl ligger nærmere hardware. Som sagt tror jeg dette fort får implikasjoner på ytelse. Endret 12. august 2012 av Del

[efikkan]

Kunne vært viktig at det ble presisert i artikkelen at datagrunnlaget her er ekstremt tynt. I alle andre sammenhenger hadde det vært så dårlig at man hadde sagt at det var irrelevant.

Det har på et testsystem, med et sett med drivere fått høyere ytelse på en ikke-triviell implementasjon.

 

OpenGL er kanskje raskere enn Direct3D, men dette er overhode ikke noe som helst bevis for at det er tilfellet.

Beklager, gikk noe fort i går. Det er en god indikasjon på at Linux gjør det like bra eller bedre enn Windows.

 

Tallgrunnlaget er selvsagt for lite til å bevise noe over all tvil.

 

Men hvorfor er dette en ikke-triviell implementasjon??

Endret 12. august 2012 av efikkan

[efikkan]

1) Jeg vil påpeke igjen at som Nvidia selv sier er det ingen ytelseforskjell mellom core- og compatibilty-profilene. I dag har bakoverkompatibilitet ingen konsekvenser for ytelsen til sammenligning med Direct3D (ivertfall har ingen klart å påvise at det er tilfelle).

Jeg har ingen dokumentasjon for hånden, men jeg finner utsagnet merkelig. Det er opplagt for meg at å optimalisere en stor kodebase er tyngre enn å optimalisere en liten og oversiktlig kodebase. Vil tro jeg kan rote frem dokumentasjon på dette i forhold til opengl, men det vil fort ta et par timer.

Will functionality marked as deprecated be slow on NVIDIA hardware?

No. NVIDIA understands that features on the deprecated list are critical to the business of a large part of our customer base. NVIDIA will provide full performance, and will support, tune, and fix any issues, for any feature on the deprecated list. This means that all the functionality in the ARB_compatibility extension and Compatibility profile will continue to operate at maximum performance.

link

 

2) Nå kan det være at jeg bare har misforstått deg. Uansett så er både Direct3D og OpenGL utviklet i samarbeid med produsentene, men utviklingen av Direct3D er ledet av Microsoft og designvalg kan derfor påvirkes noe. At Direct3D-APIet er med abstrahert vil jeg påstå er en direkte konsekvens av et prinippielt valg.

Du har ikke misforstått. Med OpenGL sitter Nvidia og co med begge hender på rattet, med D3D har Microsoft begge hendene på rattet, men er åpne for innspill fra produsentene. Det er vesentlig forskjellig, og har blant annet resultert i økt abstraksjonsnivå som du nevner, altså at opengl ligger nærmere hardware. Som sagt tror jeg dette fort får implikasjoner på ytelse.

Det var bare begrunnelsen din jeg reagerte på, jeg tror vi begge er enige i at Direct3D er mer abstrahert og at dette påvirker ytelsen. Men jeg tør påstå at dette er et prinsippielt designvalg fra MS, ikke fordi MS ikke er en produsent av GPUer. At OpenGL er designet for C og Direct3D for C++ er et eksempel på dette. MS har gjennom et par tiår frontet høyere nivås programmeringsspråk på mange fronter, og jeg tror det har en sammenheng.

[GeirGrusom]

Men hvorfor er dette en ikke-triviell implementasjon??

Når ble en spillmotor en triviell implementasjon?

Det jeg mener her, er at dersom man skal teste ytelse på API-er, så er det viktig å få med seg hva som er forskjellene. En generell tendens på et latterlig datagrunnlag er ingen tjent med.

For all del, det kan godt hende OpenGL er raskere enn Direct3D (Microsoft har noe med å implementere absolutt minimum mange steder, og la det forfalle til de bytter ut alt) men det hadde vært fint å se hva som er bedre med OpenGL. Også helst moderne versjoner av begge API-er.

[efikkan]

Men hvorfor er dette en ikke-triviell implementasjon??

Når ble en spillmotor en triviell implementasjon?

Det jeg mener her, er at dersom man skal teste ytelse på API-er, så er det viktig å få med seg hva som er forskjellene. En generell tendens på et latterlig datagrunnlag er ingen tjent med.

For all del, det kan godt hende OpenGL er raskere enn Direct3D (Microsoft har noe med å implementere absolutt minimum mange steder, og la det forfalle til de bytter ut alt) men det hadde vært fint å se hva som er bedre med OpenGL. Også helst moderne versjoner av begge API-er.

Jeg vil påstå at det viktigste er benchmarks av anvendelser (dvs. spill) fremfor syntetiske benchmarks, selv om sistnevnte kan være interessante til å teste ut spesifikke endringer.

 

Men for all del, her er det faktisk snakk om gamle versjoner av begge APIer. Jeg vil igjen påpeke at den forskjellen (15.6%) som her er antydet mellom APIene skyldes mengden API-kall som brukes, så forskjellen blir mindre eller større til færre eller flere slike kall som gjøres. Fornuftig bruk av SM4/5 krever langt færre slike kall så forskjellen blir (etter min erfaring) mer neglisjerbar da.

[efikkan]

Etter jeg har lest gjennom Valves fremvisning fra Siggraph så må jeg si meg veldig skuffet. Det hele fremstår som et enormt makkverk av en kode som er laget for SM2 (!). Det er visstnok snakk om en "oversetting" av Direct3D-kall til OpenGL på direkten, med tilhørende "translation overhead". Det står bare nevt om denne overheaden for CPU-last, men jeg fant ingenting om konsekvensene for GPU. Siden OpenGL-versjonen likevel er raskere med dette makkverket så vil jeg anta at Direct3D-versjonen også er rimelig dårlig optimalisert, og dermed lite representativ for noen av delene. Det skal forresten nevnes at de jobber med en SM3-versjon, ... jippi!

[LMH1]

Lurer litt på OpenGL 4.3 og NVIDIA 3D Vision (AMD HD3D) vs DX 11.1 hva skalerer best her?

 

Fikk lyst å prøve Counter Strike Go på linux bare for å se hvor bra det kan bli.