News Benchmark: Tomb Raider für Linux läuft langsamer als unter Windows

Wolfsrabe schrieb:

Nein, im Blenderwiki gelesen und extra bei blenderartists bei den Entwicklern nachgefragt (wo diese Frage btw regelmäßig kommt). Kein Grund beleidigend zu werden.

kA, ob ALLEN Nutzern die DIfferenzen klar sind. Scheinbar nutzt du Blender, und weißt nicht, dass Cycles OpenCL verwendet.
 
OpenGL ist schlechter als Direct X. Jedenfalls als Direct x 12. Ich finde es schön, dass manche OpenGL verteidigen, aber es ist genauso wie Direct X11 nicht mehr das Maß der Dinge. Beide "alten" Schnittstellen kranken am selben Problem.
Deswegen ist die Aussage "OpenGL ist genauso schnell wie Direct x"(mit der selben Hardware) schlicht weg falsch. Bis Direct x 11 stimmt es, aber wir haben das Jahre 2016.
 
@5@n!töt3r
Das heißt aber auch das sie seit dem Start der DX Version Zeit hatten die Linux/OpenGL Version umzusetzen und zu optimieren.
Das jetzt gezeigte ist eher ein schneller Port mit bestenfalls frühen Beta Status der durch Abwesenheit von Optimierungen glänzt.

@D708
Was hat das 2013er Tomb Raider mit DX12 zu tuen?

@TheInterceptor
Das dürfte in erster Linie die CPU Belastung und das mangelhafte Multithreading sein aber wie man bei der DX12 Version von Rise of the Tomb Raider sehen konnte kann man auch das vergeigen.
 
Wadenbeisser schrieb:
@TheInterceptor
Das dürfte in erster Linie die CPU Belastung und das mangelhafte Multithreading sein aber wie man bei der DX12 Version von Rise of the Tomb Raider sehen konnte kann man auch das vergeigen.

Das CPU-Last Problem hatte OpenGL nie, deswegen hatte Valve mit L4D2 auf Windows über OpenGL bessere Ergebnisse (mit Übersetzungslayer) als auf DX. Multithreading gibt es schon seit 4.4.
 
Wie ich schon schrieb, diese Version glänzt nur so mit Abwesenheit von Optimierungen aber das war ja nach der unterirdischen DX12 Version vom Nachfolger bereits zu erwarten.
 
Belege für die Abwesenheit von Optimierungen bei der DX12 Version?
Wie wäre es damit das sie vor allem bei den Radeons deutlich langsamer als mit DX11 läuft? Hab auch mal gelesen das sie eine ähnlich hohe CPU Last erzeugt, was in Kombination mit der geringeren Framerate zu einer höheren CPU Lastigkeit führt....ein echtes Kunststück bei ner low(er) level API.
 
Klar für den Endnutzer mag es vielleicht interessant sein, aber eigentlich sollte der sich doch auch das Resultat denken können: Wie kommt man auf die Idee OpenGL und DirectX zu vergleichen?

DirectX, das schon seit über 10 Jahren von Hard- und Softwareindustrie konsequent gefördert und gefordert wird. Dazu im Vergleich OpenGL, dass einen anderen Ansatz verfolgt, und aufgrund des Mehraufwands viele in der Spieleentwicklung lieber einen Bogen darum machen. OpenGL ist darauf ausgelegt, dass es, wenn es mal läuft, überall läuft und ist sowohl Multiplatform als auch Versionskompatibel (und OpenGL ist älter als DirectX). Das macht auch die Entwicklung von Treibern sehr aufwendig und wartungsintensiv. Und man sollte auch nicht vergessen, dass die Khronos Group aus vielen Interessensgruppen besteht, die hauptsächlich an der Entwicklung offener Schnittstellen interessiert sind. Also kurz: DirectX und OpenGL sind einfach zwei unteriedliche Schuhe.

Die Frage, ob jetzt man jetzt Linux zum Zocken verwenden sollte, liegt nicht in irgendwelchen Performance-Vergleichen, sondern macht momentan nur Sinn, wenn man offene Standards und die Platform Linux selbst unterstützen möchte.

Meine Meinung.
 
Zuletzt bearbeitet:
Das Alter ist bei OpenGL relativ ehal, dessen Problem ist das zu viele Köche den Brei verderben.
Es wird einfach in zu viele Richtungen verwendet, wobei jeder sein Ding durchsetzen will. Entsprechend lange dauert das Aushandeln der Funktionen und das Endergebnis ist für Spiele wohl eher selten optimal. Bei DirectX hat nur einer seinen dicken Daumen drauf udn die primäre Ausrichtung ist auch recht eindeutig, was natürlich auch die Weiterentwicklung beschleunigt.
So wie ich es verstanden habe soll gerade Vulcan dieses Ungleichgewicht aushebeln und ist deshalb auch kein Nachfolger für OpenGL sondern lediglich eine Alternative.
 
TheInterceptor schrieb:
Nein, im Blenderwiki gelesen und extra bei blenderartists bei den Entwicklern nachgefragt (wo diese Frage btw regelmäßig kommt). Kein Grund beleidigend zu werden.
Kein Grund an die Decke zu gehen. War glaub ich ein Mißverständnis, denn das mit der Glaskugel habe ich nur auf dein "wird er nicht" bezogen, da ich daraus schlußfolgerte, du hättest gemeint, AMD-Grafikhardware würde leistungsmäßig niemals nicht auf einen grünen Zweig in Blenders Cycles-Renderer kommen. Wobei ich eben denke oder hoffe, daß sich bei AMD im Zuge von Vulkan und dem neuen Treiber-Unterbau "amdgpu" in Zukunft eben auch unter Cycles etwas zum positiven ändert.

TheInterceptor schrieb:
kA, ob ALLEN Nutzern die DIfferenzen klar sind. Scheinbar nutzt du Blender, und weißt nicht, dass Cycles OpenCL verwendet.
Ist mir bewußt, hab es nur verwechselt.
 
Zuletzt bearbeitet:
Ich hab hier jetzt nicht alles gelesen, konnte aber bereits auf der ersten Seite sehen wie viel Unwissenheit hier teilweise versammelt ist.
Der Artikel ist in Ordnung und spielgelt halt die Situation wieder, so wie sie ist.

Aber mal ganz ehrlich, ob ich nun 70 oder 170fps habe ist mir in der regel egal, solange das Spiel spielbar läuft (die Framedrops im Spiel sind ja bekannt und Feral arbeitet dran)

Viele scheinen gar nicht zu verstehen das für den Port weder Square Enix noch Crystal Dynamics verantwortlich ist, sondern ein drittes Unternehmen, welches sich halt auf Spieleportierungen für Mac und mittlerweile auch Linux spezialisiert hat.
Ich kenne zwar das Vertragswerk nicht, aber Geld dürfte hier vom Publisher nur recht wenig fließen. Denn es wurde schon mehrfach erwähnt, dass man auf die Steam Verkäufe nach Release angewiesen ist, da diese Käufe dann, sofern siem von einem Linux System kommen auch als Linux-Käufe gewertet werden.
Ich gehe also mal davon aus, das Feral von Square Enix einen gewissen kleinen Betrag bekommt (welche vielelicht für die ersten Entwicklungsarbeiten reicht um die Machbarkeit zu prüfen) und alles darüber hinaus muss man selbst über die Linux Verkäufe erwirtschaften. Und mit diesem System schreibt man durchaus schwarze Zahlen, wie bereits bestätigt wurde.

Aber natürlich muss man auch hier wirtschaftlich denken. Klar könnte man noch ein paar Monate in optimierungen Stecken, aber das sind dann Monate wo kein Geld rein kommt und wie bereits hier festgestellt wurde, so viele Geld ist mit Linux nicht zu machen.
Also bringt man das Spiel raus, sobald es "spielbar" ist. Und Spielbar ist es ja in der Tat.
Auch möchte man sich an vielen Punkten Arbeit sparen und nutzt oft die Schnittmenegen von OpenGL unter Linux und Mac (und Mac hinkt hinterher) somit wird Linux hier oft durch den Umstand ausgebremst, dass man gewisse Dinge wegen des Macports nicht umgesetzt hat.

Ich habe selbst viele der Feral Spiele schon gespeilt, von Grid über Alien und nun auch Tomb Raider, sie erreichen zwar nie die Performance wie unter Windows, aber spielbar sind sie immer und das ist es was für mich zählt.

Die Technik von Feral ist im übrigen vergleichbar mit dem was Valve mit seinen Spielen gemacht hat. Der Quellcode wird über ein Tool halbautomatisch von DX zu OGL gebracht und man muss halt hinterher nur noch wenig von Hand machen. Das ist natürlich längst nicht so optimal als wenn man sich die Mühe macht wirklich alles neu zu schreiben und ganz gewiss wird es viele Stellen geben wo ein einfacher aber schlechter weg genommen wird anstatt den wirklich optimalen. Aber das ist halt alles ne Frage des Geldes.
Wer das als Wrapper bezeichnet ok, dann ist es halt ein Wrapper. Ich sehe es aber dennoch als nativ an.
Was Virtual Programming mit eON macht ist in meinen Augen ein echter Wrapper. Denn dort wird in der Tat eine Windowsversion onthefly von DX nach OGL gewrappt ohne das man den Quallecode auch nur gesehen nat. Zwar wird auch hier bei manchen Dingen noch von Hand nachgebessert, aber wirklich nur minimal. Aber auch diese Spiele laufen mittlerweile recht ordentlich.

Hier gibt es z.B. ein Video von Tomb Raider unter Linux
 
Zuletzt bearbeitet:
Wie macht Valve es denn mit Left4dead etc. Wenn ich mich recht erinnere laufen die sogar schneller als auf Windows?

Mit meiner GTX770 und 1680x1050 Auflösung geht es gerade noch flüssig in Ultimate zu spielen. Gleich wie in Windows, nur etwas
weniger FPS, was in meinem Fall aber keine Rolle spielt.

X-Plane läuft auch ca. 20% schneller auf Ubuntu/Nividia.
 
Ultimate würde ich da auch nicht unbedingt machen. Denn wenn ich im Twitch Stream von Feral richtig zugehört habe damals, wird TressFX unter Linux unabhängig der Hardware immer von der CPU übernommen in dem Spiel. Das frisst dir also wenn es aktiviert ist schonmal gut was weg, denn Lara hat ja nunmal keine Glatze.

Valve konnte damals sehr gute Ergebnisse erzielen, da es alles DX9 Spiele waren und ihre ToGL Technik da sehr gut mit umgehen konnte. http://www.extremetech.com/gaming/1...oftware-here-come-the-steamos-and-linux-games

Um nochmal kurz auf den Streit DX vs. OGL einzugehen. Selbst Valve sagt, dass OpenGL schneller ist als Direct3D. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows

Das ist im übrigen mein "Low" und "Ultimate" Ergebnisse auf meinem schon etwas betagtem Rechner mit ner Phenom II 1090T + GTX 970 + 16GB DDR3 1333
Bildschirmfoto vom 2016-05-01 09:25:42.pngBildschirmfoto vom 2016-05-01 09:24:00.png
Also in beiden Situationen durchaus noch spielbar.

"Ultra" wären dann meine Einstellungen. Was im Grunde Ultimate ist, nur mit deaktiviertem TressFX
Bildschirmfoto vom 2016-05-01 09:39:26.png
Wie man sieht, schluckt alleine dieses Freature fast 30fps.
 
Zuletzt bearbeitet:
mickthebike schrieb:
Wie macht Valve es denn mit Left4dead etc. Wenn ich mich recht erinnere laufen die sogar schneller als auf Windows?
​Natürlich. Valve will ja auch ihr SteamOS puschen ;) Also darauf würde ich jetzt nicht viel geben
 
CCIBS schrieb:
​Natürlich. Valve will ja auch ihr SteamOS puschen ;) Also darauf würde ich jetzt nicht viel geben

Wenn du mir nun erklärst was das eine mit dem anderen zu tun hat.
Also die für jeden nachprüfbare bessere Performance von L4D2 unter Linux und Valves Interessen mit SteamOS.
Wenn Valve sicher ein wenig mehr Ehrgeiz zeigt als andere Entwickler bei den Portierungen gibt es doch keinen Weg das irgendwie negativ auszulgen. Eher zeigt es doch auf, dass OpenGL halt sehr wohl besser performt als Direct3D. Man muss es halt nur gescheit umsetzen.

Ab OpenGL 4.2 gab es sogar noch Features um den Ovehead zu minimieren, jedoch hat das bisher kaum jemand mal umgesetzt und nun da Vulkan da ist wird das auch wohl keiner mehr mal umsetzen.

Ein weiterer Grund warum es bei Source Spielen recht gut geht ist, dass diese Engine recht modular aufgebaut ist, was vieles vereinfacht.
Bei anderen Engines ist das nicht so sehr ausgeprägt bis teilweise gar nicht vorhanden. Da muss man für nen Port teilweise wirklich alles auf links drehen anstatt nur die nötigen Dinge.
Die beiden Porter von Dying Light haben das in einer Talkrunde mal sehr gut beschrieben. Die sind gegen Ende der Arbeiten am Spiel dazugestoßen und mussten dann mit dem Arbeiten was da war. Natürlich waren die Entwickler der Win-Version nicht bereit nochmal alles umzuwerfen, also musste man mit Tricks und Workarounds Lösungen für Probleme finden, welche im Grunde leicht zu beheben wären, wenn die Struktur des Spiels eine andere wäre. Der Zustand dieses Spiels diehnt bis heute als Paradebeispiel für eine eher schlechte Portierung, wobei ich dabei nichtmal den beiden Portern die Schuld geben will. Jedes Update ist im Grunde ein Lottospiel ob es danach noch läuft.

Das ist wie als wenn du dein Auto nachträglich auf Gas umrüstest. Es geht zwar, aber du musst an manchen Punkten abstriche machen. Wäre das Auto von Anfang an dafür designd worden, wäre es eleganter zu lösen gewesen.
 
Zuletzt bearbeitet:
PlayX schrieb:
Wenn du mir nun erklärst was das eine mit dem anderen zu tun hat.
Also die für jeden nachprüfbare bessere Performance von L4D2 unter Linux und Valves Interessen mit SteamOS.
Wenn Valve sicher ein wenig mehr Ehrgeiz zeigt als andere Entwickler bei den Portierungen gibt es doch keinen Weg das irgendwie negativ auszulgen. Eher zeigt es doch auf, dass OpenGL halt sehr wohl besser performt als Direct3D. Man muss es halt nur gescheit umsetzen.

Ab OpenGL 4.2 gab es sogar noch Features um den Ovehead zu minimieren, jedoch hat das bisher kaum jemand mal umgesetzt und nun da Vulkan da ist wird das auch wohl keiner mehr mal umsetzen.
Und du glaubst ernsthaft, dass sich Valve bei Direct3D genauso viel mühe gab als wie bei OpenGL? Natürlich haben die sich da nur so viel mühe gegeben, wie notwendig. Genauso wie hier bei Tomb Raider der Fall anders herum ist.
​Also daraus Schlussfolgern, weil "Valve" sich bei einem Spiel bei OpenGL mehr mühe gab wie für Direct3D, dass OpenGL performer läuft, halte ich für ziemlich blauäugig.
 
CCIBS schrieb:
Und du glaubst ernsthaft, dass sich Valve bei Direct3D genauso viel mühe gab als wie bei OpenGL? Natürlich haben die sich da nur so viel mühe gegeben, wie notwendig. Genauso wie hier bei Tomb Raider der Fall anders herum ist.
​Also daraus Schlussfolgern, weil "Valve" sich bei einem Spiel bei OpenGL mehr mühe gab wie für Direct3D, dass OpenGL performer läuft, halte ich für ziemlich blauäugig.
Das die Linuxumsetzung von L4D2 auch erst viele Jahre nach dem Windows Release kam weißt du aber schon oder? Die wollten die Source Engine damals doch wenn möglich auch weiter lizensieren. Die werden sich da schon Mühe gegeben haben. Immerhin stand man damals in Konkurenz mit der IDTech4 und der UE2.5
 
Zuletzt bearbeitet:
@CCIBS, wenn du Dinge in seine Aussage reininterpretierst, die er nie gesagt hat, dann ist das deine Sache. Fakt ist nunmal, dass die Valve-Spiele auch erst nachträglich auf OpenGL portiert wurden (eben mit ToGL) und dass sich Valve die Mühe gemacht hat, die Dinger ordentlich ans laufen zu kriegen. Was im Endeffekt auch gelungen ist.

Ich weiß nicht, ob du jetzt auch zu den Die-Hard-Dx11-Fanboys gehörst, aber du benutzt gerade genau dieselben Argumente, mit denen wir hier die ganze Zeit klarzustellen versuchen, dass ein Linux-Spiel mit GL nicht per se langsamer laufen muss als der Dx9/11-Counterpart unter Windows. Natürlich hat Valve ein Interesse daran, dass die Spiele auf dem eigenen OS möglichst gut laufen, aber das warum stand nie zur Debatte, es geht um das wie. Und das ist mit einem einzigen Wort zu beantworten: Optimierung.
 
@PlayX
Nochmals für Dich. Schau dir mal dir die Werte an. Eine von mir abgelaufene Strecke wo alles an FPS passiert. Da sind deine Werte vom internen Benchmark gegen Dreck. Das ist bei Arch als auch bei OpenSuse bei mir.

2.jpg3.jpg4.jpg5.jpg6.jpg7.jpg
 
Zurück
Oben