Auflösung in PS3 Games

renozeross schrieb:

Also wir sind uns einig. Zaubern kann man nicht. Aber wenn man GTA4 exklusiv für die PS3 entwickelt hätte, und die Kerne ausgenutzt hätte würde es flüssiger und mit weniger matschigen Texturen laufen.

Das kannst du so einfgach nicht sagen, denn GTA4 nutzt zum Teil wiederum Third Party Software, die wiederum als Multi-Plattformk entwickelt wurde, oder um ehrlicher zu sein: die nachträglich auch noch auf die PS-3 herrübergewürgt wurde.

Ich denke hier liegt ein weiteres Mißverständnis der heutigen Lage: Immer mehr Spiele basieren in Wirklichkeit auf Tools und Programmen anderer Hersteller.

Im Prinzipß war hier genau eine der Stärken der PS-2, doch jetzt eine der Schwächen eines Exklussivspiels.

Auf der PS-2 wurden zunächst im Laufe der Programmentwicklung massive Vorräte an Tools und Programmbibliotheken geschaffen, die von Programm zu Programm immer weiter verfeinert und verbessert wurden. Als dann die Xbox auf den Markt kam hätte man im Prinzip diese Programmbibliotheken auf der Xbox neu aufbauen müssen um die Programme anschließehnd auf der Xbox und der PS-2 zugleich verkaufewn zu können. Dieser Aufwand erschien den meisten japanischen ENtwicklern zu hoch, nicht zuletzt, weil man die Leute erst mal auf der Xbox hätte schulen müssen.

Dieses Mal war jedoch die Xbox 360 zuerst fertig, doch man wußte von Anfang an, dass diese im Prinzip den gleichen Basis Prozessor wie die PS-3 besitzt, nur dreifach. Da dieser Multi-Core Ansatz sich auch für die PCs andeutete paßte man derartige Entwicklungssysteme natürlich an derartige Umgebungen an: Ich kralle mir einen Core, dann hat das eigentliche Spiel immer noch 2 + freie Slots auf meinem Core.

Da die Basis-Konzepte ähnlich sind bot es sich für Tool Hersteller an sich nicht auf Gedeih und Verderb auf eine Plattform fest zu legen.
Wenn man derartige zugekauften Tools verwendet gibt es eben genau wegen der schwierigen Synchronisation immer gewisse Probleme, wie auch durch Eigenheiten der SPEs (bestimmte Funktionen laufen sehr schnell, andere sehr langsam). Auf dieser Basis ist es sehr schwer den eigenen Code einerseits zu schützen und andererseits den Nutzern genug Verüänderungsmöglichkeiten zu geben, damit diese möglichst wenig unter deinen Laufzeitanforderungen zu leiden haben. Die Wiederverwendbarkeit von SPE Code ist erheblich geringer als der von normalen Routinen auf einem Multicore, da man auf dem SPE Hardware näher programmiert.

Doch andererseits haben die neuen Plattformen nun einmal auch deutlich mehr Möglichkeiten. Entsprechende Routinen selbst zu schreiben kostet sehr viel Zeit und Geld und man weiß noch nicht einmal ob das Endergebnis besser aussieht, denn bis du fertig bist ist bei denen schon wieder die nächste Generation fertig. Es ist daher im allgemeinen weitaus billiger sich entsprechende Software dazu zu kaufen, doch diese schränkt im Prinzip deine Freiheitsgrade auch etwas ein und du kannst mit speziellen Hardwareanpassungen wie für die PS-3 weniger Vorteile erzielen, statt dessen machen sich gerade ihre Schwächen deutlich bemerkbar.

Und wenn man sich die Schwächen von GTA4 ansieht deutet es gerade auf diese bekannten Schwächen hin, nur ist daran nun eher die Third Party Software Schuld oder das Programm selbst?

Im Prinzip nutzt dieses System genau eines der Verfahren die der PS-3 theoretisch mehr Leistung geben (Vorberechnung von Grafik Objekten in den SPEs) sollten, nur können die SPEs lesend eben nur schnell auf das normale RAM zurück greifen.

Ohne jetzt hier eine Plattform bevorteilen zu wollen, doch wer zugekaufte Tools nutzen will kann vor allem im Multiplattform Bereich davon profitieren, während zum reinarbeiten und austüfteln die Xbox 360 eindeutig den besseren Ruf hat. Für die Entwicklung auf der PS-3 muß man laufgend die Vorstellungsräume verlassen, wodurch es vor allem bei parallelen Prozessen zu Race Conditions kommt und man keine echte Ahnung hat was eigentlich vor sich geht. In der Beziehung ist die Xbox 360 schlichtweg weritaus einfacher zu debuggen. IBM selbst schlägt vor dass man auf der PS-3 das gesamte Programm zuerst auf dem PPE zum laufen bringen sollte und von dort ausgehend unabhängige Prozesse bildet (damit wäre das Programm auf der Xbox 360 im Prinzip fertig!) und diese schließlich für die SPEs portiert. Man sitzt also erheblich länger an der Vorplanung während man auf der Xbox 360 bereits austestet.

Im übrigen ist es eine vollkommen irrige Vorstellung dass mehr Kerne eine schnellere Ausführung bedeuten. Es ist hingegen entscheidend dass Programme überhaupt gut parallelisierbar sind. Spiele gelten vor allem durch die Bedingung Realzeit Applikation nur als bedingt parallelisierbar, da durch die Handlung des Spielers jederzeit Berechnungen basierend auf "alten" Daten sinnlos werden können. Es dürfte in vielen Bereichen schwierig sein mit der Spielmechanik mehr als 2-3 Cores zu beschäftigen.
Aus genau denselben Gründen wird momentan den Hardware-Entwicklern der Wind aus den Segeln genommen, denn desto mehr Cores man hat, desto weniger Geschwindigkeitsvorteile bringen sie, wenn man ihnen nicht eine Vielzahl unabhängiger Probleme zu fressen geben kann. Desweiteren steigt der Synchronisierungsoverhead für die Prozessoren und es steht immer weniger Kapazität für sinnvolle Berechnungen zur Verfügung. So soll im Prinzip der PPE im echten Cell primär der Synchronisierung und Verwaltung der SPEs dienen, doch ein derartiger Ansatz ist in Spielen einfach nicht drin, denn es läuft immer wieder darauf hinaus dass er der einzige ist der weiß was ansteht und bevor er einen dedizierten Prozess auf einem bislang unbenutzten SPE initialisiert und gestartet hat, kann er schon längst ein Ergebnis selbst berechnet haben. Die SPEs machen genau dann Sinn, wenn viel Rechenzeit für eine relativ geringe Anzahl an Daten benötigt wird. Bei trivialen Problemen oder Probleme die über sehr große und dennoch eng verknüpfte Datenmengen scheinbar zufällig zugreifen muß ist der SPE sinnlos. Die SPEs sind nun einmal Datenstrom orientierte Einheiten, während eine klassische CPU eher Random Access orientiert ist. Man hat wenig Informationen welche Daten demnächst benötigt werden.

Physikalische Modelle lassen sich recht gut parallelisieren, doch auf diese kommt es in Wirklichkeit bei den Spielen nur zum kleinen Teil an. Es muß nur glaubhaft wirken und sich so anfühlen, was sich näherungsweise sehr gut mit vereinfachten Verfahren durchführen läßt. Es interessiert nun mal einen Spieledesigner nicht dass der Charakter sich bei der Aktion eigentlich alle Knochen brechen würde. Wenn es gut aussieht, wird es gemacht. Für derartige Berechnungen ist ein SPE so etwas, als ob man mit Kanonen auf Spatzen schießt. ATI hatte schon vor einiger Zeit angefangen statt dessen einfache Shader etwas mehr zu generalisieren. Derartige Einheiten können im Prinzip so etwas genauso gut durchführen.

Es ist in vielen Fällen gar nicht mal so schwierig ausreichende Kapazitäten zu haben, sondern es ist nicht zuletzt die Verteilung von Aufgaben. Sowohl Mac OS X wie auch Windows sind heute im Prinzip in der Lage kleine Nebenjobs an Shader der GPU auszulagern. Denn diese Shader sind genau wie die SPEs Datenstrom orientiert nur sind sie einfacher, aber dafür schneller und in größerer Stückzahl vorhanden.

Die Vorstellung das viele Einheiten auch automatisch zu schnelleren Ergebnissen führen kam auch in den siebziger Jahren des letzten Jahrunderts auf, doch dann konnte leider BEWIESEN werden, dass diese Vorstellung falsch ist.

Es gibt im Fachbereich Elektrotechnik eine Vorlesung: Rechnerstrukturen, wo genau derartige Probleme behandelt werden. Dort lernt man dass ein Viel hilft Viel eben nicht geht, sondern so manche kleine Änderung kann sehr viel einbringen, während eine große teure Änderung in Wirklichkeit das System verlangsamen kann, oder zumindest bei hohen Kosten ein kaum erkennbarer Vorteil zustande kommt. Es kann daher durchaus sein, dass ein Problem auf 2 Cores weitaus schneller abarbetiet wird, als auf acht! Um das zu klären müßte man ganz genau den Programmcode analysieren. Ich denke in dieser Lage sind wir nicht. Die bloße Behauptung dass mehr Prozessoren eine größere Geschwindigkeit bedeuten ist auf jeden Fall in dieser Allgemeinheit falsch!

Allerdings muß ich zugeben, dass es nicht einfach ist diese Problematik zu verstehen. Man muß sich nur mal in die damalige Zeit zurück versetzen: Als diese Beweise gefunden wurden realisierten Leute dass sie Millionen von Dollar in ein Phantom gesteckt hatten oder dass sie die letzten zehn Jahre ihres Lebens einem Projekt verschrieben hatten, das unmöglich zu lösen war!

Damals dachte man dass Transputer in kurzer Zeit die normalen CPUs zum Schrott degradieren würden. Damals stieß man auf den Grad der Parallelisierbarkeit eines Programmes. Es gab tatsächlich Experten die aufgrund der schlechten Parallelisierbarkeit den Multi Core der Xbox 360 als Schwachsinn bezeichneten. Als schließlich Sony mit dem endgültigen PS-3 Layout kam schüttelten diese nur noch ungläubig den Kopf.

Unter solchen Bedingungen ist ein Vorwurf warum man NUR 2 CPUs nutzt reichlich verwegen, solange man nicht selbst an dem Projekt gearbeitet hat! Die Tatsache das ein anderes Programm scheinbar das Problem besser gelöst hat ist ohne passende Internas nicht mal annähernd als Beweis geeignet.

Gute Beitrag Kartsen!

Nur eine Anmerkung...

Ich denke schon, dass eine stärkere Parallelisierung der Prozesse die einzige gangbare Lösung derzeit ist.

Das hier die grundlegenden Prozesse in den "Kinderschuhen" stecken, dass man hier auch in der Entwicklung zahlreiche Fehler macht ist klar, dennoch denke ich, dass es der richtige Weg ist.

Grüße,

NIUBEE

NIUBEE schrieb:

Ich denke schon, dass eine stärkere Parallelisierung der Prozesse die einzige gangbare Lösung derzeit ist.

Das sagt sich zwar einfach aber dummerweise kann in zahlreichen Fällen tatsächlich bewiesen werden, dass eine Parallelisierung sehr schnell auf logische Grenzen stößt die nicht zu verhindern ist. Man hat sich bereits sehr weit an diese Grenzen herangearbeitet, denn der wesentliche Grund für globale Caches ist ja genau der, dass man zum Teil in Daten hinein sehen kann die der andere Prozeß noch gar nicht geschrieben hat.

Eine derartige Technik war damals noch nicht bekannt. Daher ist eine weitestgehende Optimierung bereits heute möglich. Doch darfst du Taskwechselzeiten und Zeiten für Prozessinitialisierung nicht ignorieren.

Der Cell ist für bestimmte Arten von Algorithmen geschrieben worden, doch definitiv nicht für Spiele. Dies läßt sich eigentlich an einem einfachen Beispiel zeigen:
Nehmen wir mal an, wir würden uns die Arbeit einfach machen wollen und für jeden gegnerischen Charakter einen Prozess starten.
Dieser Prozeß braucht dringend Zugriff auf Daten seiner näheren Umgebung, also auf eine Map die im Grunde das repräsentiert, was seine "Augen" wahr nehmen.
Für einen klassischen MultiCore theoretisch eine sehr einfache Aufgabe: Man startet wirklich für jeden "Gegner" einen Prozeß, der seine momentane Map aus dem globalen Cache nimmt. Sobald er seine Entscheidung getroffen hat kann er auch direkt seine Positionsänderung beim "Map-Wächter" beantragen (den brauchen wir um Race-Conditions zu verhindern). Der Prozessor selbst kümmert sich darum dass diese Prozeße bestmöglich auf die Cores verteilt sind (Load-Balancing).

Sehen wir uns die Lage bei den SPEs an. Bis zu maximal sieben "Gegnern" klappt das, ansonsten mußt du neue SPE Prozeße schreiben die mehrere Gegener auf einmal verarbeiten. Außerdem müssen diese Prozesse laufend Teile der Map über den lokalen Bus anfordern oder gewschickt bekommen durch den "Map-Wächter". Schon die Zeitdauer dieses Transfers ergibt eine erheblich größere Update-Zeit zwischen zwei Zeitschritten der Map. Es gibt außerdem keine dynamische Lastverteilung. Da im Normalfall ein dynamischer Wechsel von SPE Programmen selten vorkommt ist dieser Prozeß eher aufwändig realisiert. Daher kann es tatsächlich sein dass die PS-3 in manchen Situationen weniger parallel ausgelegt ist als das entsprechende Programm auf der Xbox 360. Durch die Möglichkeit von mehr Handarbeit kannst du zwar theoretisch größere Leistung erzielen doch du mußt auch mehr Arbeit hinein stecken.

Wie sieht es jedoch in der realen Programmentwicklung aus?
Das eigentliche Programmziel ist mehr oder minder eine diffuse Masse und die Spieleentwickler kommen mit neuen Ideen, die sie mal gerne ausprobieren wollen.
Unter diesen Vorstellungen ist es wohl klar welches Team eher diese Idee hineinzwängen kann und auf welcher Plattform das neue Feature beurteilt wird.
Wenn du solche Features auf der PS-3 nachpflegen darfst landen sie meist einfach im PPE Code. Ein Nachpflegen in die SPEs bedeutet nämlich häufig genug dass die SPE Verteilung noch mal neu beurteilt werden muß. Doch das bedeutet natürlich auch dass der PPE häufig genug einen größeren Teil der eigentlichen Rechenarbeit übernehmen darf, als eigentlich sinnvoll ist. PPE und SPE Code muß man schließlich vollkommen getrennt verwalten und verwenden.

Im Cluster Computing, wie auch in der Entwicklung von massiven Pipes ist es vollkommen normal dass man znächst das gesamte Programm einmal langsam in Form eines einzigen Programmes aufbaut um Konzeptionsfehler zu entdecken usw. Es macht eben nichts aus wenn in der Testphase etwas unendlich langsam abläuft, wenn die potentiellen Fehler genauso auftauchen. Doch Spieletestern geht es so nicht, weil die gesamte Wahrnehmung vollkommen anderes abläuft, wenn man Spielelemente in Superzeitlupe sieht. Daher wird es wohl auch immer so bleiben das wichtige Ideen in Buchstäblich letzter Sekunde dazu gepackt werden.

Doch in so einem Umfeld ist es schlichtweg eine Riesendummheit massiv parallel arbeiten zu wollen, da KEIN MENSCH intuitiv das gesamte Zeitverhalten seiner Prozesse überblickt. Wer schon mal derart gearbeitet hat, weiß bei was für trivialen Problemen sich teilweise Race-Conditions einschleichen. Ich saß neulich mit einem Kollegen geschlagene drei Wochen an knapp 200 Zeilen Code. Extrem langsam, aber da wir wußten das wir in einem absolut kritischen Bereich operierten, und dort Fehler im Nachinein kaum auffindbar wären, war es voll angemessen.
Fehlerfreiheit des Codes hat in parallelen Programmen eine vollkommen andere Bedeutung, da dass Debuggen um ein vielfaches schwieriger ist. Wie willst du derartige Forderungen in Projekten durchsetzen, wo sich alles um "Time To Market" und geringe Kosten drängt?

Ich denke in weiten Bereichen wird sich Parallele Programmierung auf die Nutzung vorgefertigter Libraries beschränken.