SWITCH - Hardware-Diskussionsthread

[yopparai]

Ja, kommt hin. Nicht weltbewegend aber ok. Bin immer locker damit ausgekommen. Da man die auch per USB-Kabel an PowerBanks laden kann reicht das auch für sehr lange Zugfahrten.

[yopparai]

Ich habe nachgedacht. Über das Bandbreitenproblem.

Wir hatten hier neulich mal die Diskussion, ob die 25GB/s, die Nvidia für den Tegra X1 als Speicherbrandbeite (also die Geschwindigkeit, mit der GPU und CPU auf den Arbeitsspeicher zugreifen) angibt, nicht etwas sparsam sind, wenn Konsolen wie die PS4 irgendwo bei 176GB/s liegen. Also dem 7-fachen. Krulemuk war das glaub ich aufgefallen, wenn mich die Erinnerung nicht täuscht. Ich hatte damals angemerkt, dass Pascal eine eingebaute Farbkompression hat, die Bandbreite sparen hilft und etwas vage hinzugefügt, dass es generell eine deutlich modernere Architektur ist, aber Ruhe gelassen hat mir das Thema nicht. Denn keine Kompression könnte einen solchen Rückstand aufholen. Und was genau ist an der Architektur moderner?

Jetzt hatten wir neulich im anderen Thread die Diskussion über die Größe des Arbeitsspeichers und ob 4GB wohl ausreichen. Dabei ist mir das Thema wieder in den Kopf geschossen. Beim Lesen diverser News und Threads aus NeoGAF ist mir dann in einem Nebensatz eines Posters eine Information untergekommen, die ich völlig übersehen hatte (und auf die ich eigentlich selbst hätte kommen müssen): Nvidia nutzt Tile Based Rendering.

Ich erklär gleich genauer, was das ist und warum es das Bandbreitenproblem wesentlich weniger kritisch erscheinen lässt. Für alle, die keinen Bock auf lange Abhandlungen haben hier die Kurzfassung mit der wichtigsten Info in einem Satz: TBR reduziert die Zugriffe auf das RAM, indem es den Screen in Kacheln rendert und nicht komplett auf einmal.

Für die technisch Interessierten jetzt die Langfassung. Ich muss dazu etwas weiter ausholen, damit das ganze Bild klar wird:

Spoiler

Show

Die Rendering Pipeline hat die Aufgabe, aus 3D-Objektkoordinaten, Geometrien und Texturen das fertige 2D-Bild zu berechnen. Diese Daten werden von der Spiellogik zur Verfügung gestellt (die theoretisch sogar auf einem Server im Netz berechnet werden kann, z.B. bei MMOs). Eine gute Engine übergibt der Rendering-Pipeline möglichst wenige Daten, hat also vorher bestimmt, welche Objekte überhaupt sichtbar sein können.
Die Geometrie besteht im wesentlichen aus zwei Tabellen je Objekt: Eine Tabelle enthält die X, Y und Z-Koordinaten der Eckpunkte („Vertices“), die andere die Verknüpfung dieser Punkte zu Dreiecken (z.B. heißt „4, 6, 3“ dass Vertex Nr. 4, 6 und 3 aus der Vertex-Tabelle ein Dreieck bilden, die Reihenfolge bestimmt gegen den Uhrzeigersinn die Außenseite des Dreiecks, die gezeichnet wird). Der erste Schritt auf dem Weg zum Bild ist die Berechnung der neuen Koordinaten im Bildschirmkoordinatensystem. Die Berechnung ist mathematisch tatsächlich einfacher als man so glaubt, und durchaus faszinierend, aber da dieser Post eh schon lang genug werden wird kürz ich das mal ab (wenn Interesse besteht kann ich das nochmal ausführen). Man stellt in dem Prozess sogenannte Transformationsmatrizen auf (Zahlenschemata mit in dem Fall 4 x 4 Zahlen) und berechnet mit deren Hilfe aus den Vertex-Tabellen die neuen Koordinaten. Das Bildschirmkoordinatensystem hängt natürlich von der Kamera ab und hat seine X- und Y-Achsen üblicherweise an den Bildschirmkanten orientiert, Z zeigt in die Tiefe. Gleichzeitig werden die Polygon-Normalen (Vektoren, die senkrecht auf den Dreiecken stehen und vom Objekt weg nach außen zeigen) bzw. Vertex-Normalen (werden aus den angrenzenden Polygon-Normalen gemittelt) per Kreuzprodukt berechnet. Mit Hilfe dieser Normalen wird der Winkel zur Lichtquelle bestimmt (Skalarprodukt von Lichtrichtung und Normalen) und jedem Vertex ein Helligkeitswert zugewiesen. All diese Daten sind bis jetzt noch reine Geometriedaten, keine Pixel.
Der nächste große Schritt ist die Rasterisierung. Dabei lässt man auf jeden Pixel des Bildschirms die zum jeweiligen darunter liegenden Dreieck gehörigen Shaderprogramme los. Die Shader erhalten dazu die Informationen über Lichter, Oberflächennormalen, Licht/Schattierungswerte der benachbarten Vertices und auch Texturen. Ein sehr einfacher Shader könnte jetzt einfach aus den Farbwerten der benachbarten Vertices einen Zwischenwert berechnen (Interpolation) und ausgeben. Wenn das auf jedem Pixel (nach OpenGL genauer: Fragment) gemacht wird, dann sieht das ungefähr so aus wie Marios Nase in Mario 64. Er könnte auch eine sog. Normal Map erhalten, das ist eine Textur aus Richtungsinformationen, mit der jedem Pixel eine Schattierung zugeordnet werden kann, abhängig von der Richtung des einfallenden Lichtes. Das Ergebnis sähe dann aus wie die meisten Viecher in Doom 3: Die Polygone bekommen plötzlich Struktur und die Texturen reagieren auf Lichteinfall. Oder um ein weiteres Beispiel zu nennen, man könnte das Ergebnis in grobe Klassen einteilen und statt einem fließenden Farbwert über das Polygon nur grobe Approximationen liefern: Das Ergebnis wäre die Grundlage eines einfachen Cell-Shaders.

Wichtig hierbei für unser Grundproblem ist, dass jeder Shader-Durchgang einerseits auf Daten zugreift (Texturen) und andererseits Daten in’s RAM schreibt (Pixel/Fragment-Werte). All das geht über den Bus und wird in die 25GB/s eingerechnet. Praktisch stehen da noch ein paar Cache-Speicher dazwischen, die oft benutzte Daten näher am Prozessor halten und damit schon Zugriffe verhindern helfen. Aber die berechneten Ergebnisse landen üblicherweise direkt im RAM.

Ohne Tile Based Rendering erfolgt dieses Schreiben für den kompletten Frame. Wenn ein Shader über das Bild muss, der für jeden Pixel Normalen berechnet, dann schreibt der also einmal eine komplette Map für z.B. 1080p ins Ram. Wenn danach einer Texturen lädt, wiederholt sich das. Wenn jetzt noch einer Schattenwerte berechnet ebenfalls, usw. All das erzeugt Daten auf dem Bus.

Mit Tile Based Rendering passiert im Prinzip das gleiche, aber immer nur für kleine Kacheln des Screens (z.B. 32x32 Pixel). Dadurch sind die Datenmengen sehr klein und können lokal im Cache der GPU gehalten werden, ohne direkt über den Bus geschickt werden zu müssen. Das werden sie jeweils erst am Ende, wenn das Bild innerhalb einer Kachel fertig ist. Die wiederholten Zugriffe also werden so verhindert und effektiv viel Bandbreite gespart. Und das ist der Grund, warum man hier mit so wenig Bandbreite davon kommt.

Ich möchte trotztdem nochmal betonen, dass das Switch jetzt auch nicht zum Bandbreitenwunder macht. Das ist schon immer noch nicht sehr viel, es ist nur nicht unbedingt der furchtbar enge Flaschenhals, nachdem es aussieht. Die Technik ist auch nicht besonders neu, die PS Vita und praktisch alle Mobilgeräte arbeiten auch so.

Edit: Ist mir übrigens klar, dass die Darstellung oben ein paar Dinge unter den Tisch fallen lässt. Geht nur ums Prinzip.

[JesusOfCool]

schlaue idee, die die da hatten.
wirkt sich das nicht auch positiv auf die leistung aus? immerhin fällt da ein gewisser overhead weg. oder geht das sonst alles so oder so im takt mit?

[yopparai]

Gute Frage. Ich könnte mir auch vorstellen, dass TBR in einem anderen Punkt eher Leistung frisst, denn wenn du den Screenspace in Kacheln teilst, teilst du auch Polygone, die mehrere Kacheln überspannen. Das heißt, du musst ein und dasselbe Polygon und seine Shader womöglich mehrfach laden. Auf der anderen Seite ergibt sich durch die Kachelbearbeitung nochmal etwas Freiraum bei der Parallelisierung, denn die sind ja alle unabhängig voneinander. Ich nehme an, dass sich das insgesamt am Ende ausgleicht. Es dürfte auch Engineabhängig sein. Wenn ich durch viele kleine Shader häufige RAM-Zugriffe provoziere, dann profitiere ich von dem Verfahren mehr. Ich könnte mir vorstellen, dass das Deferred Lighting Engines zugute kommt, aber das muss ich erst noch mal in Ruhe gegenchecken.

[Grauer_Prophet]

Wii U Pro Controller werden nicht Supportet oder doch?

[Chibiterasu]

weiß man noch nicht - aber ich hoffe doch.
Wüsste nicht was dagegen sprechen sollte.

[E-G]

man könnte theoretisch argumentieren, dass man nen klaren Bruch zu allem alten machen will und nun erstmal gar nix altes mehr supporten wird... hat sich inzwischen ja ne menge altlast angesammelt.
Könnte auch sein, dassn anderer wireless standard genutzt wird...
oder das man mehr zubehör verkaufen will

[johndoe527990]

Ich wüsste nicht, wo aus Kundensicht das Problem wär, den Pro Controller als das Ding der Dinge zu positionieren (und somit eine Weiternutzung zu garantieren).

Naja, ich sag mal, zuletzt hat ja auch kein Mensch mehr gerafft mit welchem Controller man jetzt welches Spiel zocken kann. Das war schon ziemlicher Terror aus Kundensicht, bzw aus der Sicht eines eher unbedarften Kunden.

Das ist ein Kommunikations- und/oder Entwicklerproblem. Aber keins, was den Controller selber betrifft.

[Chibiterasu]

Naja, aber wenn die Switch auch Motion Gaming bieten soll (per Joycons), siehe auch Just Dance, dann will ich auch dass meine Wiimotes noch funktionieren (speziell im Multiplayer).
Ich bin arg gegen diese Anhäufung von Plastikteilen, die alle den selben Zweck erfüllen würden.

Ja, das mit der Message ist blöd.
Würde das evtl. auf den Packungen gar nicht mehr thematisieren sondern eine offizielle Liste zum Nachschauen online stellen. Die Interessierten informieren sich dort, der Rest kauft den Schrott halt nochmal...arme Umwelt... :-/

[yopparai]

So ich hatte es schon angedroht, hier jetzt meine Ergebnisse zur CPU der Switch im Vergleich zu den AMD-Kernen in XBone und PS4. Vorsicht, Technik:

Ich hatte ja immer mal wieder angedeutet, dass ich glaube, dass Switch eine vergleichsweise starke CPU haben wird, die sich vor den PS4-/Xbone-CPUs nicht verstecken braucht. Das Problem war dabei immer, dass ich dafür nie konkrete Zahlen anführen konnte, die in irgendeiner Weise darauf hindeuten. Es war ein allenfalls ein Bauchgefühl, genährt durch Post von NeoGAF-Usern, denen ich in technischer Hinsicht vertraue (Thraktor, Durante z.B.) und auch Posts in Homebrew-Foren, deren Mitglieder sich mit der Hardware schon aus praktischen Gründen sehr detailliert auseinandersetzen müssen. Dazu kamen dann eigene Experimente auf x86/AMD und ARM-Mobilhardware, die deutlich darauf hinwiesen, dass da nicht mehr Faktor 10 dazwischen liegen kann wie früher.

Warum ist das überhaupt wichtig?
Wenn die GPU der ist, der ein Bild malt, ist die CPU derjenige, der zunächst die später gemalte Landschaftskulisse aufbaut und gestaltet. Das heisst, die CPU bestimmt in erster Linie, was in der Spielwelt möglich ist. Ob Objekte aufeinander reagieren, wieviele Objekte überhaupt verwaltet werden, ob die intelligent sind, wieviel Kommunikation über's Internet bei Online-Spielen nebenher verarbeitet werden kann (Anzahl Mitspieler). Das alles sind Dinge, die darüber entscheiden, ob ein Spiel umsetzbar ist auf der Plattform oder eben nicht. Ist die GPU zu schwach fahre ich die Auflösung runter. Eine zu schwache CPU kann ich nur mit Tricks kompensieren, z.B. indem ich Rendering und Game-Loop voneinander trenne (und so z.B. im Schnitt nur noch jedes dritte Bild die KI neu berechne). Kurz: Eine CPU in der gleichen Leistungsklasse erleichtert Ports extrem.

Grundlage des Vergleichs
Problematisch bei solchen Vergleichen ist immer, dass man von beiden Plattformen Benchmarkergebnisse braucht, und bei Architekturen, die in so unterschiedlichen Welten unterwegs sind wie x86 und ARM historisch gesehen, ist das schwierig. Denn kaum jemand auf irgendwelchen PC-Seiten interessiert sich für die Leistung von ARM, und genausowenig interessiert sich jemand auf Handy-/Tablet-Portalen für x86.

Jetzt habe ich nach langem Suchen erstmals Benchmark-Werte für AMD-Mobilhardware und ARM-Prozessoren ausgraben können, und zwar zum guten alten Dhrystone-Benchmark aus den 80ern, der heute immer noch gern mal verwendet wird, Prozessorleistungen grob einordnen zu können. Nicht perfekt, aber besser als nix. Dhrystone ist ein reiner Integer-Benchmark, das heißt, er berücksichtigt nicht die Berechnung von Fließkommazahlen. Früher hätte ich hier schon abgebrochen, da Geometrie in Spielen nunmal aus Fließkommazahlen besteht, aber heute ist das nicht mehr so relevant wie in den 90ern, denn inzwischen werden die meisten dieser Berechnungen (Koordinatentransformationen, etc.) von der GPU übernommen. Außerdem handelt es sich bei x86 und ARM nicht um Spezialprozessoren, sondern um ziemliche Allrounder, die so ausgelegt sind, dass sie jedes Einsatzszenario überstehen können. Damit kann man in erster Näherung davon ausgehen, dass ein schneller Integer-Rechner auch recht gut mit Kommas klarkommt.

Dhrystone besteht aus einer bekannten zählbaren Menge an Operationen mit z.B. Strings (Zeichenketten, für den Rechner nichts anderes als Ganzzahlen) und Pointern (Speicheradressen, ebenfalls Ganzzahlen). Das Ergebnis eines Dhrystone-Tests auf einer konkreten CPU wird in MIPS angegeben (nicht zu verwechseln mit der gleichen CPU-Architektur, heißt "million instructions per second"), bzw. DMIPS (D für Dhrystone). Will man dagegen Kerne gegeneinander vergleichen will man oft nicht, dass die Taktrate da mit rein spielt, da die in verschiedenen Geräten dann z.B. unterschiedlich ausfallen kann. In dem Fall gibt man das Ergebnis als DMIPS/Mhz an, also Instruktionen pro Sekunde und Taktrate. Damit hat man einen Wert, der einen konkreten Kern in seiner Leistung unabhängig von seinem Takt beschreibt. Wenn man diesen Wert wieder mit dem Takt und der Kernzahl multipliziert hat man einen Vergleichswert für den ganzen Prozessor (wobei man hier aufpassen muss, dass man nicht 2-Kerner mit einem 8-Kerner vergleicht, der 8-Kerner wird dann oft trotzdem langsamer sein, da der laufende Code evtl. gar nicht richtig parallelisierbar ist).

Solche Werte habe ich bei ARM für mehrere Kerne in der Wikipedia gefunden: https://en.m.wikipedia.org/wiki/List_of ... hitectures

Beim AMD Jaguar aus den beiden Konsolen liegt der Fall schon schwieriger. DMIPS/Mhz-Werte sind da direkt nicht verfügbar. Sie sind aber für den AMD E350 verfügbar, einen kleinen Prozessor für Mini-PCs (hab selbst so'n Ding), der auf dem Vorgänger von Jaguar, nämlich Bobcat basiert. Die Wikipedia hat in ihrem Artikel zu Instructions per Second eine riesige Tabelle mit Prozessoren und MIPS-Werten, unter anderem auch für den E350, dessen Wert von tomshardware.com zitiert wird. Zusammen mit der offiziellen Aussage von AMD, dass Jaguar 15% mehr Instruktionen pro Sekunde bringt als Bobcat (ein realistischer Wert für einen Nachfolger) wird ein Bild hieraus.

Der Vergleich
Hier zunächst mal die Werte für einen der AMD-Kerne:
E350: 10.000DMIPS für 2 Kerne bei 1,6GHz, d.h. 10.000DMIPS/1600Mhz/2 = 3,125 DMIPS pro Kern und MHz.
Jaguar: 3,125DMIPS/MHz * 1,15 = 3,594DMIPS/MHz

Bei den verschiedenen ARMs ist das einfacher, die sortiert auch wieder die Wikipedia direkt:
Cortex-A53: 2.3 DMIPS/MHz
Cortex-A57: 4.6 DMIPS/MHz
Cortex-A72: 4.8 DMIPS/MHz

Konkret verbaut ist in der PS4 der Jaguar als 8-Kerner mit 1,6Ghz. Davon arbeitet einer für das OS und die Share-Funktion. Nehmen wir mal an, die restlichen 7 Kerne könnten komplett unabhängig voneinander arbeiten (was den Prozessor mit mehr Kernen etwas bevorteilt), dann erhalten wir einen Vergleichswert von 3,594DMIPS/Mhz * 7Kerne *1600Mhz = 40250DMIPS für den ganzen Prozessor (das N64 hatte etwa 100, die WiiU liegt irgendwo bei 8600, was die Probleme mit Ports erklärt). Gegen diesen Wert können wir jetzt verschiedene Szenarien für den Switch-Prozessor stellen, den wir ja noch nicht im Detail kennen. Fangen wir an mit dem Tegra X1 bei 1800Mhz. Was konservativ ist, denn im Google Pixel C läuft der mit etwa 1900Mhz, und das ist bekanntlich passiv gekühlt. Der Tegra X1 besteht aus 4x A57 und 4x A53, die A53er sind aber nicht einzurechnen, denn Nvidia erlaubt im Unterschied zu Qualcomm und Konsorten keinen gleichzeitigen Betrieb, sondern schaltet den kompletten Satz an Threads komplett auf die 4 kleineren, wenn die Auslastung niedrig ist (Cluster Migration). Deshalb rechnen wir hier erstmal nur mit 4 Kernen:

4.6DMIPS/Mhz * 4Kerne * 1800Mhz = 33120DMIPS

Das sind schon mal 82% der PS4-CPU-Leistung für einen konservativ geschätzten Mobilprozessor. Doch es kommt noch besser: Nicht jedes Spiel nutzt wirklich alle 7 Kerne aus. Schon allein deswegen nicht, weil die meisten PCs eher so 4 haben. Und genau deswegen macht es Sinn sich anzuschauen, wie groß eigentlich die Performance eines einzelnen Kerns ist, denn der langsamste Thread hält das ganze Programm auf:

PS4-Jaguar: 3,594DMIPS/Mhz * 1Kern * 1600Mhz = 5750,4
Cortex-A57: 4.6DMIPS/Mhz * 1Kern * 1800Mhz = 8280

Hier wäre Switch selbst in diesem konservativen Szenario plötzlich 30% schneller. D.h. übersetzt: Schlecht parallelisierter Code wird auf Switch tendenziell Vorteile haben.

Jetzt reden wir hier aber bei Switch die ganze Zeit von einem halben Prozessor und zwar bei einer relativ niedrigen Taktrate. Der Fairness halber rechnen wir noch ein mittleres und ein optimistisches Szenario durch:

Mittel: 6x Cortex A57 bei 1900MHz
Single: 4.6DMIPS/Mhz * 1Kern * 1900Mhz = 8740DMIPS (+34% ggü. PS4)
Multi: 4.6DMIPS/Mhz * 4Kerne * 1900Mhz = 52440DMIPS (+23% ggü. PS4)

Optimistisch: 4x Cortex A57 + 2x Cortex A72 ohne Cluster Migration bei 2000MHz
Single A57: 4.6DMIPS/Mhz * 1Kern * 2000Mhz = 9200DMIPS (+37% ggü. PS4)
Single A72: 4.8DMIPS/Mhz * 1Kern * 2000Mhz = 9600DMIPS (+40% ggü. PS4)
Multi: (4.8DMIPS/Mhz * 2Kerne + 4.6DMIPS/Mhz * 4Kerne) * 2000Mhz = 56000DMIPS (+28% ggü. PS4)

Wie man es also auch dreht und wendet, mit der richtigen Konfiguration läuft ARM was DMIPS betrifft Kreise um den alten PS4-Jaguar. Selbst die Pro wäre nicht ausser Reichweite. Die obigen Rechnungen berücksichtigen dabei noch nicht, dass Nintendo wahrscheinlich auch einen Kern für Hintergrundaufgaben reservieren wird. Realistisch rechne ich da mit 4x A57 oder A72 und 2 oder 4x A53 für's OS, wobei die Cluster Migration dafür rausfallen müsste, aber wir haben hier ja einen Custom-Chip und für Handheld-Gaming macht das keinen Sinn, daher ist das durchaus möglich.

Das Ganze soll als eine Einschätzung dienen. Auch, wenn ich da oben teilweise Kommazahlen verwende heißt das nicht, dass diese Zahlen in Stein gemeißelt und die einzig relevanten für den Anwendungsfall sind. Auch werden hier keine Speicher und ähnliches berücksichtigt. Es geht mir nur um Eines: Ein Jaguar ist nicht automatisch unschlagbar, weil er ein x86-Kern ist. ARM hat in den letzten 10 Jahren extreme Fortschritte gemacht. Mir geht es nur darum zu unterstreichen, dass Switch keinesfalls "underpowered" sein muss, jedenfalls nicht in der CPU-Abteilung. Die Architekturen sind mindestens auf Augenhöhe und Nintendo muss sich schon anstrengen, mit der Grundlage etwas langsameres als eine PS4-CPU auf die Beine zu stellen.

[Kensuke Tanabe]

Also die Nitch wird günstig sein, mobil und fast so Leistungsstark wie die PS4Pro. Hört sich doch alles sehr gut an.

[yopparai]

Lies doch erstmal, da wirst du feststellen, dass explizit nur von der CPU die Rede ist (und ob Ports von aktuellen Titeln technisch möglich sein werden, was sie auf der U ja oft nicht waren). Die ist bei Sony halt lahm. Das wussten wir alle vorher. Die GPU ist eine ganz andere Baustelle.

[Levi]

Tolle Aufschlüsselung. Und irgendwie hatte ich bei deiner Einleitung geahnt, dass du auf mips aus bist.
Man sollte aber trotzdem nochmal dick betonen, das mips so ziemlich die synthetischsten Benchmark-werte sind, die man sich vorstellen kann.
(Reihen sie sich quasi neben den Flops ein.)

[yopparai]

Ist halt der einzige Wert, den es praktisch von jedem Prozessor irgendwo gibt. Und für eine erste Einschätzung der Größenordnung ist das gerade so zulässig. Zumindest kann man daraus ableiten, dass Switch nicht nur eine WiiU in mobil wird, denn das war so eine Aussage, die man in vielen Forenposts hier und anderswo immer wieder mal durch kam. Wenn das rübergekommen ist, hab ich damit alles erreicht was ich wollte.

[Levi]

Schade ist einfach, dass das bei den üblichen Verdächtigen einfach nie ankommen wird