News Nintendo: Switch 2 und Switch 1 sind hardwareseitig inkompatibel

Hab ich was verpasst? Es ist doch immer noch arm oder?

Das bedeutet, dass es kompatibel ist. Es ist nur keine identische Hardware der Switch (1) verbaut wie bei früheren Konsolen bei einem Architektur Wechsel. Aber das ist doch auch gar nicht nötig jetzt?

Verstehe ich hier was nicht? Soll das nur fancy klingen?
 
Hab ich was verpasst? Es ist doch immer noch arm oder?
ARM ist nicht gleich ARM und GeForce ist nicht gleich GeForce.

Mit der Zeit gab es bei ARM einige Softwareerweiterungen, die die Kerne unterscheiden. Bei der GeForce ist der Sprung mit Maxwell zu Ampere sogar deutlich gewaltiger.

Oft mals sind die Probleme aber in der Regel nicht die Hardware - wenn man weitgehend von Assembler als auch bei Nvidia von der NVAPI abstand nimmt. Da kann dann der Compiler vieles regeln.

Ich schätze eher, dass sich bei der Switch 2 die Software-Basis im Zug mit den neune Kernen und Ampere stärker geändert hat und die alte Switch API nicht kompatibel zur Switch 2 API gestaltet wurde und man deswegen eine Emulation/Übersetzung benötigt. Man muss entsprechend die API-Zugriffe der Switch-API so ummünzen, dass sie auch mit der Switch 2 funktionieren.

Da das aber "schwer" zu erklären - viele verstehen die Probleme auf Software-Ebene nicht - wird hier die Hardware vorgeschoben.
 
zu sein (was ein Emulator tut).
Kurz da mal als Ergänzung: Ab wann ist ein Emulator ein Emulator?

Klar, Wine/Proton schreiben, dass sie kein Emulator sind, nur ist das - je nachdem wie streng man gewisse Aspekte auslegt - so nicht richtig. Das Problem ist hier die Frage eben, ab wann ein Emulator als Emulator bezeichnet wird.

Wine/Proton bedient sich weitgehend vieler Techniken, die man auch in "klassischen" Emulatoren findet. Wine basiert sogar auf einem Grundsatz, den quasi jeder Emulator hat. Das sind wir auch damals im Studium durchgegangen.

Wine ist in der Form kein "klassischer" Emulator, weil kein ganzes Betriebssystem emuliert wird. Es bildet aber die WinAPI und Proton eben DirectX zu weiten Teilen nach - was auch ein Emulator macht - und übersetzt dann die eine API zur anderen - was auch ein Emulator macht. Der Translator ist ein wichtiger Bestandteil eines Emulator.

Nehme ich aus Datenintegrität, Datenarchivierung und Co die Vorlesungen, dann ist bereits dieses "Übersetzen" durchaus schon als Emulation zu bezeichnen. Nur dass sich Wine/Proton den ganzen Rest dann spart, was viel Leistung kosten kann.
 
Ich bin gespannt wie sich die Switch 2 verkauft. Denn der deutlich gestiegene Anschaffungspreis und die nicht garantierte Abwärtskompatibilität halte ich für große Hürden bei potentiellen Käufern. Ich hab ne Switch und werde mir sehr wahrscheinlich niemals eine Switch 2 kaufen. Ist mir zu teuer und dann nicht mal garantiert alle Switch Spiele spielen zu können ist für mich der Genickbruch. Teure Nintendos haben sich aber auch nie besonders gut verkauft.
 
Ich bin gespannt wie sich die Switch 2 verkauft. Denn der deutlich gestiegene Anschaffungspreis und die nicht garantierte Abwärtskompatibilität halte ich für große Hürden bei potentiellen Käufern. Ich hab ne Switch und werde mir sehr wahrscheinlich niemals eine Switch 2 kaufen. Ist mir zu teuer und dann nicht mal garantiert alle Switch Spiele spielen zu können ist für mich der Genickbruch. Teure Nintendos haben sich aber auch nie besonders gut verkauft.
Ich denke die Switch 2 wird sicherlich wieder ein voller Erfolg
 
Und genau dieses zur Laufzeit übersetzen statt Hardware zu emulieren ist es eben was eine Übersetzungsschicht von einem Emulator unterscheidet.
Ich glaube, dass man von einer Übersetzung der Laufzeit und nicht zur Laufzeit spricht, auch wenn es zur Laufzeit passiert. Eigentlich müsste es vermutlich am ehesten noch Laufzeitumgebung heißen. Man hat also eine Übersetzungsschicht, die zur Laufzeit eine Laufzeitumgebung in eine andere übersetzt. Klingt jetzt nach Haarspalterei, aber ein Emulator übersetzt gegebenenfalls auch zur Laufzeit.
Kurz da mal als Ergänzung: Ab wann ist ein Emulator ein Emulator?

Klar, Wine/Proton schreiben, dass sie kein Emulator sind, nur ist das - je nachdem wie streng man gewisse Aspekte auslegt - so nicht richtig. Das Problem ist hier die Frage eben, ab wann ein Emulator als Emulator bezeichnet wird.
So wie ich das sehe, sobald eine andere Hardware vorgegaukelt wird, was Wine und Proton aber nicht tun. Wenn mein Stand korrekt ist, wandelt Wine Windows-Systemaufrufe in Linux-Systemaufrufe um, während der Rest ganz normal nativ läuft und Proton DirectX-Aufrufe in Vulkan-Aufrufe, die dann auch ganz normal auf der Grafikkarte laufen.
Recompiler statt klassische Interpreter zu benutzen ist stand der Technik bei allen aktuellen Emulatoren.
Aber sind das dann wirklich noch Emulatoren? Passiert das JIT? Ansonsten hat man am Ende doch einfach ein neues, kompatibles Programm.
 
Aber sind das dann wirklich noch Emulatoren? Passiert das JIT? Ansonsten hat man am Ende doch einfach ein neues, kompatibles Programm.
Man nennt es jedenfalls Emulator.
Ein RPCS3 kompiliert während des Spielens JIT die PS3 Shader auf Vulcan um und speichert die dann aber zum späteren nachladen.
Für N64 gibt es afaik mittlerweile tatsächlich einen Cross Compiler und man hat am Ende ein ausführbares x86 Programm.
 
Was man mit Sicherheit bei den Titeln die funktionieren erwarten kann, ist eine stabilere Framrate. Es gab ja auf der Switch so einige Titel in bestimmten Szenen nur noch mit sehr wenig FPS liefen. Die 30 FPS wird die Switch 2 dann vermutlich immer halten können.
 
Zuletzt bearbeitet:
Kurz da mal als Ergänzung: Ab wann ist ein Emulator ein Emulator?

Klar, Wine/Proton schreiben, dass sie kein Emulator sind, nur ist das - je nachdem wie streng man gewisse Aspekte auslegt - so nicht richtig. Das Problem ist hier die Frage eben, ab wann ein Emulator als Emulator bezeichnet wird.
Ich dachte tatsächlich, die Antwort wäre einfach und ich würde sie kennen :D.
Nur dachte ich auch, die Definition wäre trennscharf.

Seis drum, die teils fast philosophischen Gedanken dazu sind sehr interessant :).
 
Hab ich was verpasst? Es ist doch immer noch arm oder?

Das bedeutet, dass es kompatibel ist. Es ist nur keine identische Hardware der Switch (1) verbaut wie bei früheren Konsolen bei einem Architektur Wechsel. Aber das ist doch auch gar nicht nötig jetzt?

Verstehe ich hier was nicht? Soll das nur fancy klingen?

Nur weil beides ARM-Systeme sind, bedeutet das nicht, dass sie automatisch kompatibel sind. Du kannst das MacOS für Appels M-Prozessoren ja auch nicht auf einem Raspi installieren. Das ist alles ein wenig komplizierter. Vielleicht mag es jemand erklären, der sich richtig damit auskennt.
 
ARM ist nicht gleich ARM und GeForce ist nicht gleich GeForce.

Mit der Zeit gab es bei ARM einige Softwareerweiterungen, die die Kerne unterscheiden. Bei der GeForce ist der Sprung mit Maxwell zu Ampere sogar deutlich gewaltiger.

Oft mals sind die Probleme aber in der Regel nicht die Hardware - wenn man weitgehend von Assembler als auch bei Nvidia von der NVAPI abstand nimmt. Da kann dann der Compiler vieles regeln.

Ich schätze eher, dass sich bei der Switch 2 die Software-Basis im Zug mit den neune Kernen und Ampere stärker geändert hat und die alte Switch API nicht kompatibel zur Switch 2 API gestaltet wurde und man deswegen eine Emulation/Übersetzung benötigt. Man muss entsprechend die API-Zugriffe der Switch-API so ummünzen, dass sie auch mit der Switch 2 funktionieren.

Da das aber "schwer" zu erklären - viele verstehen die Probleme auf Software-Ebene nicht - wird hier die Hardware vorgeschoben.
Und wie funktioniert das dann unter Android mit Apps die zum Teil schon uralt sind ? Warum laufen die immer noch problemlos unter neuen Android Versionen mit modernen A78 cores ?

Ist ähnlich wie beim PC, ich kann mit meinem 5700X3D auch uralte Windows 98 Spiele ausführen, die noch weit entfernt waren das sie auch nur wenigstens die allerersten SSE instruktionen nutzen, sondern noch auf reinen x86 code basieren, und trotzdem funzt es problemlos

Ich weiss von der PS4 das es da anders sein soll, die Spiele bringen alles mit was zu Ihrer Ausführung gebraucht wird, das System der Playstations hält da wohl nicht sowas wie irgendwelche "visual c++ redistributable" Versionen vor, nutzt ein Spiel vielleicht nur sse 4.1 und noch kein avx, weiss die Konsole das über executeables vom Spiel

Beim Grafiktreiber ist's ja, zumindest was nvidia betrifft, ähnlich, die müssen nur Aufwärtskompatibel zu den neusten Spielen gemacht werden, und selbst wenn nicht laufen die Spiele ja oft trotzdem, vielleicht mit ein paar Einbußen, aber das war's in der Regel auch schon, ansonsten kann man ja machen was man will, z.B Far Cry 2 spielen, was ja noch auf maximal directx 10 basiert

Ich werd das Gefühl nicht los das bei der Switch 2 die Unterschiede hauptsächlich an der Software, bzw dem neuren OS liegen, bei der nvidia GPU ist außer dx 12.2 wegen Raytracing ab Turing ja nicht viel dazu gekommen, die A78 cores basieren jetzt eben auf Armv8.2 anstelle von 8.0 bei den A57 cores der switch 1, was in meinen Augen den Unterschied darstellen sollte der noch am ehesten für die "Inkompatibilitäten" verantwortlich sein dürfte, aber wie gesagt, mein neues Handy mit 2x A78 cores kann eine olle GBA emulator app trotzdem noch problemlos ausführen, trotz Warnmeldung ... neues Handy ist Android 15 im Vergleich zu 9 beim alten ...
 
Ist natürlich völliger Blödsinn. Natürlich sind sie kompatibel. Eine Swich ist einfach nur ein PC auf ARM Basis als CPU mit einer Nvidia GPU. Nintendo lügt aus bestimten Gründen. Lügen Nintendo lügt und ist gierig. Das war schon immer so.
 
So wie ich das sehe, sobald eine andere Hardware vorgegaukelt wird, was Wine und Proton aber nicht tun. Wenn mein Stand korrekt ist, wandelt Wine Windows-Systemaufrufe in Linux-Systemaufrufe um, während der Rest ganz normal nativ läuft und Proton DirectX-Aufrufe in Vulkan-Aufrufe, die dann auch ganz normal auf der Grafikkarte laufen.
Zu Deiner Frage, warum das nicht als Emulator bezeichnet:

"Wine (WINE Is Not an Emulator) – kein Emulator, da lediglich API-Funktionen emuliert werden (der Code als solches jedoch direkt ausgeführt wird)"

de.wikipedia.org/wiki/Emulator
 
Nur weil beides ARM-Systeme sind, bedeutet das nicht, dass sie automatisch kompatibel sind. Du kannst das MacOS für Appels M-Prozessoren ja auch nicht auf einem Raspi installieren. Das ist alles ein wenig komplizierter. Vielleicht mag es jemand erklären, der sich richtig damit auskennt.

Ich finde Apple's CPUs sollte man hier nicht gerade als Vergleiche verwenden, die Dinger sind seit über 10 Jahren komplette Eigenentwicklungen zu denen nicht viel bekannt ist wie Sie genau funktionieren, man weiss eigentlich nur das deren Technik mit der von ARM im Grundaufbau verwandt ist, und es nicht auf MIPS oder sonstwas basiert, aber ansonsten läuft Apple nicht wie so gut wie alle anderen zur ARM Holding group und lizenziert da die neusten X3 Cores die diese derzeit im Angebot haben und baut das dann in Ihre CPU's ein, sondern entwickelt eben alles selber und schneidet die Sachen auf Ihre ganz eigenen Produkte zu.
 
Vielleicht liegt es wirklich eher an der Software.
Analog zu Windows und Linux am PC, nur das PC Betriebssysteme von Haus aus auf verschiedene Hardware ausgelegt sind, während das Konsolen OS im Grunde nur die eine Hardware kennt.
Jetzt hat man die ganze Software und die Treiber auf die neue Hardware maßgeschneidert und jetzt fehlen wohl einige Sachen, die nur wenige Spiele überhaupt genutzt haben.
 
KI generierter Beitrag (ChatGPT)


Nintendo Switch 1 vs. Switch 2 – Warum keine Hardwarekompatibilität, obwohl beides ARM?

Nintendo behauptet, dass Spiele der originalen Switch nicht auf der Switch 2 laufen – wegen angeblicher Hardware-Inkompatibilität. Das wirkt auf den ersten Blick seltsam, denn beide Konsolen basieren auf ARM-SoCs (ARMv8). Die Switch 1 verwendet einen Tegra X1, und die Switch 2 soll laut Leaks auf einem Jetson Orin AGX basieren – also beides ARMv8. Wie kann es da also zu Inkompatibilitäten kommen?

Hier mal eine technische Gegenüberstellung:

Vergleich: Tegra X1 (Switch 1) vs. Jetson Orin AGX (Switch 2)

MerkmalTegra X1 / X1+ (Switch 1)Jetson Orin AGX (Switch 2)
Release2015 / 20192022
CPU-Kerne4× Cortex-A57 + 4× Cortex-A538–12× Cortex-A78AE
CPU-ArchitekturARMv8-AARMv8.2-A
GPU-ArchitekturMaxwellAmpere
CUDA-Kerne256Bis zu 2048
Tensor-CoresNeinJa
RAM-TypLPDDR4LPDDR5
Speicherbandbreite~25 GB/sBis zu 204 GB/s
Video-Encoding4K H.264/H.2658K + AV1 (teilweise)
TDP10–15 W15–60 W (anpassbar)
Fertigung20 nm8 nm (TSMC)

Was bedeutet das für die Kompatibilität?

– Obwohl beide SoCs ARMv8 verwenden, ist vor allem die GPU sehr unterschiedlich: Maxwell (Switch 1) vs. Ampere (Switch 2). Shader, Grafiktreiber und Renderingverhalten sind nicht kompatibel.

– Viele Spiele auf der Switch 1 sind eng an die Eigenheiten der Maxwell-GPU angepasst (z. B. Custom Shader, Low-Level-Hacks), was auf der Ampere-GPU schlicht nicht funktioniert.

– Auch das OS der Switch 2 dürfte anders aufgebaut sein: neue Treibermodelle, neue APIs (evtl. Vulkan statt OpenGL ES), anderes Ressourcenmanagement.

– Speicherlatenzen, Audio-Hardware, Video-Engines und Peripherie-Verhalten unterscheiden sich ebenfalls, was für „bare-metal“-Spiele schnell zu Problemen führt.

– Und nicht zuletzt könnte Nintendo auch bewusst auf echte Kompatibilität verzichten, um gezielt Neuverkäufe (Remaster etc.) zu ermöglichen.

Fazit: Rein von der CPU-Architektur wäre eine Kompatibilität durchaus denkbar. Aber die stark unterschiedliche GPU, das veränderte OS, Treiber und Timing-Verhalten machen eine echte Kompatibilität auf Hardware-Ebene nahezu unmöglich – oder zumindest extrem aufwändig. Wenn Nintendo will, könnten sie über Emulation oder einen Kompatibilitätsmodus nachhelfen – aber aktuell scheint das nicht vorgesehen zu sein.
 
Zuletzt bearbeitet:
Und wie funktioniert das dann unter Android mit Apps die zum Teil schon uralt sind ? Warum laufen die immer noch problemlos unter neuen Android Versionen mit modernen A78 cores ?
Android Apps werden bei der Installation aus einem Zwischencode neu für die jeweilige Plattform kompiliert
Früher während der Ausführung

Das ist deutlich mehr Abstraktion als man bei einer effizienten Spielekonsole haben will.
Dem Verhalten von C# ähnlich, Spiele benutzen aber in der Regel C++.
 
Zurück