Valve: Left 4 Dead unter Linux schneller als auf Windows - dank OpenGL

die "Performance-Steigerung" hält sich doch aber stark in Grenzen, vor allem bei über 300 Fps.
Trotzdem interessant, das Linux effizienter mit Ressourcen umgehen kann

ja mag sein.
Wenn ich aber in jedem Spiel dafür +20% FPS im Vergleich zur Windows Version habe ist es mir auch egal wenn ich nur
max. 300 FPS habe.

Ich halte das was Valve vorhat vorhat im Auge weil mir bei "Linux" der Desktop deutlich besser gefällt als unter Windows.
 
Im Weiteren spekuliert der Artikel dann noch, warum überhaupt auf DX setzen, wenn OpenGL schneller ist und auch auf Mac, Konsolen und Handies/Tablets läuft (DirectX nur auf Windows, Xbox, Windows Phones).
Man hat die letzten Jahre auf DX gesetzt, weil es ein sehr sauberer Standard ist und OpenGl davon lief, besonders nach dem sehr enttäuschenden OGL3. Und je mehr Entwickler darauf programmierten, desto mehr zogen auch andere Entwickler nach.
Heute hat OGL4 denke ich einen sehr guten Sprung nach vorne hingelegt und man könnte es durchaus wagen, wieder mit OGL zu programmieren.

Schon komisch. Jahrelang lag Linux als Spieleplattform quasi brach, bis auf ein paar Eigenkreationen usw. und jetzt nimmt sich Valve dessen an und plötzlich scheint es in großen Schritten voran zu gehn. Hoffentlich klemmen sich jetzt noch weitere Publisher und Entwickler dahinter, so dass das Angebot weiter wächst.
Damals gab es einige Gründe gegen OpenGL. Einige OpenGL-Portierungen gab es immer, also ich sehe das jetzt nicht als großen Meilenstein, dass man jetzt L4D portiert hat. Der Meilenstein ist die Idee, es wirklich weitgehend zu unterstützen und das müssen wir noch abwarten.

Was hat das mit 300fps zu tun? Bzw über?
Die Leistung stieg DURCHSCHNITTLICH um 20%.
Wenn man das bei einer Grafikkarte will, zahlt man oft 100€ drauf.
Überleg mal eine Radeon 7850 zu 7950 oder Geforce 670 zu 680. Das sind knapp um 20% AFAIR und der Preisunterschied sind über 100€. Dabei ging das theoretisch auch mit mehr Optimieren der API, Treiber, OS und des Spiels.
Was sind 20%? Das ist natürlich so gesehen nicht viel. Eine geringfügig höhere Auflösung, mehr AF oder AA. Aber das wars dann auch, es lässt natürlich keine revolutionär neue Grafik zu. Aber das erstaunliche ist jetzt nicht, dass es bloß 20% mehr sind, man hat eher erwartet, dass man bei Linux WENIGER Fps hat als bei Windows
Rollora ein kühler Kopf ist vielleicht dort angebracht. Es ist ein Spiel, es sind FPS-Zahlen über 250. 20% hier, könnten bei bei FPS unter 100 weniger als 10% generieren. Wir haben auch Portal auf dem Mac und Blizzard Games. Da gab es auch einige Benchmarks und mir bleibt noch gut in Erinnerung das Portal sehr wohl schlechtere Performance auf dem Mac bot. Der Unigine-Bechmark hat ja ebenfalls einen OGL- und DX-Pfad, da werden durch DX mehr Punkte auf die Waage gebracht.
Prinzipiell wird OpenGL seinen schnelleren DrawCall behalten können, wobei ich jetzt nicht weiß ob MS mit DX10 und 11 da etwas verändert hat, aber ohne eine ausgereifte Plattform wie Windows + DX werden wir bei Linux wohl nirgendwo immer 20% mehr Geschwindigkeit bei spielen sehen.

Aber egal, dass ist sowieso sehr schwer zu beurteilen, da man nicht weiß wie viel Aufwand investiert werden muss und ob bisherige OGL-Implantationen nicht alle samt total Halbherzig entwickelt wurden und deshalb etwas weniger FPS manchmal haben.
Wichtig ist ja die Idee und ob dadurch wieder ein kleiner Konkurrenzkampf entstehen könnte, wo MS bei DX stärker entwickeln muss oder gar bei ihrem Store gewisse Restriktionen auflockert.
Leider muss ich für mich persönlich sagen, dass MS durch eine Dekade Herrschaft ihre Stellung sehr gut zementiert haben und niemals das Spieleangebot der letzten 10 Jahre auf Linux portiert wird.
Ich werde wohl mindestens für die nächsten 5-10 Jahre weiterhin bei Windows bleiben.
 
Man hat die letzten Jahre auf DX gesetzt, weil es ein sehr sauberer Standard ist und OpenGl davon lief, besonders nach dem sehr enttäuschenden OGL3. Und je mehr Entwickler darauf programmierten, desto mehr zogen auch andere Entwickler nach.
Heute hat OGL4 denke ich einen sehr guten Sprung nach vorne hingelegt und man könnte es durchaus wagen, wieder mit OGL zu programmieren.


Damals gab es einige Gründe gegen OpenGL. Einige OpenGL-Portierungen gab es immer, also ich sehe das jetzt nicht als großen Meilenstein, dass man jetzt L4D portiert hat. Der Meilenstein ist die Idee, es wirklich weitgehend zu unterstützen und das müssen wir noch abwarten.


Rollora ein kühler Kopf ist vielleicht dort angebracht. Es ist ein Spiel, es sind FPS-Zahlen über 250. 20% hier, könnten bei bei FPS unter 100 weniger als 10% generieren. Wir haben auch Portal auf dem Mac und Blizzard Games. Da gab es auch einige Benchmarks und mir bleibt noch gut in Erinnerung das Portal sehr wohl schlechtere Performance auf dem Mac bot. Der Unigine-Bechmark hat ja ebenfalls einen OGL- und DX-Pfad, da werden durch DX mehr Punkte auf die Waage gebracht.
Prinzipiell wird OpenGL seinen schnelleren DrawCall behalten können, wobei ich jetzt nicht weiß ob MS mit DX10 und 11 da etwas verändert hat, aber ohne eine ausgereifte Plattform wie Windows + DX werden wir bei Linux wohl nirgendwo immer 20% mehr Geschwindigkeit bei spielen sehen.

Aber egal, dass ist sowieso sehr schwer zu beurteilen, da man nicht weiß wie viel Aufwand investiert werden muss und ob bisherige OGL-Implantationen nicht alle samt total Halbherzig entwickelt wurden und deshalb etwas weniger FPS manchmal haben.
Wichtig ist ja die Idee und ob dadurch wieder ein kleiner Konkurrenzkampf entstehen könnte, wo MS bei DX stärker entwickeln muss oder gar bei ihrem Store gewisse Restriktionen auflockert.
Leider muss ich für mich persönlich sagen, dass MS durch eine Dekade Herrschaft ihre Stellung sehr gut zementiert haben und niemals das Spieleangebot der letzten 10 Jahre auf Linux portiert wird.
Ich werde wohl mindestens für die nächsten 5-10 Jahre weiterhin bei Windows bleiben.


Mac OpenGL Leistung ist auch nicht einfach mit Linux gleich zusetzen.
Anscheind sieht es auf dem Mac nochmal anders aus.

[Phoronix] Mac OS X 10.6.3 vs. Windows 7 vs. Ubuntu 10.04 Benchmarks

Fazit letzte Seite: "So while Microsoft Windows 7 Professional took the lead in all of these gaming tests on Apple hardware, aside from when using Intel integrated graphics, Ubuntu 10.04 LTS "Lucid Lynx" was a faster gaming platform than Mac OS X "Snow Leopard", which is good news for once the Steam Linux client arrives."

Seit 2010 hat sich bei Linux Grafikstack aber einiges getan. Beim Mac scheinen sie wohl sehr drauf achten zumüssen, dass alles über alle Versionen und Geräte passt. https://developer.apple.com/graphicsimaging/opengl/capabilities/

Auch die Treiber für OpenGL werden wohl getrennt behandelt auf dem Mac:
Deg says:
August 1, 2012 at 5:48 pm
Will the improvements to OpenGL in Linux carry over to improvements in OS X? What are some of the differences and challenges in 3d gaming between the two platforms?
Reply
przemoli says:
August 2, 2012 at 3:12 am
OSX and Linux do not share code for OpenGL drivers. Also Apple have its own API layer so GPU OEMs just provide back-ends.

On the other hand both AMD and NVIDIA drivers share code between Windows and Linux (hence improvements to Win+OpenGL, even though work was done on Lin+OpenGL).

So the simple answer is:
No.
Any improvements in Apple OpenGL drivers will come only from 1)Apple caring. 2)Game devs cooperating. 3)OSX users demanding.

All of above is true for this moment. So you should see improvements to OSX OpenGL regardless of Linux improvements.

Quelle: Kommentare des Blogs

Es ist also eher noch weitere Entwicklung bei Linux zu erwarten als bei Mac, einfach weil es anpassungsfähiger ist.
 
Zuletzt bearbeitet:
naja, linux wurde in einer 32bit variante verwendet, windows in der 64bit variante.

is da nicht die 32bit variante sowieso immer ums gespür schneller aufgrund der kürzeren befehle die der prozessor abzuarbeiten hat?
 
naja, linux wurde in einer 32bit variante verwendet, windows in der 64bit variante.

is da nicht die 32bit variante sowieso immer ums gespür schneller aufgrund der kürzeren befehle die der prozessor abzuarbeiten hat?

Ist die Frage wieviel die Grafik überhaupt von CPU seitigen Änderungen profitiert, dass kommt wohl auf das Spiel drauf an.

Linux 64-Bit ist eigentlich immer deutlich schneller und fühlt sich auch von dem System her direkter an, wenn man damit arbeitet.
[Phoronix] Ubuntu 12.04 LTS: 32-bit vs. 64-bit Performance

Die Tests wurden übrigens von Valve mit OpenGL 3.x durch geführt was etwa DX9-10 entspricht. Also nicht das neuste OpenGL gegen das alte DX9c.

Weiß einer was für ne NVIDIA Treiber Version bei 12.04 gerade benutzt wird? Die sind ja nicht immer die aktuellsten. Ich habe zur Zeit z.B. 302.17-4
 
Zuletzt bearbeitet:
Ist die Frage wieviel die Grafik überhaupt von CPU seitigen Änderungen profitiert, dass kommt wohl auf das Spiel drauf an.

Linux 64-Bit ist eigentlich immer deutlich schneller und fühlt sich auch von dem System her direkter an, wenn man damit arbeitet.
[Phoronix] Ubuntu 12.04 LTS: 32-bit vs. 64-bit Performance
Interessant. Danke. Habe vor 8 Jahren ca das erste mal mit Linux 64 für x86-64 Systeme gearbeitet, das war damals noch katastrophal. Gut, wenn es jetzt hinhaut :)
Die Tests wurden übrigens von Valve mit OpenGL 3.x durch geführt was etwa DX9-10 entspricht. Also nicht das neuste OpenGL gegen das alte DX9c.
Danke #2. Würd ich gern in die News übernehmen!
 
Bei mir funktioniert das Exploit schon garnicht mehr und mein Treiber hab ich schon ein paar Tage. Das ist halt der Vorteil von Rolling Release.

Wie dem auch sei. Nächste Woche ist die SIGGRAPH 2012 und hoffentlich stellt Valve ein paar Folien, Bilder oder gar Videos bereit.
 
Lange Rede kurzer Sinn - Wenn Linux zur Spiele Plattform wird - hab ich OpenSuSE am Start. Ein paar FPS mehr oder Weniger sind mir dabei völlig Wurst.
 
naja, linux wurde in einer 32bit variante verwendet, windows in der 64bit variante.

is da nicht die 32bit variante sowieso immer ums gespür schneller aufgrund der kürzeren befehle die der prozessor abzuarbeiten hat?

Kurze Antwort: Nein.

Lange Antwort: x86-64 hat einige Erweiterungen, die nur im 64bit-Modus nutzbar sind. Unter anderem deutlich mehr Register, Befehlssatzerweiterungen wie neue Vektorbefehle (wenn diese gut genutzt werden, kann z.B. die Physik um einiges schneller berechnet werden), oder direkte Unterstützung von 64bit-Operationen.
Manche Befehle sind zwar länger, aber mit Prefetching und Instruktions-Caches wird der Nachteil recht gut abgefangen.
 
Kurze Antwort: Nein.

Lange Antwort: x86-64 hat einige Erweiterungen, die nur im 64bit-Modus nutzbar sind. Unter anderem deutlich mehr Register, Befehlssatzerweiterungen wie neue Vektorbefehle (wenn diese gut genutzt werden, kann z.B. die Physik um einiges schneller berechnet werden), oder direkte Unterstützung von 64bit-Operationen.
Manche Befehle sind zwar länger, aber mit Prefetching und Instruktions-Caches wird der Nachteil recht gut abgefangen.

x86_64 CPUs haben nicht zwangsläufig "deutlich mehr Register". Die Register haben lediglich eine höhere Kapazität als die von 32bit CPUs.
 
aber braucht eine ALU nicht länger, gleicher takt vorausgesetzt, um 2 64bit befehle zu verarbeiten als 2 32bit befehle? ich mein, die bits werden doch nicht parallel verarbeitet, oder?

schon allein die adressierung is da doch viel komplizierter.
 
x86_64 CPUs haben nicht zwangsläufig "deutlich mehr Register". Die Register haben lediglich eine höhere Kapazität als die von 32bit CPUs.
Sowohl, als auch. Sowohl die Breite, als auch die Registeranzahl hat sich bei einigen Registern verdoppelt. ( Nicht bei allen Registern hat sich die Größe verdoppelt und nicht bei allen die Anzahl, allerdings oft eines davon)

aber braucht eine ALU nicht länger, gleicher takt vorausgesetzt, um 2 64bit befehle zu verarbeiten als 2 32bit befehle? ich mein, die bits werden doch nicht parallel verarbeitet, oder?

schon allein die adressierung is da doch viel komplizierter.
Nein, 2 Cycles für 2 64Bit Operationen und 2 Cycles für 2 32Bit Operationen. Das ist auch der Sinn einer 64-Bit Erweiterung ;)
Sowohl die ALUs sind doppelt so breit, als auch die Register doppelt so groß.
Die Adressierung ist in dem Sinne auch nicht viel komplizierter, sondern sie verbraucht mehr Speicherplatz.
 
ein Rennen gegen DX9... wow :ugly: Na dann mal her mit dem Vergleich gegen DX11. Nciht das dann doch noch das Bööööööööööse MS System schneler wäre wa? ;D
Ich denke Valve veruscht einfach mal wiede rein paar schlagzeilen um sich zu tümmeln. Und wir werden sehen. Half Life 3 wird unter Win 8 laufen. Bei Linux bezweifle ich das dann ja schon fast ^^ Natürlich wird man das dann irgendwie erklären können xD

btw: Windows Phone spiele sehen immernoch am besten aus ;) Ausserdem finde ich gar nicht so verkerht, das Spiele derzeit nur uner Windows laufen. Wenn parallel bal dnoch an Linux versioenen gearbeitet wird, dann stecken die Firmen womöglich noch weniger arbeit in den Inhalt des Spieles an sich. Und dann lohnen sich Videospiele womöglich gar nicht mehr. Oder man versucht den merhaufwand mit erhöhten Spielepreisen auszugleichen. Wer weiss auf was für teuflihsce ideen die Firmen kommen.
 
Ähm einen Augenblick: Hat mein Ironiedetektor versagt oder vergleichst du tatsächlich Spiele für Mobile Geräte mit denen für Desktops? Oder meinst du Windows Phone vs Android vs Apple? Das liegt an den strengen Hardwarebeschränkungen von MS und des recht geringen Alters der Plattform. Der Spaß geht erst los wenn Windows Phone 8 und Win 8 etwas älter geworden sind und die Entwickler dann anfangen müssen auch ältere Geräte zu beachten.

Wie es schon Valve gesagt hat: Sie benutzen OpenGL 3. Das bedeutet, dass sie eine Spezifikation irgendwo zwischen 2008 (3.0) und 2010 (3.3) verwenden, was in etwa D3D9 und D3D10 entspricht. Möchtest du einen D3D11 Vergleich, musst du mit OpenGL 4 vergleichen. Den kann dir aber meines Wissens nach niemand liefern. Zudem läuft die Source Engine unter Windows mit DX9.

BTW: Wenn du schon APIs vergleichen willst: Die Drawcalls von OpenGL sind effizienter als die von Direct3D. :P

Was die Sache mit der Mehrarbeit angeht: Da hast du grundsätzlich Recht, aber die Spiele werden dennoch auf die PS3 portiert, obwohl die Entwickler normalerweise nicht mehr die OpenGL ES Schnittstelle verwenden und deshalb ein höherer Portierungsaufwand entsteht. Da bei sehr vielen Spielen bereits von Anfang auf eine gute Portierbarkeit wert gelegt wird, wird der Mehraufwand unerheblich sein. Schließlich hatte Steam für Mac auch keine negativen Auswirkungen.

Fazit: Wir werden sehen. Aber mach dir keine allzu großen Sorgen um die Zersplitterung des PC Marktes, Linux wird den Marktanteil nicht sehr schnell vergrößern können. ;)
 
Ich meinte mit Windows Phone natürlich den vergleich mit Android und Apple. Apple hat natürlich nur ein einziges hardwareprofil, auf welches angepasst werden muss.
Zu dem vergleihc mit DX9. auch wenn es schon "alt" ist wurde das spiel ja nun doch nochmal extra an OpenGL angepasst, ich denke mit weiteren optimierungen würde dort auch noch ein bisschen aus DX9 rauskommen. Zumal dort in so hohen fps bereichen die rede war, das der vergleich sowieso etwas unaussagekräftig ist. Ich bin nicht sooo tief in Linux drin, das cih behaupten könnte wie die belastung des OS im hintergrund eines möglcihen laufenden spieles ist. bei windows kommt da natürlcih einiges zusammen. Ich bin teilweise schon verwundert wie starke abweichnungen es bei leutne mit ähnlcihen System gibt. Je nach Virescanner etc kommen dort schon einige Prozent zusammen. Zum glück gibt es bei einigen Virenprogrammen ja den ultragenialen "spiele modus" :ugly:
 
Deren OpenGL Renderer ist auch unter Windows mit ca 33 FPS schneller ;)

Wie gut der D3D9 Pfad nun optimiert ist, kann dir wohl nur ein Valve Entwickler sagen, allerdings ist es schon erstaunlich, dass deren OpenGL Renderer ja praktisch erst seit der OS X Version (schlecht optimiert) existiert und nun für die Linuxversion erst in den letzten Monaten aufgebohrt wurde und dennoch schneller ist. Das entspricht einem Zeitraum von 2 Jahren für die OpenGL Version, verglichen mit der D3D Version, die seit 2004 stetig weiterentwickelt wird. Ich denke da kann man ruhig davon ausgehen, dass die D3D Version ein effizientes Stück Code ist ;)

Deswegen zu sagen "OpenGL ist besser" halte ich dennoch für falsch. Den einzigen Vergleich den man sich momentan erlauben kann sind die schnelleren Drawcalls, die ich ja schon erwähnt habe. Aber ich kenne sowohl D3D als auch OpenGL nicht gut genug um die APIs sinnvoll miteinander vergleichen zu können.
Letztendlich fehlen einfach genug moderne Vergleiche. Denn das einzige aktuelle große OpenGL Spiel für Windows, das ich kenne heißt RAGE und da wurde ordentlich Potential verspielt (und hat keinen D3D Renderer).
 
Zuletzt bearbeitet:
Zurück