• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

News PlayStation 4: Entwickler dürfen jetzt sieben Jaguar-Kerne nutzen

Rickmer schrieb:
Jain.
Da AMD sich entschieden hat so ein Modul als zwei Kerne zu vermarkten kann man das nicht mehr mit Hyperthreading gleichsetzen... auch wenn es vom Prinzip her nicht unähnlich ist.

Abgesehen davon hat die Jaguar Architektur nichts mit CMT zu tun :D
 
Cool Master schrieb:

Nein tut man nicht. Auf Windows/OSx/Linux ja, weil die Anzahl der Kerne für die Anwendung größtenteils transparent ist und man seinen Code einfach auf beliebig viele Kerne hinschreiben kann. Aber selbst das geht nur bei Anwendungen die sich tatsächlich beliebig parallelisieren lassen. Dazu gehören Spiele nunmal aber definitiv nicht. Ganz egal wie sehr du es herbeipredigst, eine Simulation (und nichts anderes ist ein Spiel) lässt sich nicht beliebig parallelisieren weil durch die nicht mehr garantierte Ausführungsreihenfolge so viele Fehler und Schwierigkeiten reinkommen, dass das keiner macht, weil es schlichtweg nicht zu beherrschen ist.

Und dann ist es immer noch ein Riesenunterschied ob man nun auf Windows das schon alles irgendwie scheduled programmiert oder eben auf einer Konsole wo man so lowlevel drauf rumrutscht dass man tatsächlich sagen kann: "Kern 1 führt jetzt die Physiksimulation aus und Kern 2 die KI".
Genau das kann man bei Windows nämlich nicht. Da kann man nur sagen: "ich will dass Physik und KI irgendwie parallel laufen, sofern das denn möglich ist".

Bei ersterem muss ich den kompletten Code umschreiben damit Kern 7 auch noch benutzt wird, bei letzterem muss ich mich einfach drauf verlassen, dass das OS schon irgendwie den 7ten Kern mitbenutzt und meine einzige Sorge ist, dass ich dem OS auch mindestens 7 Sachen vorwerfen muss, die es parallel tun soll. Das ist ein himmelweiter Unterschied.
 
@dgschrei

Gerade eine Simulation lässt sich super parallelisieren. Schau dir den FSX an, der packt 256 Kerne! Wie ich schon schrieb je nach programmierung ergo wie viel wurde OOP gemacht lässt sich das schnell oder schwer umsetzen.
 
Ein weiterer Kern? Schön. Wird sicher viel bringen.

https://twitter.com/gafferongames/status/668901888155394049

dgschrei schrieb:
Nein tut man nicht. Auf Windows/OSx/Linux ja, weil die Anzahl der Kerne für die Anwendung größtenteils transparent ist und man seinen Code einfach auf beliebig viele Kerne hinschreiben kann. Aber selbst das geht nur bei Anwendungen die sich tatsächlich beliebig parallelisieren lassen. Dazu gehören Spiele nunmal aber definitiv nicht.

Wir sind noch lange nicht an der Grenze des Möglichen, nicht einmal ansatzweise, wir sind noch nicht einmal an der Grenze des einfach machbaren. Bei allen Spielen, die nicht gerade KSP heißen, ist der Renderthread das, was einen Kern vernichtet und die anderen langweilt, und das lässt sich sehr wohl multithreaden. Halt nur nicht mit vorsintflutlicher Software wie D3D11, und Arbeit ist es natürlich.

Gerade miserable und faul geschriebene Engines wie die von Fallout sind natürlich die, die hier am wenigsten profitieren. Fallout könnte man auch 500 Kerne hinwerfen und es wäre noch langsam.
 
dgschrei schrieb:
Und dann ist es immer noch ein Riesenunterschied ob man nun auf Windows das schon alles irgendwie scheduled programmiert oder eben auf einer Konsole wo man so lowlevel drauf rumrutscht dass man tatsächlich sagen kann: "Kern 1 führt jetzt die Physiksimulation aus und Kern 2 die KI".
Oh man. So wird maximal ein Exklusivspiel programmiert und selbst dann wäre die Vorgehensweise extrem fragwürdig, weil es ja bedeuten würde das der Entwickler genau weiß in welcher Situation welcher Prozess wieviel Leistung braucht. Im Umkehrschluss würde extrem viel Leistung verschenkt, wenn z.B. gerade keine KI berechnet werde müsste, dafür aber Physik gerade sehr wichtig wäre.

Guter Code hat einen eigenen Thread Sheduler. Das Spiel meldet seinen benötigten Threads bei diesem an und der verteilt dann die Threads auf die ihm zu Verfügung stehenden Ressourcen. Gerade wenn man für unterschiedliche Systeme programmiert, wird das so gehandhabt. Schließlich will man jede Menge Code wieder verwenden und nicht jede zweite Anweisung umschreiben, weil auf einmal nur 5 oder 4 Threads zur Verfügung stehen. Deshalb wird die Integration von einem Kern sehr wahrscheinlich nur eine minimale Änderung an der Code Basis verursachen. Der Scheduler kann ab jetzt mehr Ressourcen nutzen. Fertig. Ob das in vielen Spiele was bringt ist die andere Frage. Die wenigstens Games werden bisher alle Kerne genutzt haben.

Kerne für spezielle Aufgabe zu reservieren macht höchsten das OS, aber sicherlich kein Spiel.
 
@CoolMaster Ich entwickle selbst Software und das nicht gerade im kleinen Maßstab. Und nein es macht einen ganz gewaltigen Unterschied ob ich nun eine Physiksimulation nun sequentiell oder parallel ausführe.

Ein gutes Beispiel für parallele Physiksimulation wäre z.B. PhysX. Das muss prinzipbedingt schon auf hunderte Threads parallelisieren, weil das sonst mit der GPU-Berechnung nichts wird. Das hat aber eben auch seinen Preis. Sollen die einzelnen Partikel nicht nur mit der Umgebung sondern auch mit sich selbst kollidieren, wird's nämlich ganz schnell haarig. Weil dann müsste Partikel A ja wissen wo Partikel B zum Zeitpunkt des aktuellen Ticks in der Simulation ist. Wenn die Bahn von Partikel B aber auf einem völlig anderen Thread zu einem überhaupt nicht garantierten Zeitpunkt berechnet wird, dann ist es praktisch nicht möglich immer den aktuellen Zustand von B zu wissen.

Deswegen unterstützten erste Versionen von PhysX die Kollision zwischen Partikeln einfach gar nicht. Das sah dann halt auch entsprechend unrealistisch aus.

Spätere Versionen unterstützen das jetzt aber dort wird zweifellos einfach getrickst und es wird für die Berechnung einfach der letzte bekannte Zustand von Partikel B genommen. Ob der jetzt schon aktuell ist oder nicht wird einfach ignoriert. Das ist aber dann eben nicht mehr deterministisch. Soll heißen wenn man zweimal die gleiche Simulation laufen lässt, kommt zweimal ein anderes Ergebnis heraus. Und das will man in einer Simulation eigentlich nicht haben. Deswegen nutzen Spiele die PhysX benutzen die PhysX Effekte meist auch nur für hübsches Beiwerk wie rumfliegende Partikel, Staub, kleine Steinbrocken die die Kugel aus der Wand rausschlägt usw (Borderlands 2 ist da ein super Beispiel für), aber eben nicht für Physikeffekte die das Gameplay beeinflussen. (wie z.b. Half Life 2 das mit Havok gemacht hat) Dafür nimmt man dann eine single Threaded Physiksimulation damit das Ergebnis deterministisch bleibt und der Spieler sich darauf verlassen kann, dass das Ergebnis seiner Handlungen auch konsistent ist.

Und sorry, aber was hat OOP mit Multithreading zu tun? Naughty Dog hat Multithreaded Code für den Cell in Assembler geschrieben. Man kann multi-threaded Code mit OOP schreiben, aber man braucht kein OOP um Multithreading zu betreiben. Sonst wäre der Linux Kernel auch irgendwie komplett angeschmiert :).

@GrooveXT
Grundsätzlich richtig, weswegen auch so gut wie kein Studio mehr seine eigenen Engines verwendet sondern größtenteils Unreal, CryEngine, Frostbite, Unity3D und co zugekauft/benutzt werden.
Dort wurde die Arbeit auf die Xbone/PS4 zu optimieren eben einmal gemacht und jetzt setzt man darauf auf.

@Zehkul
Nur dass auf den Konsolen keiner D3D11 benutzt sondern Low-Level APIs wo das mit der parallelisierung des Render Threads längst usus ist.
 
Zuletzt bearbeitet:
S1ru9p schrieb:
Nein. Es sind keine "stink" normalen Jaguar CPUs in der PS4 oder XOne verbaut. Diese weichen von der Architektur der PC Desktop Variante ab.

Du willst mir also sagen, das aufgebohrte ALUs und ein geänderter Speichercontroller einen anderen CPU Kern machen? Da muss Sony ja richtig tief in die Tasche gegriffen haben....
 
Cool Master schrieb:
Warum ist nicht jeder Kern freigegeben? Hat man ja unter Windows, OS X oder Linux auch und da kommt es zu keinen Problemen mit dem OS.
Ich kann jetzt nur für die XboxsSprechen, aber dort laufen drei Betriebssysteme drauf. Ein Hostsystem auf dem dann zwei Gastsysteme laufen. Eines für die Spiele und eines für die Oberfläche und die ganzen Mediageschichten. Damit beiden Systemen immer genügend Resourcen zur Verfügung stehen und diese auch schön parallel arbeiten können ist einem der Gastsysteme ein eigener Kern zugewiesen. Ursprünglich war auch der Kinect ein eigener Kern zugewiesen worden, aber diese Vorgabe hat man mittlerweile gelockert und den siebten Kern auch für andere Zwecke freigegeben.
Ich denke so ähnlich wird das Ganze bei der PS4 sicherlich auch irgendwie laufen. Gewisse Aufgaben die garantiert werden müssen bekommen ihre festen Resourcen zugeteilt und Spiele erhalten dann eben nur den Rest, der noch übrig bleibt.
 
VikingGe schrieb:
Jaguar hat aber bekanntlich eh kein SMT/CMT/whateverMT.

Danke das war meine Frage. Damit dürfte ein 6700K mit HT für Multiplattformspiele dauerhaft genausogut geeignet sein wie ein 5820K.
 
dgschrei schrieb:
@Zehkul
Nur dass auf den Konsolen keiner D3D11 benutzt sondern Low-Level APIs wo das mit der parallelisierung des Render Threads längst usus ist.

Nicht wirklich. Wenn das Usus wäre, könnten die großen Engines alle kinderleicht DX12 implementieren, können sie aber nicht, weil keine Engine das je getan hat. Die grundlegende Architektur aller Grafikengines funktioniert vollkommen anders, und das schreibst du nicht mal eben für einen Konsolenport komplett um.

Die Konsolen sind noch neu und die alten hatten wenig Kerne, bisher hat sich keiner großartig um Multithreading gekümmert, und am PC gings sowieso nie, also hat mans gelassen. Das kommt alles erst jetzt so langsam.
 
Oromis schrieb:
Abgesehen davon hat die Jaguar Architektur nichts mit CMT zu tun :D

Ich glaube der Punkt war eher, wie pauschal gesagt wurde, das AMD kein HT kann. Das Jagur nichts mit CMT zu tun hat ist dann wieder ein anderer Hut :)
 
dgschrei schrieb:
@GrooveXT
Grundsätzlich richtig, weswegen auch so gut wie kein Studio mehr seine eigenen Engines verwendet sondern größtenteils Unreal, CryEngine, Frostbite, Unity3D und co zugekauft/benutzt werden.
Dort wurde die Arbeit auf die Xbone/PS4 zu optimieren eben einmal gemacht und jetzt setzt man darauf auf.
Gerade dort wird es keine festen Kern Zuweisung geben. Weil die Engine Entwickler ja nicht erahnen können ob du nun ein physiklastiges Spiel produzierst oder eher viel KI brauchst. Außerdem handelt es sich dabei um eine Engine für diverse Funktionen aber es läuft bei Leibe nicht der ganze Code in der Engine. Die Argumentation hat bei der PS3 noch Sinn gemacht, wo nicht jeder Kern auch tatsächlich alles konnte, aber hier macht das keinen Sinn. Der OS-Unterbau der PS4 ist übrigens BSD und der verfügt über die gleichen Multiprozessorfähigkeiten wie z.B. Mac OS. Das einzige was die Engines limitiert ist die maximale Anzahl der möglichen Softwarethreads. Wenn Unity z.B. seine Arbeit nur in 6 Threads aufteilen kann, wird man niemals was von dem 7 Kern haben...dafür müsste ein großer Teil der Engine neu geschrieben werden. Da Unity aber auf mehreren System läuft gehe ich mal stark davon aus das durchraus mehr Threads angesprochen werden können.
 
Wird alles immer besser...
Berechtigte Frage, wieso eigentlich erst jetzt? Warum nicht direkt vorher? Hätte es keine besseren Ergebnisse gebracht wenn die Kerne nicht von Anfang freigeschaltet wären? Sorry, aber ich verstehe so Recht nicht was das soll? Wenn ich als Käufer dadurch mehr FPS und höhere Auflösung in einem Game bekomme, weil der Entwickler endlich Zugriff auf den weiteren Kern hat um ein Game zu optimieren, warum nicht gleich Anfang an so?

Was auch immer, ich bin gespannt und hoffe die Konsoleros profitieren auch davon und dem Entwickler bringt es mehr.
 
SirBerserk schrieb:
durch den freigegebenen kern kann der cpu teil nun mehr strom ziehen, weshalb die taktrate wohl sinken wird, weil das kühlsystem nicht mit dem mehrverbrauch klarkommen würde. also bleibt die gesammtrechenleistung gleich.
Die Leistungsaufnahme eines Gerätes ist die Nennleistung, bzw die maximale Leistung die das Gerät aufnehmen kann. D.h. Die Konsole verbraucht die Leistung wie sie angeben ist, wenn alles grad auf maximal steht: Prozessoren, Lüfter, Festplatte, Laufwerk.
Das Kühlsystem ist ausgelegt für die Maximale Leistung. Und nicht im Idle oder sonst was.

(Eigene Elektrotechnik Weisheit)
 
Satzzeichen schrieb:
Wird alles immer besser...
Berechtigte Frage, wieso eigentlich erst jetzt? Warum nicht direkt vorher? Hätte es keine besseren Ergebnisse gebracht wenn die Kerne nicht von Anfang freigeschaltet wären? Sorry, aber ich verstehe so Recht nicht was das soll? Wenn ich als Käufer dadurch mehr FPS und höhere Auflösung in einem Game bekomme, weil der Entwickler endlich Zugriff auf den weiteren Kern hat um ein Game zu optimieren, warum nicht gleich Anfang an so?

Was auch immer, ich bin gespannt und hoffe die Konsoleros profitieren auch davon und dem Entwickler bringt es mehr.

Beides wird nicht passieren. Die minFPS werden sich dadurch nur stabilisieren oder man kann mehr KI/Physik einbauen. Bei Gran Tourismo z.B. 2 mehr Fahrer im Feld.

Ich denke mal das durch die BS Updates das ganze System schlanker und Perfomanter geworden ist und somit nurnoch 1 Kern benötigt wird. Für die Aufzeichnung und Hintergrundaufgabegn hat die PS4 ja zahlreiche Zusatzchips.
 
Satzzeichen schrieb:
Wird alles immer besser...
Berechtigte Frage, wieso eigentlich erst jetzt? Warum nicht direkt vorher? Hätte es keine besseren Ergebnisse gebracht wenn die Kerne nicht von Anfang freigeschaltet wären? Sorry, aber ich verstehe so Recht nicht was das soll? Wenn ich als Käufer dadurch mehr FPS und höhere Auflösung in einem Game bekomme, weil der Entwickler endlich Zugriff auf den weiteren Kern hat um ein Game zu optimieren, warum nicht gleich Anfang an so?

Was auch immer, ich bin gespannt und hoffe die Konsoleros profitieren auch davon und dem Entwickler bringt es mehr.

Die Kerne sind/waren ja fürs OS, damit da alles läuft und Hintergrundaktivitäten den Spielfluss nicht stören (Update, Streaming, etc.)
Dadurch das Sony jetzt weiter am OS gearbeitet hat, konnte man dort wohl Resourcen einsparen, die man nun freigegeben hat.
Übliches Sprichwort: Better safe than sorry.
 
neo243 schrieb:
die ps4 nimmt doch auch durchgehend die letzten 15 Minuten auf oder? Das müsste doch auch 10% oder mehr an Leistung fressen.

Nein.
Dafür ist ein eigener Chip zuständig. Bei der Xbone wird die CPU dafür angezapft.
 
Zurück
Oben