Proton: Valve testet ARM-Kompatibilität für Steam-Spiele

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.978
Valve hat offenbar noch viel mit dem eigenen Betriebssystem SteamOS vor. Ein Update einer Testanwendung verrät, dass Valve augenscheinlich die Unterstützung der ARM64-Architektur in seine Übersetzungsschicht Proton implementiert hat. Daraus lässt sich ableiten, dass Valve zukünftig Steam-Spiele auch auf ARM-Plattformen zugänglich machen möchte, möglicherweise sogar das gesamte Betriebssystem SteamOS.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Jetzt wird es langsam interessant…
 
Der Vergleich mit Linux hinkt imho ein wenig stark. Linux hat es eigentlich nie an Leistungsfähigkeit gemangelt und das konnte man auch damals direkt sehen. So ziemlich alle älteren Spiele von id-Software liefen unter Linux.... nativ... iirc mit OpenGL und das auch ohne nennenswerte Performanceprobleme auf gleicher Hardware. Nur hat sich dann Microsoft mit DirectX/3D etabliert und DAS war das Problem von Linux. Hätte es D3D nicht gegeben, sondern man wäre bei OpenGL geblieben oder sowas wie Vulkan wäre wesentlich früher gekommen, dann hätte es weite Teile von Proton gar nicht gebraucht, z.B. das ganze DXVK, was ja Spiele erst (wieder) unter Linux brauchbar gemacht hat.

ARM-CPUs dagegen fehlte lange Zeit tatsächlich die Hardwareleistung. Daran hätten auch diverse Softwarelayer nichts ändern können.

Ich denke, wenn Valve aktiv ARM-Unterstützung durch Proton vorantreibt, dann könnte das evtl. durchaus schneller brauchbar werden, als man vielleicht erstmal annehmen würde. Hat Apple nicht quasi das exakt gleiche Kunststück vollbracht, als sie von x86 zu ARM gewechselt sind? Rosetta oder wie die Übersetzungsschicht dort hieß.... oder sogar immernoch heißt?
 
Der Emulator, der Intel x86_64 Code in ARM Code wandelt heißt fex-emu oder Box64. Beides kommt nicht von Steam.
Man nutzte bisher also Proton+Windows Spiel+dxvk und lies es vom Emulator nativ auf ARM laufen.

Neu ist nun, dass man nur noch das x86_64 Spiel von fex-emu/Box64 emulieren lässt und Proton und dxvk native ARM Programme sind und nicht auch noch emuliert werden müssen.


Das das alles sehr gut funktioniert, kann man hier sehen.
Hier haben Leute ARM-Ubuntu auf der Switch installiert und danach Steam+Proton+Box64.

Link

1727105956215.png


Selbst aktuelle Windows Spiele wie Titanfall 2 laufen mit 20 fps auf der Switch !!!

Da auf ALLEN aktuellen Snapdragon CPUs momentan noch kein natives Linux läuft, lässt sich nicht abschätzen wie gut das auf denen laufen wird.
 
Zuletzt bearbeitet:
Sehr interessant, hab mit hängen und würgen das ein oder andere kleine Game unter ARM am laufen, mal schauen ob der Panfrost Treiber für meinen RK3588 jetzt dann mal mehr Rückenwind erfährt.
 
Selbst aktuelle Windows Spiele wie Titanfall 2 laufen mit 20 fps auf der Switch !!!
Wow, das ist extrem beeindruckend. Das zeigt aber auch, wie wenig die Spiele auf der Switch an sich dann noch optimiert werden, wenn sogar das hier gefühlt effizienter ist als native Switch-Spiele. Die meisten erreichen ja nicht mal die native Auflösung von lächerlichen 720p.
 
Dazu fällt mir nur eine Sache ein "JAAAA" :banana:
 
Worin besteht jetzt das beeindruckende wenn eine 300€ Konsole das gleiche hinbekommt wie ein 75€ x86 system? (wertungsfrei)
 
Worin besteht jetzt das beeindruckende wenn eine 300€ Konsole das gleiche hinbekommt wie ein 75€ x86 system? (wertungsfrei)

Es sind die Softwarelayer, die dies alles ermöglichen. Ebenso die harte Arbeit von verschiedensten Teams, die alle mit ihrer Software dazu beigetragen haben.
Das Ziel ist am Ende, das man JEDES Windows Programm/Spiel, auf JEDEM Computer, ganz egal welcher CPU basierend, laufen lassen kann.

Schon heute ist es möglich Windows Software/Spiele, ohne Microsoft Lizenzen zu nutzen.
Das bedeutet, man kann ab heute endlich neue CPUs designen und hat sofort Zugriff auf Millionen von Programmen, die direkt darauf laufen.
Denn in der Vergangenheit hatten sich andere CPU Architekturen nicht durchgesetzt, weil es eben keine Software dafür gab. Das hat sich ab heute komplett geändert. Die Softwarelayer zeigen, das heutige CPUs schnell genug sind, um on-the-fly Programmcode zu übersetzen und laufen zu lassen, selbst auf so lahmen Rechnern, wie der Switch.
 
Zuletzt bearbeitet:
Denn in der Vergangenheit hatten sich andere CPU Architekturen nicht durchgesetzt, weil es eben keine Software dafür gab. Das hat sich ab heute komplett geändert. Die Softwarelayer zeigen, das heutige CPUs schnell genug sind, um on-the-fly Programmcode zu übersetzen und laufen zu lassen, selbst auf so lahmen Rechnern, wie der Switch.
Die Möglichkeit, das das geht ist natürlich toll, aber da entsteht auch gerade schon wieder ein riesen Haufen umständlicher (Legacy)Softwarelayer.

Man entwickelt Software auf Windowsschnittstellen wie Win-API, DirectX, etc. um die dann mit anderen Emulatoren, Wrappern, etc auf Hardwaresystemen UND Softwaresystem laufen zu lassen. Nur waren die Windowsschnittstellen nie dafür gedacht und schon gar nicht darauf ausgelegt. Und auch wenn CPUs "schnell genug" sind, kostet es trotzdem irgendwo Leistung, die dann eben nicht für andere Sachen zur Verfügung steht.

Das ist ungefähr so, wie wenn man unter ein altes Bruchsteinschloss eine Tiefgarage unten drunter baut, ohne das Gebäude abzureissen. Da kommt mir direkt der Gedanke an Denkmalschutz. :ROFLMAO:
In 50 Jahren wird Windows als Betriebssystem evtl. ausgestorben sein, aber seine APIs leben immernoch, evtl wird sogar immernoch neue Software dafür entwickelt, obwohl es das Betriebssystem schon nichtmehr gibt. Einfach weil ja die nötigen Kompatibilitätslayer ja trotzdem vorhanden sind und man es "halt schon immer so gemacht hat".

Id-Software hat früher, wie oben schon erwähnt immer Linux-Versionen ihrere Spiele gemacht, gepflegt, vertrieben. Es gibt ein Interview von John Carmack, in dem er sagt, das sie keine Linux-Versionen mehr machen werden, weil Wine/Proton funktioniert mittlerweile so gut und zuverlässig, das sie sich den Aufwand extra eine Linuxversion zu pflegen einfach sparen wollen. Aber in irgendeinem Nebensatz erwähnte er iirc immerhin, das sie ihre Windows-Versionen auch explizit mit Wine/Proton testen werden.

Ich kanns absolut verstehen, ich bin selbst Softwareentwickler und weiß aus erster Hand wie nervig Multiplatformentwicklung ist. Aber man schafft sich da gerade wieder einen ganzen Softwarestackbloat und ich befürchte dabei, das das wiedermal so ein "Provisorium für die Ewigkeit" wird.
 
Trotzdem in Summe eine nette Geschichte, das es nicht super elegant ist.. ist halt leider so. Aber es funktioniert und die Hemmschwelle für Windows als Mainsystem sinkt halt.
 
Die Möglichkeit, das das geht ist natürlich toll, aber da entsteht auch gerade schon wieder ein riesen Haufen umständlicher (Legacy)Softwarelayer.

Man entwickelt Software auf Windowsschnittstellen wie Win-API, DirectX, etc. um die dann mit anderen Emulatoren, Wrappern, etc auf Hardwaresystemen UND Softwaresystem laufen zu lassen. Nur waren die Windowsschnittstellen nie dafür gedacht und schon gar nicht darauf ausgelegt. Und auch wenn CPUs "schnell genug" sind, kostet es trotzdem irgendwo Leistung, die dann eben nicht für andere Sachen zur Verfügung steht.

Da muss ich leider einhaken.
Mit Emulatoren hat das auch nichts mehr zu tun. Der Programmcode wird nicht mehr Emuliert. Er wird vor dem Programmstart in den nativen Code der neuen CPU codiert, komplett. Erst dann wird das neue erstellte Programm laufen gelassen. Das klappt so gut, das es keine Nachteile in der Geschwindigkeit gibt.

Apple macht es mit ihrem Rosetta2 genau so, x86 Code zu ARM Code.
Die Software wird dadurch nicht langsamer.

Man kann sich das wie Java Code vorstellen. Dieser wird auch einmal für eine virtuelle CPU compiliert und läuft dann auf jeder CPU, egal welche Architektur.

Id-Software hat früher, wie oben schon erwähnt immer Linux-Versionen ihrere Spiele gemacht, gepflegt, vertrieben. Es gibt ein Interview von John Carmack, in dem er sagt, das sie keine Linux-Versionen mehr machen werden, weil Wine/Proton funktioniert mittlerweile so gut und zuverlässig, das sie sich den Aufwand extra eine Linuxversion zu pflegen einfach sparen wollen. Aber in irgendeinem Nebensatz erwähnte er iirc immerhin, das sie ihre Windows-Versionen auch explizit mit Wine/Proton testen werden.

Es ist halt einfacher Software für eine Plattform zu erstellten und diese dann überall laufen zu lassen. Ich denke die Zukunft wird die Windows-API sein und diese dann auf jedem System zu "emulieren".

Ich kanns absolut verstehen, ich bin selbst Softwareentwickler und weiß aus erster Hand wie nervig Multiplatformentwicklung ist. Aber man schafft sich da gerade wieder einen ganzen Softwarestackbloat und ich befürchte dabei, das das wiedermal so ein "Provisorium für die Ewigkeit" wird.

Das schöne daran ist, der Softwareentwickler muss seine Software nicht mehr für 3 Plattformen entwickeln und testen, sondern nur noch für eine. Die Software läuft dann auf den anderen Plattformen dank der "Emulation". Firmen wie Steam kümmern sich um die perfekte "emulation" und Updaten die "Emulatoren". Ein Win/Win für alle.
 
Mit Emulatoren hat das auch nichts mehr zu tun. Der Programmcode wird nicht mehr Emuliert.
Deswegen habe ich auch noch Komma Wrapper Komma etc. dazu geschrieben. Ich weiß das das kein Emulator ist, ich weiß auch das WINE ausgeschrieben sogar "Wine is not an emulator" heisst. :ROFLMAO:

Er wird vor dem Programmstart in den nativen Code der neuen CPU codiert, komplett. Erst dann wird das neue erstellte Programm laufen gelassen. Das klappt so gut, das es keine Nachteile in der Geschwindigkeit gibt.
Dann braucht die Zielplatform eigentlich keinen Kompatibilitätslayer mehr, denn dann könnte man das ja einmalig für die jeweilige Zielplatform codieren lassen und der Zielplatform dann gleich das gerade passend konvertierte Binary zur Verfügung stellen.

Man kann sich das wie Java Code vorstellen. Dieser wird auch einmal für eine virtuelle CPU compiliert und läuft dann auf jeder CPU, egal welche Architektur.
Bei Java war das aber von Anfang so vorgesehen, das der Binärcode eben platformunabhängig sein soll, die Zielplatform dafür dann aber eben eine Laufzeitumgebung braucht um dieses Binary überhaupt ausführen zu können.
Quasi das Mittelding zwischen Interpreter und Kompiler. Aber von Anfang an im Konzept so vorgesehen.

Ich denke die Zukunft wird die Windows-API sein und diese dann auf jedem System zu "emulieren".
Ich hoffe nicht.
Platformunabhängigkeit gerne, aber nicht auf einer zugemüllten, veralteten Legacy-API aufbauend.

Das schöne daran ist, der Softwareentwickler muss seine Software nicht mehr für 3 Plattformen entwickeln und testen, sondern nur noch für eine. Die Software läuft dann auf den anderen Plattformen dank der "Emulation". Firmen wie Steam kümmern sich um die perfekte "emulation" und Updaten die "Emulatoren". Ein Win/Win für alle.
Was genau hast du an "Ich bin selbst Softwareentwickler und habe schon Multiplatformentwicklung machen dürfen" nicht verstanden? :ROFLMAO:
Man muss/sollte übrigens trotzdem noch auf den Zielplatformen testen. Wie ich oben schon geschrieben habe, hat Id-Software sogar gesagt, das sie das explizit tun. Es gibt auch immernoch Spiele (und andere Software), die unter Linux mit Proton nicht so sauber läuft wie unter Windows. Von irgendwelchen nebensächlichen Glitches, bis hin zu Abstürzen.
Es ist nicht nur so, das eine andere CPU-Architektur anderen Binärcode braucht, alleine schon die komplette Systemumgebung kann abweichen. Unter Linux gibts z.B. keine Laufwerksbuchstaben. Somit funktioniert schon sowas simples wie einfach nur eine Datei öffnen wie es Windows tut unter Linux eben nicht. Da sorgt erst Wine dafür. Und das nervt mich sogar mit Steam ein wenig, weil deswegen es für jedes Spiel eine separate virtuelle Umgebung anlegt. Und dann kannste immer ewig Ordner durchsuchen, bis du den findest, der auch zu dem Spiel gehört, wo man gerade was ändern will.

Das ich den Win/Win nachvollziehen kann, habe ich eben ja geschrieben, nur das da eigentlich noch /Loss hinten angehängt gehört. Es machts dem Softwareentwickler leichter, es machts dem Anwender leichter, es verbessert die Verfügbarkeit von Software, aber man bindet sich eben auch einen riesigen Legacy-Klotz ans Bein und durch diverse Softwarelayer wird das Gesamtsystem auch wieder komplexer.

Das ganze ist ein Henne-Ei-Problem... wenn es das nicht wäre, hätte man mit Java schon seit wieviel... 30? Jahren die entsprechende Lösung an der Hand gehabt. Und damit meine ich nicht die Sprache ansich, sondern die Funktionsweise der kompletten Umgebung.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh