Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
Intel hat zwar auch die GPU auf das Die der CPU gebracht, aber die Kommunikation zwischen GPU und CPU ist für so etwas, was die PS4 kann, nicht vorgesehen.
Wie kommst du denn auf die Idee?
-
ScottZhang schrieb:
Hat nichts zu sagen, das Video ist schließlich ein Grafikblender und kein Physikblender wo sich viele Objekte ändern.
Also für PCs optimiert.
Das was die PS4 so toll macht, wird darin also gar nicht getestet.Benschmarks mit OpenCL Berechnungen die viele Daten zwischen GPU und CPU austauschen müssen wären wesentlich aussagekräftiger.
Da würde der PC gegen die PS4 abkacken.
-
hustbaer schrieb:
Intel hat zwar auch die GPU auf das Die der CPU gebracht, aber die Kommunikation zwischen GPU und CPU ist für so etwas, was die PS4 kann, nicht vorgesehen.
Wie kommst du denn auf die Idee?
Kannst du von der iGPU und CPU auf den gleichen Speicher zugreifen?
Also auch dann, wenn der Speicher für eines der beiden reserviert ist?Kannst du die iGPU z.B. für OpenCL nutzen, während im Rechner eine normale GPU steckt?
-
Man beachte auch:
Zudem könnten die GPGPU-Berechnungen simultan zu den Grafikberechnungen ausgeführt werden, was auf PCs derzeit nicht möglich sei.
Der 8 GByte GDDR5-Speicher habe ein Unified Architektur und könne sowohl von der GPU wie auch von der CPU adressiert werden. Über sein 256-Bit-Interface kommt er auf eine Bandbreite von 176 GByte/s. Die hohe Rechenleitung ermögliche mehr interaktive und Bewegliche Objekte in der Spielumgebung. Die Darstellung von Rauch, Wasser, Explosionen und Feuer würden ebenso profitieren wie das Rendering von Haaren, Kleidung und Haut.
http://www.heise.de/ct/artikel/GDC-Was-Entwickler-und-User-bei-der-Playstion-4-erwartet-1831997.html
Zum Vergleich, die Bandbreite von PCIe 3.0 liegt bei 32 Lanes (Maximalausbau!)
bei nur 30,77 GB/s, also 5,7 mal weniger. Dass schadet, sobald man vom Hauptspeicher Daten an den Speicher der GPU schicken will.
Und gerade das ist notwendig, wenn die Physik teil des Gameplays und nicht nur verschönerndes Beiwerk werden soll.
Da müssen die Daten nämlich wieder zurück zur CPU.Mit dedizierten GPUs ist das wegen PCIe sau teuer und mit aktuellen iGPUs nur geringfügig günstiger, weil der Speicher nicht geteilt wird.
Man also Daten kopieren muss.
-
PS4 schrieb:
hustbaer schrieb:
Intel hat zwar auch die GPU auf das Die der CPU gebracht, aber die Kommunikation zwischen GPU und CPU ist für so etwas, was die PS4 kann, nicht vorgesehen.
Wie kommst du denn auf die Idee?
Kannst du von der iGPU und CPU auf den gleichen Speicher zugreifen?
Also auch dann, wenn der Speicher für eines der beiden reserviert ist?Die Hardware kann es. Ist schliesslich alles Shared Memory. Die Treiber vermutlich (noch) nicht. Allerdings ist das nur eine Frage der Zeit.
Kannst du die iGPU z.B. für OpenCL nutzen, während im Rechner eine normale GPU steckt?
Das können die Intel-Dinger im Moment nicht. Würde mich aber auch wundern wenn das eine Hardware-Limitierung wäre. D.h. es müsste sich mMn. mit einem BIOS-/Treiber-Update machen lassen.
-
Die Playstation 4 bringt Intel doch bezüglich der Gaming PCs in Zugzwang.
Denn dort, auf der PS4 stört kein lahmer Bus zwischen CPU und GPU.Seit wann hat Intel denn irgendwelche Relevanz bei ernsthaften GPUs?
PS4 schrieb:
Man beachte auch:
"Der Speicher habe ein Unified Architektur und könne sowohl von der GPU wie auch von der CPU adressiert werden."Wow, das ist dann ja genauso wie bei der XBOX1
PS4 schrieb:
Benschmarks mit OpenCL Berechnungen die viele Daten zwischen GPU und CPU austauschen müssen wären wesentlich aussagekräftiger.
Da würde der PC gegen die PS4 abkacken.Der Clou bei den OpenCL ist doch, dass man der GPU die Daten in ihrem eigenen Speicher bereitstellt und OpenGL diese anschliessend direkt weiterverarbeiten kann.
Der Datenaustausch wird also gerade vermieden.
-
hellihjb schrieb:
Die Playstation 4 bringt Intel doch bezüglich der Gaming PCs in Zugzwang.
Denn dort, auf der PS4 stört kein lahmer Bus zwischen CPU und GPU.Seit wann hat Intel denn irgendwelche Relevanz bei ernsthaften GPUs?
Verkauft Intel mehr CPUs, wenn die PS4 bei Gamern sehr beliebt ist?
PS4 schrieb:
Man beachte auch:
"Der Speicher habe ein Unified Architektur und könne sowohl von der GPU wie auch von der CPU adressiert werden."Wow, das ist dann ja genauso wie bei der XBOX1
Es geht hier nicht um Unified Shader.
PS4 schrieb:
Benschmarks mit OpenCL Berechnungen die viele Daten zwischen GPU und CPU austauschen müssen wären wesentlich aussagekräftiger.
Da würde der PC gegen die PS4 abkacken.Der Clou bei den OpenCL ist doch, dass man der GPU die Daten in ihrem eigenen Speicher bereitstellt und OpenGL diese anschliessend direkt weiterverarbeiten kann.
Der Datenaustausch wird also gerade vermieden.Das ist kein Clou, sondern ein Bottleneck, der GPU Computing bei vielen Anwendungsfällen verhindert, weil es sich wegen den Latenzen nicht lohnt und die CPU alleine dann schneller ist.
-
hellihjb schrieb:
Die Playstation 4 bringt Intel doch bezüglich der Gaming PCs in Zugzwang.
Denn dort, auf der PS4 stört kein lahmer Bus zwischen CPU und GPU.Seit wann hat Intel denn irgendwelche Relevanz bei ernsthaften GPUs?
Ach ich denke das dauert nimmer lange bis es so weit ist.
Und für Compute-Anwendungen denke ich könnte man auch aktuelle Intel GPUs schon ziemlich gut verwenden -- speziell wenn es mal entsprechenden Treiber-/API-Support für Shared Memory gibt.
-
PS4 schrieb:
Verkauft Intel mehr CPUs, wenn die PS4 bei Gamern sehr beliebt ist?
Die Tatsache dass eine AMD-Loesung verbaut wird heisst ja auch, dass Intel nichts Vergleichbares (Preis und Performance) anbieten konnte.
Und wenn jemand eine Konsole hat, verzichtet er ja deswegen nicht auf einen PC.
Dafuer aber wahrscheinlich auf eine dicke Grafikkarte.PS4 schrieb:
Es geht hier nicht um Unified Shader.
...sondern um UMA, ich weiss.
PS4 schrieb:
Das ist kein Clou, sondern ein Bottleneck, der GPU Computing bei vielen Anwendungsfällen verhindert, weil es sich wegen den Latenzen nicht lohnt und die CPU alleine dann schneller ist.
Die CPU ist in fuer gewohnlich dann schneller wenn sich ein Algorithmus nicht sinnvoll parallelisieren laesst. Daran aendert ein schnellerer Datenbus dann aber auch nichts.
Ich nehme an, dass Du keine eigenen Erfahrungen hast, wo Dich der Busdurchsatz konkret behindert hat?hustbaer schrieb:
Und für Compute-Anwendungen denke ich könnte man auch aktuelle Intel GPUs schon ziemlich gut verwenden
Naja, ich sehe diese Onboard-Loesungen eher im Office-Markt, wenn man keine grossen Anforderungen hat kann man sich die Grafikkarte sparen und es geht trotzdem alles.
Keine Frage, dass das auch ein sinnvoller Ansatz ist...
-
hellihjb schrieb:
PS4 schrieb:
Verkauft Intel mehr CPUs, wenn die PS4 bei Gamern sehr beliebt ist?
Die Tatsache dass eine AMD-Loesung verbaut wird heisst ja auch, dass Intel nichts Vergleichbares (Preis und Performance) anbieten konnte.
Und wenn jemand eine Konsole hat, verzichtet er ja deswegen nicht auf einen PC.
Dafuer aber wahrscheinlich auf eine dicke Grafikkarte.Entweder hast du den Kern meiner Frage nicht verstanden oder du weichst der Frage aus.
Und ja, man verzichtet auf einen neuen PC, wenn die Konsole zum Spielen reicht. Alte PCs hilft Intel gar nicht wenn die neue CPUs verkaufen wollen.
PS4 schrieb:
Das ist kein Clou, sondern ein Bottleneck, der GPU Computing bei vielen Anwendungsfällen verhindert, weil es sich wegen den Latenzen nicht lohnt und die CPU alleine dann schneller ist.
Die CPU ist in fuer gewohnlich dann schneller wenn sich ein Algorithmus nicht sinnvoll parallelisieren laesst. Daran aendert ein schnellerer Datenbus dann aber auch nichts.
Ich nehme an, dass Du keine eigenen Erfahrungen hast, wo Dich der Busdurchsatz konkret behindert hat?Es geht nicht nur um Parallelisierung.
Es gibt auch Fälle, wo man auf die CPU kurz zurückgreifen muss (eben weil das parallelisieren nur eingeschränkt möglich ist), aber man dann gleich auf die iGPU wieder zugreifen können möchte, weil nach der CPU ein kleiner Datensatz wieder vorliegt, der parallel auf der iGPU schneller abgearbeitet werden könnte, wenn die Anbindung nicht so grottig wäre.Also ändert ein schneller Datenbus mit geringer Latenz sehr wohl was.
Dazu habe ich oben eigentlich schon sehr viel geschrieben (physik und so), schade das du das bisher noch nicht verstanden hast.Insofern ist deine Annahme falsch und zeigt eher, das du keine Vorstellung davon hast, was eine kurze Anbindung bringen würde.
hustbaer schrieb:
Und für Compute-Anwendungen denke ich könnte man auch aktuelle Intel GPUs schon ziemlich gut verwenden
Naja, ich sehe diese Onboard-Loesungen eher im Office-Markt, wenn man keine grossen Anforderungen hat kann man sich die Grafikkarte sparen und es geht trotzdem alles.
Und genau das siehst du falsch.
Du denkst in alten Mustern.
Also CPU macht die Hauptarbeit und die GPU kümmert sich um die Grafik.
Wenn aber Physik ins Spiel kommen soll, dann ist die iGPU auf der CPU mit einer kurzen ANbindung und geringen Latenz die Zukunft.Denn in solchen Fällen brauchst du beide Recheneinheiten CPU und iGPU gleichermaßen um eine Aufgabe zu berechnen und da gewinnt dann eine schnelle Anbindung on Die gegenüber der nur in der Theorie potenteren dedizierten Grafikkarte.
Denn letzteres hat den PCIe Bus ann als Bottleneck, also langsamer, trotz viel Rohpower auf der dedizierten GPU, die dann aber nicht genutzt werden kann.
-
Noch etwas:
Gerade weil die Latenz und Busanbindung zwischen dedizierter GPU und CPU so grottig ist, muss man bei OpenCL, Cuda und Co ja genau so programmieren,
dass die CPU zuerst einen großen Datensatz vorbereitet und an die dedizierte GPU schicken kann, den die GPU dann runterarbeitet.Wenn der Datendatz aber zu klein ist und wieder die CPU in Folge dran sein muss, um den nächsten kleinen Datensatz zu gewinnen, dann gewinnt die CPU only Lösung.
Und das ist das Hauptproblem bei dedizierten GPU + CPU Lösungen.Wie es also momentan gemacht wird, ist nur ein Ist-Zustand aufgrund mangelnder Hardware.
-
Kannste ma aufhören uns hier irgendwelche Trivialitäten um die Ohren zu hauen? Jeder weiss das man mit nem schnelleren Bus eher auf Arbeit ist. Es nervt ...
-
Ich will es nochmal von einem anderen Standpunkt aus versuchen:
PS4 schrieb:
Du denkst in alten Mustern.
Da hast Du Recht!
Als Software-Entwickler findet man es ja voellig normal, dass es an verschiedenen Stellen einen Datenbus gibt, sei es zwischen Festplatte und Ram, Ram und Cache, etc.
Dadurch bieten sich bestimmte Vorgehensweisen zur Problemloesung an.
Bzgl OpenCL naemlich:
- alles auf der CPU machen
- alles auf der GPU machen
- GPU und CPU mischen aber Traffic so gering wie moeglich haltenDaran hat man sich als Entwickler gewoehnt und weiss wie man bestehenden Code daraufhin anpassen muss um ihn performant zu machen.
Jetzt ist also der Datenbus breiter geworden, das ist schoen denn mehr ist immer gut.
Es gibt sicher einige Anwendungen wo man das gut brauchen kann.Muss man jetzt seinen gesamten Code daraufhin anpassen weil man darauf schon immer gewartet hat und dadurch alles sehr viel schneller wird?
Ich denke nicht.Muss Intel jetzt dicht machen?
Ich denke nicht.
-
hellihjb schrieb:
PS4 schrieb:
Das ist kein Clou, sondern ein Bottleneck, der GPU Computing bei vielen Anwendungsfällen verhindert, weil es sich wegen den Latenzen nicht lohnt und die CPU alleine dann schneller ist.
Die CPU ist in fuer gewohnlich dann schneller wenn sich ein Algorithmus nicht sinnvoll parallelisieren laesst. Daran aendert ein schnellerer Datenbus dann aber auch nichts.
Ich nehme an, dass Du keine eigenen Erfahrungen hast, wo Dich der Busdurchsatz konkret behindert hat?Ich schon. Und mehrfach. Gibt einfach Anwendungen, wo man hier und da viele Millisekunden rauskratzen könnte wenn man eine Unteraufgabe eines hauptsächlich CPU-lastigen Algorithmus mal schnell auf der GPU rechnen könnte, während die CPU was anderes macht, und danach wieder mit CPU weiter. Beispielsweise hab ich an einem Kompressionsalgorithmus gearbeitet, der sich teils überhaupt nicht, teils sehr gut parallelisieren lies. Wenn ich da ein paar Sektionen einfach auf der GPU, oder auf einer halbstarken CPU-integrierten GPU hätte laufen lassen können, hätte ich mir ~2 Monate Arbeitszeit gespart.
Für diese Sektionen hätte ich natürlich größere Datenmengen auf die GPU schaufeln müssen. Bei einem shared-memory Ansatz wäre das halt nicht nötig. Freilich ist das nur Wunschdenken, schließlich gibt es einen Grund warum die GPU so weit weg ist und nicht einfach als kleiner Chip neben der CPU. Es sind halt große, kräftige Teile die eigene Lüftung, eigenen Strom, usw. benötigen. Das heisst aber natürlich nicht, dass es da nicht viel Verbesserungsraum gibt.
Der Traum wäre natürlich eine Recheneinheit auf dem Mainboard, das Größenmäßig mehr Platz einnimmt als ne heutige CPU, dafür aber größere Vektor-Rechenwerke wie eine momentane GPU hat, so dass man als Anwender nur noch die passende Instruktion aufrufen muss, und wie das ganze am schnellsten passiert weiss dann die CPU. Im Prinzip siehts mit iGPUs im Moment schon ähnlich aus, aber sie sind halt einfach noch zu schwach.
-
[quote="hellihjb"]
PS4 schrieb:
Du denkst in alten Mustern.
Da hast Du Recht!
Als Software-Entwickler findet man es ja voellig normal, dass es an verschiedenen Stellen einen Datenbus gibt, sei es zwischen Festplatte und Ram, Ram und Cache, etc.
Dadurch bieten sich bestimmte Vorgehensweisen zur Problemloesung an.
Bzgl OpenCL naemlich:
- alles auf der CPU machen
- alles auf der GPU machen
- GPU und CPU mischen aber Traffic so gering wie moeglich haltenDaran hat man sich als Entwickler gewoehnt und weiss wie man bestehenden Code daraufhin anpassen muss um ihn performant zu machen.
Jetzt ist also der Datenbus breiter geworden, das ist schoen denn mehr ist immer gut.
Es gibt sicher einige Anwendungen wo man das gut brauchen kann.
[QUOTE]Ja, deine dritte Vorgehensweise:
- GPU und CPU mischen aber Traffic so gering wie moeglich halten
Nun muss man den Traffic nicht mehr so gering wie möglich halten, weil der, wenn die iGPUs+CPU so sind wie in der PS4, kaum noch was kostet.
Also gibt's ein weiteres Einsatzfeld:
- GPU und CPU mischen, Traffic ist kein Bottleneck mher.Muss man jetzt seinen gesamten Code daraufhin anpassen weil man darauf schon immer gewartet hat und dadurch alles sehr viel schneller wird?
Ich denke nicht.Habe ich auch nicht gefordert.
Muss Intel jetzt dicht machen?
Ich denke nicht.Spieleentwickler werden dies nun endlich für gameplayrelevante Physik verwenden können und dies auf der PS4 dann auch nutzen.
Vom Gameplay zieht die PS4 den Intel PCs also davon, wenn Intel nicht nachrückt.
Und das der PC keine homogene Plattform ist und alte CPUs auch noch unterstützt werden, wird erst Recht den Spielspaß gegenüber der PS4 ins Hintertreffen bringen.
Denn von ner hübschen Grafik allein, kann ein Computerspieler nicht leben, wenn es Spiele gibt, in der die Physik als Handlungseingreifende Bestandteil und nicht nur Beiwerk zur Verschönerung von ihm wind wehenden Haaren und Kleidern ein tragender Pfeiler geworden ist.@ScottZhang
Wenn dir der Thread nicht paßt, dann hau halt ab.
Nichts ist nerverender als Mimimis die sich in Threads aufhalten, die sie nicht interessiert und dann uns hier was vorheulen.
-
TravisG schrieb:
Für diese Sektionen hätte ich natürlich größere Datenmengen auf die GPU schaufeln müssen. Bei einem shared-memory Ansatz wäre das halt nicht nötig. Freilich ist das nur Wunschdenken, schließlich gibt es einen Grund warum die GPU so weit weg ist und nicht einfach als kleiner Chip neben der CPU. Es sind halt große, kräftige Teile die eigene Lüftung, eigenen Strom, usw. benötigen.
Es gibt ja auch gute Gruende fuer separate Speicher.
Wenn neben der GPU noch 4-8 CPU-Cores auf dem gleichen Speicher rumroedeln hat jede Seite eben nur noch einen Bruchteil des Speicherdurchsatzes.
Hatte selber schon mehrmals den Fall wo Parallelisierung (auf CPU-Seite) eben gar nichts gebracht hat, weil der Speicherdurchsatz nicht mehr hergegeben hat.
Und unterschiedliche Rechenwerke sinnvoll auszulasten ist ja auch nicht einfach mal so gemacht.PS4 schrieb:
Spieleentwickler werden dies nun endlich für gameplayrelevante Physik verwenden können.
Vom Gameplay zieht die PS4 den Intel PCs also davon, wenn Intel nicht nachrückt.Deine Beitraege lesen sich echt wie die Schlagzeilen der Bildzeitung
-
hellihjb schrieb:
PS4 schrieb:
Es geht hier nicht um Unified Shader.
...sondern um UMA, ich weiss.
Nein, auch nicht.
Schau dir mal diese Grafik über die AMD Roadmap an.
Hier insbesondere den Kaveri, der entspricht in etwa dem, was in die PS4 reinkommt:Die UMA gab's schon im Liano, ist aber nicht das, was die PS4 und Kaverie bietet.
Dazu auch etwas Text:
But AMD didn't only beef up the x86 CPU cores but also the architectural features of their APU. As AMD publicized before, Kaveri will be the first APU which allows coherent memory access for the GPU part of the chip. To this end the communication facilities between x86 CPU cores and GPU cores have been extended considerably. The width of the internal interface called Onion which connects the GPU to the coherent request queues has been widened to 256-bit in each direction. This allows for faster data exchange between the CPU and GPU, clearly a requirement of the HSA.
Die PS4 und Kaverie sind also beide diesbezüglich ein geiles Teil und was bietet hier Intel?
@TravisG
Kaverie geht in die Richtung das zu bieten, was du dir gerne wünschst.
Klar, die GPU Einheiten dürften als iGPU etwas schwächer sein, aber die Kommunikation zwischen iGPU und CPU ist superschnell.
-
PS4 schrieb:
hustbaer schrieb:
Intel hat zwar auch die GPU auf das Die der CPU gebracht, aber die Kommunikation zwischen GPU und CPU ist für so etwas, was die PS4 kann, nicht vorgesehen.
Wie kommst du denn auf die Idee?
Kannst du von der iGPU und CPU auf den gleichen Speicher zugreifen?
ja, das geht, intel hat sogar vor AMD beides ueber denselben cache/controller geleitet.
Also auch dann, wenn der Speicher für eines der beiden reserviert ist?
in welcher form reserviert? es gibt hardware maessig nur einen speicher und einen memory controller.
Kannst du die iGPU z.B. für OpenCL nutzen, während im Rechner eine normale GPU steckt?
wenn es dir dein betriebssystem erlaubt, kannst du das machen.
-
PS4 schrieb:
Man beachte auch:
Zudem könnten die GPGPU-Berechnungen simultan zu den Grafikberechnungen ausgeführt werden, was auf PCs derzeit nicht möglich sei.
Der 8 GByte GDDR5-Speicher habe ein Unified Architektur und könne sowohl von der GPU wie auch von der CPU adressiert werden. Über sein 256-Bit-Interface kommt er auf eine Bandbreite von 176 GByte/s. Die hohe Rechenleitung ermögliche mehr interaktive und Bewegliche Objekte in der Spielumgebung. Die Darstellung von Rauch, Wasser, Explosionen und Feuer würden ebenso profitieren wie das Rendering von Haaren, Kleidung und Haut.
http://www.heise.de/ct/artikel/GDC-Was-Entwickler-und-User-bei-der-Playstion-4-erwartet-1831997.html
Zum Vergleich, die Bandbreite von PCIe 3.0 liegt bei 32 Lanes (Maximalausbau!)
bei nur 30,77 GB/s, also 5,7 mal weniger. Dass schadet, sobald man vom Hauptspeicher Daten an den Speicher der GPU schicken will.oben sprichst du von latenz, hier jetzt von bandbreite. finde einigkeit in dir selbst, junger padawan.
Und gerade das ist notwendig, wenn die Physik teil des Gameplays und nicht nur verschönerndes Beiwerk werden soll.
Da müssen die Daten nämlich wieder zurück zur CPU.ist nicht notwendig, es waere kompletter unsinn die meshes von der graphikkarte wieder zurueck zur CPU zu schieben, genau so unsinnig wie es waere diese jedes frame wieder zur GPU zu schicken. nach dem prinzip wuerde man heute auch beim rendern die GPUs nie ausnutzen koennen
macht man so nicht.Mit dedizierten GPUs ist das wegen PCIe sau teuer und mit aktuellen iGPUs nur geringfügig günstiger, weil der Speicher nicht geteilt wird.
Man also Daten kopieren muss.die daten dafuer sind position+rotation, das sind 24byte, bei deinen 30GB/s sind das also ca 1Milliarde objekte/s. pro frame bei 30hz also noch 30Millionen objekte/s. diese menge an objekten bekommst du, selbst wenn du sie simulieren kannst, nicht gerendert sofern es nicht primitive boxen sind, weil du drawcall limitiert bist.
rechne mit 10k dynamischen objekten -> 240kbyte/frame -> 10MB/s an daten pro richtung ueber PCIe.
-
hustbaer schrieb:
Das können die Intel-Dinger im Moment nicht. Würde mich aber auch wundern wenn das eine Hardware-Limitierung wäre. D.h. es müsste sich mMn. mit einem BIOS-/Treiber-Update machen lassen.
sollte unter linux eigentlich gehen, hab ich aber nicht selbst probiert
