ConsoleWAR Current Gen Konsolen und Ihre Technik dahinter

[Konsolenbaby]

@Konsolenbaby

Da ist ein wenig viel Spekulation dabei. Meines Erachtens setzt MS bei der XBX wie auch bei der XSX auf Hardwarekompatibilität bis zur One zu gewährleisten.

Nicht, wenn es von MS selber bestätigt wurde
Sie sagen im DF Artikel ja selber, dass nun JEDES ONE Game von der vollen Leistung der XSX profitiert. Bei der X konnten manche Games ohne Patch D nur ein Drittel der Leistung der X nutzen.

Und zu den Unterschieden bei der GPU Ansteuerung von PS4 Und ONE /X mal ein kleines Beispiel

Angenommen:
Das Programm möchte ein Dreieck zeichnen.
Mit Software API (für die Grafikeinheit) läuft das folgender Maßen ab.

Programm übergibt den Befehl: Zeichne ein Dreick an den Grafiktreiber.
Es werden dann diverse Informationen über die Größe, die Lage und sonstiges mit dem Befehl übergeben.

Der Grafiktreiber sorgt nun dafür, dass die GPU die Daten hierfür genau so erhält, wie sie es gerne hätte.
Also z.B
Größe in Register A
Lage in Register B
usw.

Jetzt hat GPU Hersteller B aber intern ein anderes Schema. Denn anders als bei CPUs, gibts hier keine festgesetzen Normen, was das angeht.
Vielleicht erwartet die GPU von Hersteller B nun genau die umgekehrte Reihenfolge.
Also
Größe in Register B
Lage in Register A.

Mit einem Softwaretreiber überhaupt kein Problem.
Im spezilellen Treiber für diese GPU werden einfach die Daten hierfür getauscht.
Das eigentliche Programm merkt davon nix

Das gleiche, wenn sich beim selben Hersteller intern die Abläufe bei späteren GPUs verändern. Was durchaus oft Sinn ergibt.
Auch hier sorgt der Grafiktreiber für die korrekte Umsetzung

Was aber nun, wenn man die GPU direkt anspricht.
Nun.
Beim Wechsel der GPU landen dann plötzlich den Daten für die Größe des Dreiecks im Register für die Lage. Und umgekehrt.
Das führt sicherlich zu lustigen Ergebnissen

Bei der X und der XSX aber wieder kein Problem, da ja hier die eigentlich Umwandlung der Daten in der GPU durch den Microcode gewährleisetet ist.

 

[becko2011]

Oha! Sei mal nicht so gemein.

Ich kann den Farben einfach nichts abgewinnen.

Das geht wirklich besser.

 

[Konsolenbaby]

Doch, das Betriebssystem muss es sogar. Die Befehle unterscheiden sich bspw. bei Intel und AMD etwas, auch wenn die Befehlssatzarchitektur gleich ist. Du kompilierst bei Windows eine Anwendung nicht für eine spezifische CPU, sondern für die Architektur, die sich aber etwa unterscheiden zwischen einzelnen Herstellern. Das Betriebssystem muss da also je nach CPU andere Befehle weiterreichen.

Das stimmt so nicht.
Das OS wandelt gar nichts um. Wäre auch viel zu zeitintensiv.
AMD und Intelbefehle sind komplett gleich.
Es kann maximal sein, dass eine CPU noch zusätzliche Funktionen besitzt, die die andere noch nicht hat.
Ist oder war z.B. bei den MMX und SSE Befehlen der Fall.
Hier aber wandelt nicht das OS die Befehle um sondern im Programmcode sind für beide Versionen unterschiedliche Programmblöcke vorhanden.
Die werden auch beide Compiliert und je nach dem, auf welchem Sytem das Programm dann läuft, wird der entsprechende Programmblock ausgeführt.
Mit dem OS hat das überhaupt nix zu tun.

Doch, das ist der Nachteil von Schichten und Overheads.

"Alles ist sauschnell", aber eben nicht so schnell wie ohne dieser zusätzliche Mehraufwand. Ganz logisch.

Beispielhaft:
Es gibt drei Phasen, Phase 2 ist "sauschnell" (um deine Worte zu nehmen).

System A: Phase 1 -> Phase 2 -> Phase 3.
System B: Phase 1 -> Phase 3.

Egal wie "sauschnell" Phase 2 für System A ist, System B ist schneller fertig.

Ich habe mich mit der genauen Implementation von Microsoft nicht beschäftigt, ist nur allgemein gesagt. Jede einzelne Schicht bringt natürlich Overhead und somit auch Performanceeinbußen. Wenn eine Schicht bzw. das System die Befehle umkonventieren muss, ist sie langsamer als eine System, was es nicht muss, auch wenn die Konvertierung "sauschnell" geht. Dafür profitierst du aber von einer größeren Kompatibilität - der allgemeine Vorteil der Schichten.

Microcode, der direkt in der GPU ausgeführt wird, ist sauschnell und es gibt hier keine spürbare Verzögerung. Selbst wenn die Codeausführung ein paar Takte dauern sollte, die nächsten Befehle sind ja dann schon in der Pipeline. Es gibt also einfach ausgedrückt nur am Anfang eine Verzögerung von ein paar Takten. Danach kommen die Daten kontinuierlich in die Recheneinheiten der GPU.
Und bei einem Takt von fast 2GHz kannst du dir die Verzögerung ja selber ausrechnen
Wir reden hier von ein ein bis zwei Nanosekunden.

 

[Ironman]

Ich kann den Farben einfach nichts abgewinnen.

Das geht wirklich besser.

Ich finds cool. Bis auf die PSX waren Playstation und Peripherie immer schwarz. Ist mal was anderes.

 

[LoLsh0ckx]

Ich finds cool. Bis auf die PSX waren Playstation und Peripherie immer schwarz. Ist mal was anderes.

Ich find auch es sieht gut aus... mal was anderes ... bevorzuge eigentlich schwarz ... aber den Controller find ich schon mal geil. Zu dem wirds ohnehin wieder diverse Farbvarianten geben. Mitunter sicher auch komplett schwarz.

 

[Nullpointer]

Wie schon im Vita - Thread auf CW geschrieben wurde, sind die Tasten wie bei Sonys letzten Handheld. Zumindest scheint man sich daran orientiert zu haben. Das kann ich nur begrüßen

Den Vergleich mit Sonys letztem großen Fail kann ich auch nur begrüßen

Nach der Cerny Präsentation hat sich Sony nochmals via Twitter zur Abwärtskompatibilität zu Wort, gemeldet

„Wir glauben, dass die überwiegende Mehrheit der über 4.000 PS4-Titel auf der PS5 spielbar sein wird.
Wir möchten zunächst jedes einzelne PS4-Spiel prüfen und schauen, ob es wirklich uneingeschränkt auf der PS5 läuft. Zudem könnt ihr erwarten, dass die abwärtskompatiblen Spiele auf der PS5 zum Teil Vorteile bieten. Dazu zählen eine erhöhte Bildrate und „möglicherweise“ höhere Auflösungen. "

"glauben"
"möglicherweise"

Wenn ich es genau wissen will, muss ich wohl wieder nach einer Liste auf GitHub suchen?

Hier übernimmt das Betriebssystem sehr viel und passt es an die eingebaute CPU an (AMD oder Intel bspw.). Das ist so bei Konsolen natürlich nicht gegeben, deren API (vermutlich - habe kein SDK hier) viel tiefer gehen.

Was übernimmt das Betriebssystem denn da? Und was ist bei einer Konsole anders, wenn ich meinen C-Code nach x64 kompiliere und auf Windows oder Xbox ausführe?

 

[Ark]

Das OS wandelt gar nichts um. Wäre auch viel zu zeitintensiv.

Das OS wandelt jeden Speicherzugriff, der virtuell stattfindet, auf eine physische Speicheradresse und wenn nicht vorhanden, dann wird mehr getan (das Betriebssystem schickt es an die MMU). Auch ist das OS für Scheduling verantwortlich und auch das ist stark CPU-abhängig (bspw. bei einem Interrupt, müssen alle Register des Prozessors gespeichert werden - wo glaubst du, sind diese Informationen gespeichert, jede CPU hat unterschiedliche). Was soll daran "zeitintensiv" sein? Das sind die Aufgaben jedes Betriebssystems. Eine Applikation kann niemals direkt auf die CPU zugreifen, das geht immer ausschließlich über das Betriebssystem.

AMD und Intelbefehle sind komplett gleich.

Nein, das Betriebssystem ist dafür verantwortlich, mit der CPU ordnungsgemäß zu kommunizieren. Bspw. arbeitet die MMU bei AMD und Intel anders, Windows würde bei AMD-Prozessoren anders auf die CPU zugreifen, als bei Intel-Prozessoren. Das passiert normalerweise im HAL (Hardware Abstraction Layer).

Die Beispiele sollen aufzeigen, dass das Betriebssystem die CPU selbstverständlich sehr gut kennen muss, ansonsten würde es nicht funktionieren. Du verkaufst es gerade so, als ob dem Betriebssystem egal ist, welche CPU läuft. Nein, die kennen sich sehr gut.

Was übernimmt das Betriebssystem denn da?

Die Kommunikation mit der Hardware.

Und was ist bei einer Konsole anders, wenn ich meinen C-Code nach x64 kompiliere und auf Windows oder Xbox ausführe?

Musst in der Dokumentation des Betriebssystems nachlesen.

 

[Nullpointer]

Die Kommunikation mit der Hardware.

Welcher Hardware? Was genau passt es an meinem kompilierten Code an?

 

[Ark]

Welcher Hardware?

Es gibt genug Literaturen zum Verhältnis zwischen Betriebssystem (Software) und Hardware.

Was genau passt es an meinem kompilierten Code an?

Läuft auf deiner Xbox vermutlich gar nicht, da nicht für die Xbox kompiliert, wenn du auf Adressen zugreifst, wo du bei der Xbox bspw. nichts verloren hast. Dafür gibt es ja das SDK.

Du kannst auch nicht einfach irgendein eingebettetes System nehmen und deinen Code 1:1 für ein anderes System übernehmen, der ja explizit für die Hardware geschrieben ist. Da sind Windows-Applikationen meist natürlich wesentlich mehr "High-Level".

Also nochmal: Lies die Dokumentation.

 

[Nullpointer]

Es gibt genug Literaturen zum Verhältnis zwischen Betriebssystem (Software) und Hardware.

Läuft auf deiner Xbox vermutlich gar nicht, da nicht für die Xbox kompiliert, wenn du auf Adressen zugreifst, wo du bei der Xbox bspw. nichts verloren hast. Dafür gibt es ja das SDK.

Du kannst auch nicht einfach irgendein eingebettetes System nehmen und deinen Code 1:1 für ein anderes System übernehmen, der ja explizit für die Hardware geschrieben ist. Da sind Windows-Applikationen meist natürlich wesentlich mehr "High-Level".

Also nochmal: Lies die Dokumentation.

Hierum ging es
"Hier übernimmt das Betriebssystem sehr viel und passt es an die eingebaute CPU an (AMD oder Intel bspw.)."
Also ändert das Betriebssystem meinen Code nicht sondern der Compiler. So wie es sein soll. Schön das wir das geklärt haben.

 

[Konsolenbaby]

Das OS wandelt jeden Speicherzugriff, der virtuell stattfindet, auf eine physische Speicheradresse und wenn nicht vorhanden, dann wird mehr getan (das Betriebssystem schickt es an die MMU). Auch ist das OS für Scheduling verantwortlich und auch das ist stark CPU-abhängig (bspw. bei einem Interrupt, müssen alle Register des Prozessors gespeichert werden - wo glaubst du, sind diese Informationen gespeichert, jede CPU hat unterschiedliche). Was soll daran "zeitintensiv" sein? Das sind die Aufgaben jedes Betriebssystems. Eine Applikation kann niemals direkt auf die CPU zugreifen, das geht immer ausschließlich über das Betriebssystem.


Nein, das Betriebssystem ist dafür verantwortlich, mit der CPU ordnungsgemäß zu kommunizieren. Bspw. arbeitet die MMU bei AMD und Intel anders, Windows würde bei AMD-Prozessoren anders auf die CPU zugreifen, als bei Intel-Prozessoren. Das passiert normalerweise im HAL (Hardware Abstraction Layer).

Die Beispiele sollen aufzeigen, dass das Betriebssystem die CPU selbstverständlich sehr gut kennen muss, ansonsten würde es nicht funktionieren. Du verkaufst es gerade so, als ob dem Betriebssystem egal ist, welche CPU läuft. Nein, die kennen sich sehr gut.



Die Kommunikation mit der Hardware.



Musst in der Dokumentation des Betriebssystems nachlesen.

Jetzt nicht das Thema wechseln.
Ich glaube, du weißt nicht wirklich, wie die internen Abläufe bei einem System funktionieren.

Es geht nicht ums Speichermanagment. Natürlich ist das OS hierfür zuständig.
Und auch für die Task Aufteilung.
Das OS ist dafür zuständig, jedem Task seine bestimmte Zeit zur Verfügung zu stellen. Und das funktioniert per Hardware Interrupt.
Innerhalb dieser Zeit spricht aber das Programm direkt die CPU an, ohne dass das OS damit was am Hut hätte.
Das OS überwacht nur die Zuteilung

Es geht um die CPU Befehle. Und die haben rein gar nix mit dem OS zu tun.
Wenn der Task gewechselt wird, dann werden die CPU-Register auf dem Stack gesichert. Soweit korrekt
Und das macht auch das OS. Aber dem OS ist es ziemlich Hupe, ob da jetzt eine Intel CPU oder AMD CPU drin steckt.
Denn die Befehle zum sichern des Stack sind bei beiden identisch.
Glaub mir, ich hab schon den Atari 600XL, Amiga, X86 CPUs und diverse microcontroller wie die Atmels in Assembler/Mashinensprache programmiert.
Innerhalb einer CPU Familie bleiben die Befehle gleich.

Ein PowerPC und die von dir angesprochenen Embedded Systeme unterscheiden sich natürlich in ihrem Maschinencode von der X86 Architektur.
Aber ein 64bit Intel und 64bit AMD Prozessor eben nicht bis auf die von mir angeführten propietären Erweiterungen,
Ein AMD Prozessor der neueren Gen ist aber zu seinem Vorgänger 100% Abwärtskompatibel
Er hat eben nur weitere Funktionen, die aber ein Programm, was für den Vorgänger geschrieben wurde, einfach ignoriert.
Und da sowohl die PS5 als auch die XSX sogar innerhalb der gleichen Firma, sprich AMD bleiben, gibts da von CPU Seite, was deren Befehle angeht, überhaupt keine Probleme.


Und @Nullpointer weiß wohl auch ziemlich genau, was da wie abläuft und will dich nur aus der Reserve locken
Und bisher ist das doch ein wenig schwammig, was da von dir kommt.

 

[Ark]

Hierum ging es
"Hier übernimmt das Betriebssystem sehr viel und passt es an die eingebaute CPU an (AMD oder Intel bspw.)."
Also ändert das Betriebssystem meinen Code nicht sondern der Compiler. So wie es sein soll. Schön das wir das geklärt haben.

Das ist so nicht richtig. Auch auf einem eingebetteten System läuft ein OS. Mindestens ein Kernel. Ohne OS geht hardwaretechnisch gar nichts. CPU-spezifische Befehle kann man auf Compiler-Level sicherlich machen - aber nun wieder ein einfaches Beispiel:

Programm ist kompiliert und läuft nun auf zig unterschiedlichen CPUs herstellerunabhängig. Diese CPUs haben auch andere Befehle (nur weil ISA gleich ist, heißt es nicht, dass sie die exakt gleichen Befehle verwenden). Dafür sorgt das Betriebssystem mit ihrem HAL.

Ansonsten müsste man jede alte Anwendung für neue CPUs komplett neu kompilieren, wenn jede Möglichkeit der Befehle ausschließlich der Compiler übernimmt (kann es in der Theorie auch), aber auch Betriebsysteme übernehmen diese Arbeit. Immerhin sind sie für die Kommunikation zwischen CPU und Anwendung verantwortlich. Jedes Betriebssystem hat CPU-spezifische Treiber, die je nach CPU verwendet werden.

Eingebette Systeme haben hier natürlich einen Sonderfall, da sie meistens nicht "General Purpose" sind. Die Hardware ist ja schon bekannt - der Entwickler kann stets auf diese Hardware trimmen. Das ist bei einem Windows-PC nicht der Fall, die unterschiedlichen Feinheiten (Befehle) muss das Betriebssystem kennen. Das ist ein Overhead, der nicht unbedingt bei eingebetteten Systemen notwendig ist, aber auf Windows-Rechnern eben schon.

 

[Nullpointer]

Das ist so nicht richtig. Auch auf einem eingebetteten System läuft ein OS. Ohne OS geht hardwaretechnisch gar nichts.

Ich habe schon auf Systemen ohne OS gearbeitet.

CPU-spezifische Befehle kann man auf Compiler-Level sicherlich machen - aber nun wieder ein einfaches Beispiel:

Programm ist kompiliert und läuft nun auf zig unterschiedlichen CPUs herstellerunabhängig. Diese CPUs haben auch andere Befehle (nur weil ISA gleich ist, heißt es nicht, dass sie die exakt gleichen Befehle verwenden). Dafür sorgt das Betriebssystem mit ihrem HAL.

Der HAL ändert deinen kompilierten Code nicht. Ist in deinem Programm Code enthalten, den deine CPU nicht versteht, gibts eine Prozessor-Exception und dein Programm wird vom OS beendet.

Ansonsten müsste man jede alte Anwendung für neue CPUs komplett neu kompilieren, wenn jede Möglichkeit der Befehle ausschließlich der Compiler übernimmt (kann es in der Theorie auch), aber auch Betriebsysteme übernehmen diese Arbeit. Immerhin sind sie für die Kommunikation zwischen CPU und Anwendung verantwortlich. Jedes Betriebssystem hat CPU-spezifische Treiber, die je nach CPU verwendet werden.

Betriebssysteme übernehmen diese Arbeit nicht. Diese Arbeit übernahmen Intel und AMD als sie sich auf eine gemeinsame ISA geeinigt haben. Deshalb musst du X64 Code von 2005 nicht neu kompilieren, dieser Befehlssatz wird immer noch von aktuellen AMD oder Intel CPUs unterstützt. Wenn du natürlich die neuesten SSE-Erweiterungen für maximale Performance auf einer älteren CPU ausführst, wirst du einfach einen Absturz erhalten, da patcht das OS nicht deinen Code. War glaub ich zB bei Apex Legends so.

Eingebette Systeme haben hier natürlich einen Sonderfall, da sie meistens nicht "General Purpose" sind. Die Hardware ist ja schon bekannt - der Entwickler kann stets auf diese Hardware trimmen. Das ist bei einem Windows-PC nicht der Fall, die unterschiedlichen Feinheiten (Befehle) muss das Betriebssystem kennen. Das ist ein Overhead, der nicht unbedingt bei eingebetteten Systemen notwendig ist, aber auf Windows-Rechnern eben schon.

Was hat das mit dem Thema zu tun? x64 ISA ist x64 ISA.

 

[Konsolenbaby]

@Ark
Ich glaube du hast hier ein Denkfehler, was das Einschreiten des OS angeht.

Also noch einmal kurz ausführlich

Das OS läuft als oberster Task.
Jetzt haben wir Beispielsweise zwei weitere Programme, die auf dem System laufen.

Das OS übergibt nun dem ersten Programm die Kontrolle für eine gewisse Zeit.
Per Hardwareinterrupt erhält es wieder die Kontrolle zurück
Dabei werden z.B. die CPU Register, die Programm A genutzt hat, auf dem Stack gesichert.

Dann übergibt das OS Programm B die Kontrolle und es läuft so ab wie bei Programm A.

Wenn dann wieder Programm A ausgeführt wird, werden die vorher gesicherten Registerinhalte für Programm A in die CPU Register geschrieben.

Die Programme können natürlich auf OS Funktioen zugreifen. Das hat aber alles nichts mit unterschiedlichen Befehlssätzen oder Unterschieden in der Befehlsstruktur zu tun.

Der Compiler ist dafür zuständig, dass eben X86 oder PowerPC oder Atmel Code Maschinencode erzeugt wird.
Und er kann die von mir schon mehrfach angesprochenen Unterschiede bei Befehserweiterungen zwischen z.B. Intel und AMD CPUs berücksichtigen
Es wird nur einmal für X86 kompiliert und die Berücksichtigung der unterschiedlichen Befehlserweiterungen unternimmt nicht das OS sondern der Programmierer.
Im Programmcode stecken dann z.B. zwei unterschiedliche Routinen für die unterschiedlichen Befehlserweiterungen, die aber beide gleichzeitig compiliert werden.

Vielleicht verwechselst du das auch mit Just-in-Time Compilern, die erst einen Zwischencode generieren und erst bei Ausführung des Programms den eigentlichen Maschinencode. Hier wird ein einheitlicher Zwischencode beim Compilieren generiert, der unabhängig von der Hardware ist.
Auf der Hardware selber läuft dann ein weiterer Compiler, der aus diesem einheitlichen Zwischencode einen für die speziele Hardware generiert.
Java funktioniert z.B. so.


PS: Das OS ist im Übrigen auch nur ein Programm, was natürlich wie jedes andere Programm auch in Maschinensprache vorliegt.
Nach deiner Logik würde das OS auf einem System mit neuer CPU auch nicht ohne Anpassung laufen.
Das wäre allerdings ziemlich doof
Oder soll es sich selber ändern?

 

[TheProphet]

die Tasten wie bei Sonys letzten Handheld. Zumindest scheint man sich daran orientiert zu haben. Das kann ich nur begrüßen

Find ich auch begrüßenswert, scheint ein gutes Omen für Sony zu sein

 

[Ark]

Nochmal: Hier sollten klassische eingebette Systeme nicht mit einem Windows-Rechner verglichen werden. IDEs für eingebettete Systeme haben zig Header für die unterschiedlichsten Arten von Hardware, um mit der Hardware zu kommunizieren. Der Preprozessor definiert hier schon sehr viel. Falscher Header zur falschen Hardware funktioniert nicht - die Software kann schlichtweg nicht mit der Hardware kommunizieren. Deswegen läuft Nullpointers toller C-Code nicht einfach von System zu System. Das hat aber mit einem Windows-PC nichts zu tun.

Windows muss mit den unterschiedlichen CPUs klarkommen.

 

[Nullpointer]

Das OS der Xbox ändert genausoviel am kompilierten x64-Code wie das meines Windows - gar nix.

 

[MrBlonde]

Ich kann euch zwar nicht dieselben Gagen wie Dana White und die UFC bieten, aber wie wäre es, wenn wir nach all den ereignislosen Wochen den Wettkampfsport reaktivieren und Bumfights wieder ins Leben rufen?

Ich biete 12 Flaschen Perlenbacher und 2 Packungen TAWA Drehtabak, die Pfandflaschen bleiben allerdings beim Veranstalter, es sei denn einer der Kontrahenten ergattert den "Fight of the Night" Bonus!

 

[needcoffee]

Ich kann euch zwar nicht dieselben Gagen wie Dana White und die UFC bieten, aber wie wäre es, wenn wir nach all den ereignislosen Wochen den Wettkampfsport reaktivieren und Bumfights wieder ins Leben rufen?

Ich biete 12 Flaschen Perlenbacher und 2 Packungen TAWA Drehtabak, die Pfandflaschen bleiben allerdings beim Veranstalter, es sei denn einer der Kontrahenten ergattert den "Fight of the Night" Bonus!

Dein Beitrag gehört glaube ich hier hin ....

 

[MrBlonde]

Dein Beitrag gehört glaube ich hier hin ....

Du meintest wohl eher www.sherdog.com, aber hey...die Grenzen verschwimmen immer mehr.
Wer hätte vor Wochen gedacht, dass innerhalb weniger Sekunden die LIDL Abteilung für Dosengemüse zu einem Octagon zweckentfremdet wird?

HA!