PS5 Specials XBX

„TeraFLOPS“ – Was sich dahinter verbirgt und weshalb wir den Blödsinn ignorieren sollten

Spätestens mit dem Durchsickern des ersten PS5-Devkits starteten Hardware-Spekulanten ihre alltäglichen Gerüchtebombardements mit neuen Vermutungen zur Technik der Next-Gen-Konsolen. Das freut zudem die News-Redaktionen der aktivsten Videospiel-Portale im Netz. „Ein Insider hat verraten, dass die PS5 und der Xbox-One-Nachfolger Ray-Tracing beherrschen!“, „Können PS5 und die neue Xbox wirklich Ray-Tracing?“, „AMD bestätigt Ray-Tracing für die nächste Konsolengeneration.“, „Was könnt ihr von Ray-Tracing auf der PS5 erwarten?“. Ein Buzzword reicht, um es in gefühlt zwanzig Artikeln mit mehr oder weniger demselben Inhalt zu verwursten. Logisch, es handelt sich ja auch nur um Schätzungen, da sind der Fantasie keinerlei Grenzen gesetzt.

Neben der extrem präzisen Darstellungsmethode für Schatten, Spiegelungen und Beleuchtung sowie der modernsten Festplattentechnik, springt dem aufmerksamen Leser eine kryptische Angabe immer wieder ins Auge. „TeraFLOPS“ sind seit PS4 Pro und Xbox One X in aller Munde. Während das Standardmodell der vierten PlayStation-Generation auf verschwindend geringe 1,84 TeraFLOPS beziffert wird, schafft es die aktuellste Xbox-Revision auf ganze 6. Heftig, oder? Schließen wir wirklich daraus, dass eine Xbox One X dreimal so schnell ist wie die Sony-Konkurrenz? Wie skaliert das überhaupt? Äußert sich das in der Framerate oder sind Spiele jetzt dreimal so hübsch? Kann man Schönheit denn überhaupt messen? Wir stoßen unweigerlich an unsere Grenzen, logische Anwendungsszenarien zu entwerfen.

Aber es klingt erstmal nach etwas Technischem und vor allem nach verdammt viel. Man kann sich die Marketing-Meetings bei Agenturen blumig ausmalen: „Leute, hier sind die Datenblätter zu der Konsole, irgendwas müssen wir doch in der Kampagne nutzen können.“ – „Chef, Chef, Chef, hier, ich habe es gefunden! TeraFLOPS, das klingt nach nerdiger Zukunftstechnik und ist noch nicht so durchgenudelt. Hat auch einen schönen Klang. Tera. Fast so wie das lateinische Wort für Erde. Viel schwungvoller als Megahertz, frischer als Gigabyte und zart wie Bockwürste. Oh, woopsie, das ist für die Würstchenwerbung, die wir morgen besprechen.“

Performance-Marketing mal anders

Und so hat die Tech-Industrie ein neues Marketing-Gimmick entworfen, das auch sogleich Anklang fand. TeraFLOPS hier, TeraFLOPS da. Passt perfekt in eine News-Headline und der Otto-Normal-User muss sich nicht einmal durch den Artikel klicken, er zieht sich einfach die Daten aus der Überschrift und speichert sie als gültigen Leistungsvergleich ab.

Unabhängige Tests demonstrieren ein klares Leistungsbild für PC-Hardware | Quelle: GamersNexus

Die Konsolenhersteller haben damit endlich den heiligen Gral gefunden, nach dem sie seit gut dreißig Jahren angestrengt suchten. Es war stets unmöglich der Zielgruppe einen quantifizierbaren Performance-Zuwachs verständlich zu vermitteln. PC-Bastler wurden dahingehend jahrzehntelang verwöhnt: Benchmarks in verschiedenen Applikationen zeichneten ein genaues Bild, was von einem neuen Bauteil erwartet werden konnte.

Hardware-Lieferanten waren kontinuierlich bemüht, die Presse mit Testmustern auszustatten, denn nichts erschütterte den Wettbewerb so sehr wie ein zehnprozentiger Vorsprung in Framerate-Analysen von Crysis. Wenn der Preis dann auch noch stimmte – sicherer Kauf. Bei den kleinen Videospielkisten hingegen? Naja, da musste man sich eben auf Demos und Trailer, die weitgehend auf Prototypen basierten, stützen, damit der potenzielle Käufer sieht, wie gut das Gerät performt. Die Spitze des Eisbergs? Das legendäre Debakel, das sich Sony eingeheimst hat, als man versuchte, CGI-Trailer als Echtzeitmaterial zu verkaufen, nur um UNBEDINGT besser dazustehen als Microsoft mit seiner (zu diesem Zeitpunkt) früher erscheinenden, günstigeren und weitaus komfortabler programmierbaren Xbox 360.

2005 glaubten wir Sony tatsächlich, dass es sich um Echtzeitgrafik von PS3 handelte:

Vom Verkaufsflop zum TeraFLOP – der steinige Weg von Xbox One

Nun reicht eine Angabe in einem PR-Tweet, um hunderttausende Interactions zu triggern und für jede Menge Gesprächsstoff im Internet zu sorgen:

Xbox Series X
– 12 TeraFLOPS

And BOOOOOOOOOOOOOOOOOOOOOM goes the dynamite! Keine teuren Tech-Demos, man muss sich nicht um realistische Performance-Messungen scheren und die Zahl ist im Vergleich zur Xbox One X doppelt so hoch. Versteht jeder und passt zum Zeitgeist. Wir brechen munter jeden Bereich unseres alltäglichen Entertainments zur besseren Einordnung auf Zahlen runter, wieso dann nicht auch Videospielkonsolen? „Hey, wie findest du Sekiro?“ – „Puh, 8/10.“. „Was für einen Fernseher willst du dir holen?“ – „Auf jeden Fall 4K.“ Einordnen ist simpel, um Details schert sich kaum jemand und man investiert seine immens wichtige Lebenszeit ausschließlich in das Beste. Wie jeder weiß, ist eine 7,5/10 schon der größte Schrott. Genau deshalb funktionieren weiterhin Top-Listen so gut.

Das mache ich mir an dieser Stelle einfach mal zunutze, um euch gedanklich auf technischen Firlefanz vorzubereiten. Hier also meine Top-3-Liste mit Gründen, weshalb ihr TeraFLOPS als Werkzeug, das euch Konsolen schmackhaft machen soll, ignorieren solltet.

Auf Platz 3 – Die mangelhafte Abbildung technischer Faktoren, die sich wirklich auf die Leistung auswirken

AMD-Chips auf einem Silizium-Wafer – Jeder davon einzigartig in seiner Beschaffenheit | Quelle: AMD

Habt ihr euch einmal gefragt, wie TeraFLOPS eigentlich gemessen werden? Sollte man definitiv tun, wenn Leistungsfähigkeit auf dem Prüfstand steht, zumal die Antwort so simpel wie unerwartet ist: Gar nicht! Grundsätzlich soll die Angabe der Menge an Gleitkommaberechnungen, die ein Chip imstande ist durchzuführen, pro Sekunde entsprechen. Das hätte euch auch Google Translate verraten können, wenn ihr Floating Point Operations Per Second (FLOPS) eingegeben hättet. Damit habe ich dann auch schon mit der „Recherchearbeit“ der meisten Online-Publikationen zu dem Thema gleichgezogen. Kommen wir lieber zu interessanteren Fakten. Es handelt sich um eine rein synthetische Größe, um die Leistung eines Prozessors abzubilden, schließlich sind Gleitkommaberechnungen so nah am Metall wie beispielsweise Binärcode.

Auffällig ist ja schon, dass die TFLOPS-Angabe keine fluktuierende Größe ist, was bei tech-affinen PC-Bauern bereits im Ansatz für Stirnrunzeln sorgen dürfte, denn die Erfahrung weist eigentlich darauf hin, dass jeder individuelle Chip, sogar in derselben Produktreihe, qualitativ komplett einzigartig ist. Vor allem für Übertakter sind diese Fertigungsunterschiede interessant, da man „besser gelungene“ Prozessoren deutlich unproblematischer über der Herstellerspezifikation betreiben kann. Die Menge an maximal möglichen Gleitkommaoperationen pro Sekunde ist hingegen immer starr angegeben, was daran liegt, dass sie nicht gemessen, sondern berechnet wird. Das geschieht nach der Formel „SHADER UNITS x BASISTAKT x 2 INSTRUKTIONEN PRO TAKT“, die auch perfekt aufschlüsselt, welche Hardware-Daten überhaupt abgeleitet werden können.

Nehmen wir als Grundlage die 12 TeraFLOPS von Xbox Series X. Ein einfaches Rechenbeispiel wären 3000 Shader Units und 2000 MHz Basis-Takt der GPU und wir erhalten die von AMD angegebene Anzahl an Gleitkommaberechnungen. In der Praxis wäre ein so hoch getakteter Grafikprozessor völliger Blödsinn, selbst der TU106-Chip einer Nvidia RTX 2070 wird mit „nur“ 1400 MHz Basistakt betrieben. Wir bewegen uns hier in der 500€-Preisklasse von PC-Grafikkarten, die gemeinhin höher als eine APU in einer Konsole takten. Nehmen wir doch an, dass dieser Basistakt für eine Konsole erreichbar ist, was zudem realistisch wäre, da die Grafikeinheit von Xbox One X mit immerhin 1170 MHz angetreten ist. Als Ergebnis können wir eine Shader-Anzahl von circa 4280 ableiten, denn:

4286 Shader Units x 1400 MHz Basistakt x 2 Instruktionen pro Takt = 12.000.800 FLOPS oder auch 12 TeraFLOPS

Tatsächlich kann man daraus auf ein potenzielles Leistungsbild schließen, denn der Renderablauf moderner Computergrafik basiert zu Großteilen auf Shading, was mittlerweile vielerlei Funktionen zur Manipulation polygonbasierter Objekte und Texturen beinhaltet. Wie viele dieser Shading-Operationen von der Grafikeinheit durchgeführt werden können, ist eng an die angegebenen Shader Units und den Basistakt geknüpft, weshalb sich eine Steigerung der Computing-Power positiv auf Spiele auswirkt.

Auch sind meine vermuteten Zahlen nicht aus der Luft gegriffen, sondern wurden in einem vergleichbaren Maß schon bei PC-Hardware eingesetzt. In der Formel fehlen allerdings bedeutsame Variablen, die letztendlich bestimmen, wie viele Bilder die GPU bei einem gegebenen Workload berechnen kann. Zu nennen wären da etwa Texture Mapping Units (TMUs), die Texturen anpassen und über ihre 3D-Modelle legen, Render Output Units (ROPs), die final den entstandenen Frame zusammensetzen und in den Buffer schreiben sowie Anti-Aliasing hardwareseitig steuern, oder auch die sehr entscheidende Speicherbandbreite, die Auskunft über den Datendurchsatz gibt. All diese Komponenten sind Indikatoren für die theoretische Leistungsfähigkeit des Grafikprozessors, in der Formel zur Ermittlung der möglichen Gleitkommaberechnungen spielen sie dagegen keine Rolle.

Auf Platz 2 – Die Gesamtarchitektur diktiert die Performance, nicht die einzelnen Komponenten

Für diese Annahme kann ich ein praxisnahes Beispiel angeben, das deutlich zur Schau stellt, dass eine GPU nicht zwangsläufig viele Bilder pro Sekunde herauspumpen kann, obwohl Shader Units und FLOPS in immens hohen Mengen vorrätig sind. Bereits vor fast drei Jahren bot die AMD Radeon RX Vega 64 völlig irrsinnige 13,7 TeraFLOPS in seiner wassergekühlten Variante. Erreicht wurde das mit 1677 MHz im maximalen Boost sowie 4096 Shader Units. Für Crypto-Miner stellte sich die Karte als Segen heraus. Die hohe Computing-Leistung ermöglicht, dass pausenlos Gleitkommaberechnungen abgearbeitet werden können, der Workload bleibt dabei immer gleichförmig. Bei fast 500GB/s Speicherbandbreite konnte zudem gut nachgeschaufelt werden.

Schematischer Aufbau einer GPU mit RDNA-Architektur | Quelle: AMD

In Spielen setzte sich dieser Trend nicht fort. Eine herkömmliche Nvidia Geforce GTX 1080 war in nahezu allen getesteten Spielen unabhängig von der Auflösung performanter, obwohl ihr 1500 Shader Units fehlten, um gleichzuziehen, die Datentransferrate zum Speicher deutlich niedriger war und sie fast 50% weniger Verlustwärme produzierte. Die Ursache lässt sich bei der Konzeption beider Chips finden. Während AMDs Flaggschiff sehr ineffizient mit seinen massig zur Verfügung stehenden Ressourcen umging, hat die Nvidia-Konkurrenz mit ihrem GPU-Design ein perfektes Zusammenspiel aller Einzelkomponenten ermöglicht. Das fängt schon beim Aufbau der Computing Units (CUs) an. In diesen Einheiten werden eine Vielzahl von Hardware-Shadern zusammengefasst, ein Rechenwerk gibt dann die Instruktionen an die einzelnen Units weiter. Da Shader mittlerweile sehr vielfältig programmiert werden können, muss das Rechenwerk die Aufgaben sehr geschickt verteilen, um effizient zu arbeiten.

Man darf dahingehend nicht verschweigen, dass AMD in den letzten Jahren große Fortschritte erzielt hat. Mit der RDNA-Architektur hat man ein neues Konzept vorgestellt, das zur Konkurrenz aufschließen konnte, wenn auch mit kleinen Abstrichen. Zumindest sofern man hardwarebeschleunigtes Ray-Tracing außen vor lässt. Das soll dann mit RDNA2 verfügbar sein.

Es ist also davon auszugehen, dass Xbox Series X und PS5 das theoretische Leistungspotenzial der verbauten AMD-APU klar besser auf die Straße bekommen als es die Vega 64 mit völlig veralteter Graphics-Core-Next-Architektur vermochte. Ein Sprung um 100% wäre jedoch an den Haaren herbeigezogen, da neue Chip-Designs nie wirklich erprobt sind und der Umgang damit erst erlernt werden muss. Aufgrund dessen kann sich die resultierende Spieleleistung in beide Richtungen verändern. Zudem lässt die TFLOPS-Formel andere Komponenten, wie bereits erwähnt, außen vor – Wichtige Puzzleteile, deren Zusammenspiel von einer leistungsfähigen Chiparchitektur gewährleistet sein muss, werden nicht einbezogen.

Und ungeschlagen auf Platz 1 – Videospiele sind keine synthetischen Workloads, sondern verdammt willkürlich

Jeder Leser, der sich ein wenig mit IT auskennt, wird diesen Punkt schon vor etlichen Zeilen erkannt haben. „Der faselt die ganze Zeit von Shader Units und ganz viel Hardware! Die Studios hängen doch sowieso letzten Endes in spezialisierten Entwicklungsumgebungen rum und beschäftigen sich gar nicht en détail mit dem Gerät!“. Klebt euch ein Fleißbienchen ins Hausaufgabenheft, denn damit habt ihr absolut recht.

Die Kreation solcher Szenen verlangt nicht nur der Hardware, sondern auch den Entwicklern alles ab | Quelle: Control / 505 Games, Remedy Entertainment

Die Magie, die auf euren Bildschirmen entfacht wird, entsteht nahezu ausschließlich auf der Software-Ebene. Spiele-Engines gehen völlig unterschiedlich mit bestimmten Hardware-Ressourcen um und fundamentale Komponenten, wie die genutzte API und Treiber, können eine nicht zu verachtende Rolle spielen. Ganz einfach ausgedrückt: Es wäre für einen geübten Informatiker kein Problem, einen Grafikprozessor mit ein paar Code-Zeilen maximal auszulasten, der Workload ist schnell geschrieben und beinhaltet keinerlei Präzisierungen für einzelne Aufgaben. Videospiele versuchen das natürlich zu vermeiden, obwohl jeder einzelne Code-Baustein völlig unterschiedlicher Natur sein kann.

Damit hadern hochkomplexe Grafikfeuerwerke seit Jahren. Auf der einen Seite versuchen Engine-Entwickler einzelne Implementierungen zu simplifizieren, um den Programmieraufwand noch menschenmöglich zu halten, andererseits entstehen dadurch so viele Systeme, die ineinandergreifen müssen, dass ein einziger Fehler im Code ein ganzes Spiel lahmlegen kann. Allein der Medientypus „Videospiel“ bedingt diese Art der Konstruktion, da ein Animationssystem z. B. nicht von Kollisionsabfragen oder der Soundgenerierung abgekoppelt sein kann.

Es wird den Entwicklern schlecht optimierter Games ja gern mal Faulheit oder mangelndes Wissen vorgeworfen, das ist in der Praxis hingegen mitnichten der Fall. Diejenigen, die es in die Industrie und zu großen Studios geschafft haben, sind meist die Speerspitze in ihrem Fach. Und das nicht nur im Coding – Wenn es um Systeme für Lichtbrechungen, Physik, Reflexionen oder Verhalten von Materialien geht, sind Kenntnisse zu hochwissenschaftlichen Feldern wie Mathematik und eben Physik unabdinglich. Man muss ja nur einmal rüber zu Rennsimulationen schielen. Reibungswiderstände an den Reifen, G-Kräfte oder die Beschaffenheit von Untergründen sind physikalische Prinzipien, die ein Unbeleckter nicht einfach mal herleiten kann.

Mit DirectX 12 und Vulkan kamen dann noch APIs hinzu, die Low-Level-Zugriffe auf die Hardware ermöglichten und damit den Treiber, der Instruktionen der Software für die GPU verständlich kommuniziert, möglichst wenig beanspruchten. Das Resultat ist dann ja ein Performance-Gewinn, da Entwickler viel näher an der eigentlichen Hardware arbeiten können, nicht wahr? Jaaaaaaaaa, neeeeeee. Nicht ganz. Mit mehr Low-Level-Zugriff steigt die Komplexität der Programmierung erstmal sprunghaft an, obwohl man in der Theorie mehr Leistung herauskitzeln könnte. Das ist auch der Grund, weshalb die ersten DirectX-12-Versionen von PC-Spielen furchtbare Ergebnisse lieferten. Die Technik war neu und der Umgang damit nicht verbreitet, dementsprechend lief die gehabte DX11-Variante im Schnitt durchgängig performanter.

Im Blueprint-Editor der Unreal Engine 4 wird die Funktionsweise einer Deckenlampe manipuliert – eines der einfachsten Beispiele | Quelle: Epic Games

Die Unwägbarkeiten nehmen kein Ende

So viel zum technischen Unterbau. Was in den Engines und vielen weiteren Drittanbieter-Tools kreiert wird, ist dann noch einmal eine ganz andere Geschichte. Entwickler schreiben häufig die Software, auf der das Spiel basiert, in ganz grundsätzlichen Funktionen um, damit es bestens in ihren Workflow passt und man zielgerichtet die Ansprüche an das fertige Produkt erfüllen kann. Ihr merkt schon, Code über Code über Code, unzählige Potenziale zur Optimierung.

Mit solch einem Text kann ich nicht im Ansatz genug Respekt für das zuständige Leitpersonal zollen, das über all diese Bruchstücke die Übersicht bewahrt. Dabei helfen zwar mittlerweile sehr clevere Programme für die Aufzeichnung vorgenommener Änderungen, aber wie viel bei Software-Entwicklung unglücklich schiefgehen kann, tut sich einem meist erst auf, wenn man sich tiefgehend mit der Spieleentwicklung beschäftigt. Wusstet ihr, dass die CryEngine so wenig genutzt wird, weil Crytek sehr nachlässig mit der Dokumentation für Lizenzabnehmer ist? Ein an sich gutes Werkzeug, das Features reichhaltig bereitstellt und aufgrund einer Kommerzialisierungsabsicht entstanden ist, wird dadurch für etliche Teams nahezu unbrauchbar.

Entwickeln in der CRYENGINE, wenn der investierte Aufwand zu groß wird

Das ist ein modernes Beispiel, meine erste Begegnung mit der Tatsache, dass scheinbar kleinste Ungereimtheiten einen nicht zu verachtenden Einfluss im Entstehungsprozess nehmen können, war die Bonus-DVD meiner The Elder Scrolls IV: Oblivion Limited Edition. Da standen vier Entwickler gemeinsam vor einer Workstation, da sich bei der Implementierung eines neuen Animations-Features in das bestehende Physiksystem sämtliche Subroutinen zur Schattenberechnung in der Engine verabschiedeten. Die Lösung? „Erhöhe mal die Lumineszenz von Kerzenschein um 1.“ Und siehe da, alles lief wieder wie gehabt. Dafür funktionierte die KI von Assassinen nicht mehr und sobald es Nacht wurde, crashte das gesamte Spiel.

Wie das überhaupt alles zusammenhängen kann? Das dürft ihr mich nicht fragen. Tatsache ist, dass Programmierer sich vorrangig damit auseinandersetzen, wie die Konsolen auf ihren Code und die Kreationen innerhalb der Dev-Tools reagieren, nicht damit, was auf Hardware-Ebene exakt vor sich geht. Das ist ein völlig anderes, hochspezialisiertes Fach, das von den Studios gar nicht beackert werden kann, da entsprechendes Personal extrem rar gesät und kostspielig ist. Die Schlussfolgerung daraus? Euer auserkorener Titel und die Rohleistung der Konsolen befinden sich selten im Einklang, Echtweltszenarien und synthetische Leistungsträger divergieren in hohem Maße.

Natürlich schaffen es besonders talentierte, hocherfahrene und perfekt zusammengestellte Studios das kleine Quäntchen mehr Performance aus der Konsole zu kitzeln und für sich zu nutzen. Eine TeraFLOPS-Angabe kann dafür allerdings kein Indikator sein, denn die Variablen, die reell über euer Spielvergnügen entscheiden, sind so vielzählig wie dieser Artikel bereits lang, weswegen ich nun die Finger stillhalte und euch mal direkt frage: Würdet ihr gern über bestimmte Tech-Gebiete mehr erfahren? Seid ihr grundsätzlich gegenüber technischeren Aspekten von Videospielen offen? Verratet es uns doch im Forum.

Titelbild: Xbox Series X, Microsoft

19 Kommentare

  1. Natürlich wird vorrangig auf Software optimiert. Dennoch lässt sich schon sagen, dass du auf bestimmte Hardware hin optimieren kannst. Mit Low-Level-APIs wie DX12, Vulkan und Gnm kannst du bestimmte Operationen auf der Hardware steuern. Etwa Priorisierungsketten oder wie sich Anti-Aliasing verhalten soll. Natürlich macht das kein Mensch mehr im Assembly Code, bei der heutigen Komplexität von Spielen, würdest du wahrscheinlich jahrzehntelang an einem einzelnen Indie-Spiel sitzen.



    So zumindest heutzutage. Bei der Xbox 360 nutzten viele Entwickler auch den eRAM direkt neben dem Grafikchip ganz unterschiedlich. Wobei das auch weitestgehend über die Software gemacht wurde. Könnte man natürlich sagen, dass alles, was ich genannt habe, nur auf Software-Ebene stattfindet. Wie auch sonst? Am Metall kann man nichts ändern. Das Verhalten der Hardware auf die Software lässt sich aber schon analysieren und dann in dem Rahmen, der einem gegeben ist, optimieren. Ältere AMD-Hardware war z. B. in der Pixel-Shader-Berechnechnung immer etwas lahmarschig im Vergleich zur Konkurrenz. Dementsprechend kannst du schauen, wie du deine Pixel Shader möglichst schlank hältst, aber dann bei Fragment oder Tesselation mehr aufdrehen.

    Darauf will ich hinaus. Bei einem Treiber-Update hilft dir dann im Notfall sämtliche Optimierung nichts, weil plötzlich alles wieder anders ist. Man merkt es dann teils daran, dass ältere Spiele mit einmal schlechter laufen oder neuere Spiele einen kleinen Leistungszuwachs bekommen (oder auch mal andersrum), ohne dass da irgendwas am Spiel selbst geändert wurde.



    PS: FPS sind kein Leistungsindikator sondern einzig ein Vergleichswert. Deswegen gab es früher ja so Benchmarkprogramme, die dann aus verschiedenen festgelegten Demoszenen einen Wert berechneten, am populärsten war früher viele Jahre lang der 3DMark.
    Theoretisch könnten die Hersteller also so einen Benchmark im Stil von Cinebench und Co. als Standard festlegen und dann mit deren Werten werben bzw. sie auf die Packung drucken.

  2. Diese synthetischen Benchmarks wie 3DMark (oder heutzutage Futuremark, Superposition, Atomic Heart, usw.) und co. bringen dir nur nichts, weil es keine Echtweltszenarien abbildet, sondern eben dort auch synthetische Workloads sind. Dafür sind Spiele einfach zu willkürlich. Man merkt es ja teilweise schon daran, wie unpraktikabel manche Ingame-Benchmarks sind. Der Benchmark von Wolfenstein: Youngblood ist z. B. völlig unbrauchbar im Vergleich zum eigentlichen Spiel und gibt völlig unrealistische Werte aus, obwohl er In-Engine gerendert wird. Dasselbe bei Final Fantasy 15.


    Einige funktionieren hingegen recht gut, z. B. die von Gears of War 4 oder Rise of the Tomb Raider. Als einzig wahrer Leistungsindikator ist es natürlich Quatsch, ohne Kontext bringt es dir nichts, wenn du "Kann Gears 5 in 200fps darstellen!" auf die Packung druckst. Kann in anderen Spielen dann mehr oder weniger sein. Oder im selben Spiel bei unterschiedlichen Einstellungen/Settings. Es ist jedoch die ehrlichste Abbildungsmöglichkeit für den Zweck, für den du Leistung suchst, wenn der Messungskontext angegeben ist.


    Deswegen meinte ich ja, dass ich eigentlich für visuelle Überzeugungskraft am ehesten empfänglich bin, weswegen bei mir auch so eine Quake-2-Ray-Tracing-Veröffentlichung oder eine Demo von Control mehr reinknallt als eine "UNFASSBARE 12 TFLOPS!"-Meldung aus der Marketing-Abteilung. Wenn Microsoft mit einem lauffähigen Prototypen der genannten Applikationen mit hohen Framerates um die Ecke kommen würde, meine Fresse wäre ich beeindruckt. TFLOPS hingegen? Gähn.

  3. Diese synthetischen Benchmarks wie 3DMark (oder heutzutage Futuremark, Superposition, Atomic Heart, usw.) und co. bringen dir nur nichts, weil es keine Echtweltszenarien abbildet, sondern eben dort auch synthetische Workloads sind. Dafür sind Spiele einfach zu willkürlich. Man merkt es ja teilweise schon daran, wie unpraktikabel manche Ingame-Benchmarks sind. Der Benchmark von Wolfenstein: Youngblood ist z. B. völlig unbrauchbar im Vergleich zum eigentlichen Spiel und gibt völlig unrealistische Werte aus, obwohl er In-Engine gerendert wird. Dasselbe bei Final Fantasy 15.


    Einige funktionieren hingegen recht gut, z. B. die von Gears of War 4 oder Rise of the Tomb Raider. Als einzig wahrer Leistungsindikator ist es natürlich Quatsch, ohne Kontext bringt es dir nichts, wenn du "Kann Gears 5 in 200fps darstellen!" auf die Packung druckst. Kann in anderen Spielen dann mehr oder weniger sein. Oder im selben Spiel bei unterschiedlichen Einstellungen/Settings. Es ist jedoch die ehrlichste Abbildungsmöglichkeit für den Zweck, für den du Leistung suchst, wenn der Messungskontext angegeben ist.


    Deswegen meinte ich ja, dass ich eigentlich für visuelle Überzeugungskraft am ehesten empfänglich bin, weswegen bei mir auch so eine Quake-2-Ray-Tracing-Veröffentlichung oder eine Demo von Control mehr reinknallt als eine "UNFASSBARE 12 TFLOPS!"-Meldung aus der Marketing-Abteilung. Wenn Microsoft mit einem lauffähigen Prototypen der genannten Applikationen mit hohen Framerates um die Ecke kommen würde, meine Fresse wäre ich beeindruckt. TFLOPS hingegen? Gähn.

    Generell erstmal Respekt für dein technisches Hintergrundwissen. Ich mag ja generell solche Themen und diskutiere gerne darüber. Im vorletzten Post schreibst du, dass man die FPS als Vergleichswert für die Rohleistung statt den Flops nehmen sollte. In diesem zitierten Post widersprichst du dir aber quasi selbst. Je nach Spiel oder Benchmark schneidet GPU X total unterschiedlich ab.

    R
    Im Endeffekt ist die verbaute Hardware heute aber egal, es sind alles X86 PCs die voll kompatibel sind. Der Rest wird eben von Treibern und API bestimmt. D.h. man kann heutzutage gar nicht mehr auf eine bestimmte Hardware optimieren. Die Zeiten wo irgendwer in Assembler einen Chip direkt anspricht sind seit Ewigkeiten vorbei. Die Spielesoftware selbst spricht immer nur die Treiber und Schnittstellen an, also andere Software

    Das ist völliger Blödsinn. Mal davon abgesehen, dass wir von Konsolen reden die ein festes Ökosystem haben, kann man selbst im PC Bereich auf bestimmte Hardware hin optimieren, indem man bestimmte Features der Hardware nutzt, nur nicht in solch einem großen Stil wie bei Konsolen. Bei AMD gibt es z. B. Das gaming evolved Programm, bei dem Hersteller auf Radeon GPUs hin optimieren. Ich glaube das nVidia Gegenstück nennt sich gameworks oder so, hab jetzt keine Lust nach dem Namen zu googeln. Das Beste Beispiel ist da Wolfenstein 2. Das Spiel kann wie Doom mit Shader Intrinsic (GCN und Vega) umgehen und so gewisse Hardwarekomponenten von Radeon-Grafikkarten direkt ansprechen. Zudem nutzt das Spiel erstmals FP16-Shader mit Rapid Packed Math (nur Vega), sodass auf entsprechenden Grafikkarten die Shader ressourcenschonender und schneller als die klassischen FP32-Shader berechnet werden können. Das hatte den Effekt, dass die eigentlich durchweg langsamere Vega GPU die damals eigentlich deutlich schnellere und weitaus teurere 1080 Ti schlagen konnte. Da aber nicht jeder PC die selbe GPU beheimatet fällt die Optimierung nicht so aggressiv aus wie auf Konsolen. Wenn die Hardware keine Rolle spielen würde, wie du schreibst, müssteman ja auch die Spiele nicht portieren, damit es auf anderen Konsolen oder dem PC läuft, sondern könnte alles mit selbem Code laufen lassen.

  4. Generell erstmal Respekt für dein technisches Hintergrundwissen. Ich mag ja generell solche Themen und diskutiere gerne darüber. Im vorletzten Post schreibst du, dass man die FPS als Vergleichswert für die Rohleistung statt den Flops nehmen sollte. In diesem zitierten Post widersprichst du dir aber quasi selbst. Je nach Spiel oder Benchmark schneidet GPU X total unterschiedlich ab.

    Nene, ich habe geschrieben, dass FPS als reelle Leistungsangabe am besten dienlich ist, weil die Rohleistung in TFLOPS (aus den im Artikel genannten Gründen) nichts bringt. Dass du damit nur an der Wahrheit kratzt, ist logisch, deswegen ist dabei der Kontext (Spiel + Auflösung + Detailgrad) so wichtig. Eine allgemeingültige Aussage über die Leistung ist aber völlig unmöglich, da braucht man sich nichts vormachen.


    Vor allem, wenn du eben solche Exoten wie die id Tech 6 mit Half-Precision antreten lässt.

  5. FPS bringen genauso wenig denn wenn du die Details runterschraubst hast du im Normalfall eine höhere Framerate. Mit irgendetwas muss man ja werben und Terraflops hört sich unglaublich wichtig und super an. Wenn sich jemand an Daten aufhängen will ist es eigentlich egal ob er Tflops, FPS oder sonst was nimmt. Die Wahrheit ist aber dass man sicherlich kaum einen Unterschied zwischen 9Tflops und 12 Tflops sehen würde.


    Benchmarks sind in der Tat sowas von nicht aussagekräftig weil sie quasi nur kleine Echtzeitfilme sind. Auch hier kann ein Hersteller seine Hardware darauf optimieren um super Ergebnisse zu erzielen. In Spielen sieht dass dann ganz anderst aus. Es gibt einfach keinen Pauschalwert für gute Ergebnisse weil es rein vom Entwickler abhängt wie gut er sein Spiel anpasst und zurecht schleift.


    Die X86 Architektur ermöglich lediglich eine einfachere kompatibilität unter den System aber dass bedeutet nicht dass man ohne Aufwand alles portieren kann. Die Spiele können einfacher zum laufen gebracht werden aber sie laufen nicht automatisch gut. Sieht man ja allzu oft an den Konsolenports auf dem PC. CD Project Red hat damals bei Witcher 2 geschrieben dass das Spiel sofort auf der Xbox 360 geloffen ist weil diese dem PC ähnlich war, wärend es auf der PS3 nicht gelaufen ist. Trotzdem war noch ein Haufen an Anpassung nötig weil die Ressourcen stark begrenzt waren im Vergleich zum PC. Die PS3 Architektur hat aber einen Port gänzlich unmöglich gemacht.
    Eine Konsole hat durchaus einen großen Vorteil weil eben alle verbauten Komponenten identisch sind und das bei zig Millionen Geräten.

An dieser Stelle siehst du nur die letzten 5 Kommentare. Besuche das Forum um die komplette Diskussion zu diesem Thema zu sehen.