Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
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
-
PS4 schrieb:
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.
intel verkauft mehr CPUs pro jahr und hat mehr umsatz, als alle konsolen einer generation zusammen, also nein, die konsolen haben wenig einfluss auf die verkaeufe von intels CPUs, sogar bei AMD werden alle konsolen deals <10% des umsatzes ausmachen. tablets, smart phones, smart TVs sind viel wichtiger als konsolen hardware.
Auch fuer die konsolen hersteller sind die konsolen an sich unwichtig, es geht um die spiele, dienste und digitale inhalte womit sie geld verdienen.also nein, rasierer werden nicht dafuer sorgen dass der rasenmaeher umsatz grossartig schwankt.
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.
das sind die leute die schon wegen PS3, PS2, PSX keinen pc gekauft haben. im gegensatz zu jetzt, haben frueher konsolen wenigstens sugeriert mehr zu offerieren als der PC vermag. z.b. gab es die PSX 1994 mit der du 'richtige' 3d spiele spielen konntest, die erste ernstzunehmende graka, mit der 'voodoo graphics' von 3dfx kam erst 1996. "reality synthesizer" von der PS2 wurde auch mit wundern beworben die keine HW kann und "CELL" und "RSX" waren auch mit 2TFlops angepriesen (lustigerweise jenseits der PS4 leistung) die kein PC leisten konnte.
diese generation, naja, da gibt jeder offen zu dass sie schon schwach ist bevor sie raus ist, vielleicht wird ja der Haswell von intel mit der integrierten GPU schon bald dasselbe liefern was die PS4.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.ich glaube da gehen deine annahmen auf ein sehr primitives software model zurueck. eine cpu die dinge an die gpu uebergibt und auf das resultat wartet, dann eine gpu die fertig ist und die daten der cpu uebergibt und dann vermutlich auch wartet? das ist dermassen unsinnig, da waere es viel viel viel effizienter einfach viel mehr CPU kerne zu verbauen und sie alle immer voll auszulasten.
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.
latenz ist nicht sonderlich wichtig, da, wie ich gerade schrieb, es dumm waere bei heterogeneous computing latenz abhaengig zu werden, du erstellst eher alles so, dass es wie eine pipeline arbeitet. das heisst, die GPU arbeitet kontinuierlich, wenn ein teil der arbeit fertig ist, wird am naechsten teil der arbeit weitergearbeitet, die cpu hat dann locker zeit waehrenddessen die daten per PCIe zu kopieren, auszuwerten udn anhand dessen dann ueber neue tasks der GPU zu entscheiden.
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.wie in vielen benchmarks zu sehen, ist es bei sowas schneller die CPU alles bearbeiten zu lassen, statt micro-tasks hin und her zu schieben. natuerlich versucht AMD etwas anderes zu suggerieren, aber es gibt einige benchmarks im netz, die zeigen dass selbst OpenCL auf den CPU cores dann schneller sind als auf den intel oder amd GPUs.
es gibt dinge da sind GPUs gut, wie z.b. riesige matritzen zu verrechnen, das sind sehr zeitraubende und wichtige dinge in der wissenschaft z.b. bei der wettervorhersage oder SPH berechnungen, aber das sind auch spezielle dinge die oft speicher limitiert sind und nicht auf generelle tasks projezierbar sind.
-
rapso schrieb:
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
Hardwaremässig muss es irgendwie gehen. Virtu MVP kann ja auch auf beide GPUs zugreifen.
Dass die iGPU unter Windows mit OpenCL/DirectCompute/... nutzbar ist also bloss eine Frage der Zeit -- vorausgesetzt es gibt genug Nachfrage.
-
TravisG schrieb:
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.
kannst du die unteraufgaben nicht genau so gut an andere cpu kerne verteilen? statt also 4cpu kerne + iGPU, dann 8CPU kerne? wuerden dadurch nicht sogar viel mehr teile deiner software mit viel weniger aufwand schneller laufen? keine doppelte implementierung+optimierung, besseres balanzing verschiedener cpus etc. ?
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.
die naehren sich auch daraus dass du wenig, dafuer teuren und spezialisierten speicher hast. 1GB GDDR5 kann dich soviel kosten die 16GB DDR3 fuer die CPU, bei 10x des verbrauchs.
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.
naja, Haswell kommt ja, mit AVX2, AVX an sich soll bis 1024bit geplant seint -> 32floats, dabei wird haswell mit 15kernen zu haben sein. soviel anders als GPUs ist das dann nicht. kepler GK110 hat 15kerne mit scheinbar 16float breiten registern die jedoch zweimal dieselbe instruktion ausfuehren.
Am ende kommen beide seiten irgendwie auf dasselbe, was architektur angeht, weil es einfach durch benchmarks usw. diktiert wird was das effizienteste ist.
-
hustbaer schrieb:
rapso schrieb:
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
Hardwaremässig muss es irgendwie gehen. Virtu MVP kann ja auch auf beide GPUs zugreifen.
Dass die iGPU unter Windows mit OpenCL/DirectCompute/... nutzbar ist also bloss eine Frage der Zeit -- vorausgesetzt es gibt genug Nachfrage.
ab Win8 war es geplant, weiss nicht ob der support dafuer am ende reinkam.
-
@rapso
Nochwas zum Thema Latenz: ist die Latenz die durch das Scheduling von GPU Tasks entsteht um so viel grösser als die Latenz durch die Datenübertragung bei über PCIe angebundenen GPUs mit dediziertem Speicher?
In dem Fall wäre das Thema Latenz nämlich wirklich egal.Dann bleibt "nur" noch der Vorteil dass man Updates mit deutlich weniger Overhead machen kann und auch keine Bandbreite durch das Übertragen von Daten verschenkt die die GPU "vielleicht brauchen könnte" aber im Endeffekt dann doch nicht braucht.
(Wobei natürlich noch besser wäre gleich gar keine Daten zu berechnen die die GPU dann doch nicht braucht -- wo ich mir aber vorstellen könnte dass das nicht immer so einfach möglich ist.)
-
Weil's mir gerade einfällt... was ist diesbezüglich eigentlich mit Xeon Phi? Hat irgendwer Erfahrung mit den Teilen?
Und ... mit was kann man die programmieren? Nur über ein spezielles SDK, oder kann man die genau so auch über DirectCompute/OpenCL ansprechen? Bzw. gibt's da nen eigenen Compiler wo man dann "ganz normal" OpenMP machen kann?
-
rapso schrieb:
oben sprichst du von latenz, hier jetzt von bandbreite. finde einigkeit in dir selbst, junger padawan.
Beides trifft zu.
Weil die CPU und GPU auf dem Die deutlich näher zusammenliegen, sinkt die Latenz drastisch, aber weil man auf einem Die mehr Leitungen zwischen CPU und GPU legen kann, steigt auch die realisierbare Bandbreite zwischen CPU und GPU.
Bei PCIe ist die Anzahl der Leitungen aus mechanischen Gründen stark begrenzt.
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.Die CPU kann bestimmte Dinge schneller berechnen als die GPU und man macht es nur heute nicht so, weil es wegen der schlechten Anbindung zu teuer ist.
Architekturen und Vorgehensweisen wie man etwas macht, ändern sich mit steigendem Fortschritt in der Technik.
Das gilt hier auch.
-
hustbaer schrieb:
@rapso
Nochwas zum Thema Latenz: ist die Latenz die durch das Scheduling von GPU Tasks entsteht um so viel grösser als die Latenz durch die Datenübertragung bei über PCIe angebundenen GPUs mit dediziertem Speicher?
In dem Fall wäre das Thema Latenz nämlich wirklich egal.in hardware ist das nicht so teuer, zudem hat jede neue gpu eigentlich mindestens 2 command buffer, sodass die compute einheiten eigentlich ausgelastet werden koennen waehrend ein setup gemacht wird. das meiste an latenz entsteht eher durch die API und das OS. soweit ich weiss ist ein directX compute job in etwa 10mal so teuer wie ein drawcall.
Dann bleibt "nur" noch der Vorteil dass man Updates mit deutlich weniger Overhead machen kann und auch keine Bandbreite durch das Übertragen von Daten verschenkt die die GPU "vielleicht brauchen könnte" aber im Endeffekt dann doch nicht braucht.
(Wobei natürlich noch besser wäre gleich gar keine Daten zu berechnen die die GPU dann doch nicht braucht -- wo ich mir aber vorstellen könnte dass das nicht immer so einfach möglich ist.)ja, lazy evaluation von daten kann sehr einfach und effektiv implementiert werden auf CPU, auf GPU hast du dann einen von 32 oder 64 threads der sich daten vorbereitet und der rest der threads ist idle. du hast dasselbe problem wenn dein algorithmuss unterschiedliche workloads hat (z.b. mandelbrot fraktal), alle threads laufen solange wie der langsammste.
-
hustbaer schrieb:
Nur über ein spezielles SDK, oder kann man die genau so auch über DirectCompute/OpenCL ansprechen?
kannst du ganz normal ueber den intel compiler als build target festlegen. im einfachsten fall laeuft dein code als wuerdest du den auf einem alten pentium starten. OpenCL sollte es geben, war jedenfalls mal gesagt worden, direct compute eher nicht.
Bzw. gibt's da nen eigenen Compiler wo man dann "ganz normal" OpenMP machen kann?
es gibt openMP und intels TBB. dazu supported der compiler auto-vectorizing und automatische parallelisierung, aber mit openMP kann man es schoener tunen.
der intel compiler ist echt krass von dem was er anstellt.am schoensten programmiert man die dinger aber mit den intrinsics, siehe http://software.intel.com/en-us/articles/prototype-primitives-guide (werden auf SSE gemappt damit man damit ohne einen xeon phi arbeiten kann.
gibt uebrigens bald die 'billig version' fuer unter 2k, xeon phi 3100 oder so.
-
PS4 schrieb:
rapso schrieb:
oben sprichst du von latenz, hier jetzt von bandbreite. finde einigkeit in dir selbst, junger padawan.
Beides trifft zu.
Weil die CPU und GPU auf dem Die deutlich näher zusammenliegen, sinkt die Latenz drastisch, aber weil man auf einem Die mehr Leitungen zwischen CPU und GPU legen kann, steigt auch die realisierbare Bandbreite zwischen CPU und GPU.
die latenz fuer einen task haengt hauptsaechlich an der API, nicht der hardware.
programmierst du hingegen ordentlich, hast du mehrere tasks in der pipeline, dann ist es an sich egal wo dieser gestartet wird, die beschreibung des tasks sind ein paar wenige pointer und kein bottleneck.
das kannst du dir wie drawcalls vorstellen, wuerdest du jeden einzeln abschicken und abwarten, wuerdest du nichtmal 10% dessen darstellen koennen was spiele heute zeigen, das funktioniert nur, weil alle drawcalls in einer queue aufgereiht und zeitversetzt von der gpu abgearbeitet werden. bei nvidia karten kannst du das im treiber menue einstellen, wieviel frames im voraus aufgezeichnet werden, das heisst, es gibt quasi tausende 'tasks' die die CPU der gpu voraus ist. das heisst auch, du koenntest die GPU per PCIe 4x betreiben, falls es nur um die job latenz geht.
ergo, latenz ist eigentlich irrelevant.Bei PCIe ist die Anzahl der Leitungen aus mechanischen Gründen stark begrenzt.
es sind eher elektrische gruende, aber es ist auch ein kuenstliches problem darueber zu reden.
die besten CPUs koennen 50GB/s an daten transferieren, die besten GPUs 300GB/s und in beiden faellen waere eine CPU schnell genug all diese daten zu verarbeiten, da CPUs intern in terrabyte bereichen daten verschieben.
wenn du also ein reales problem hast, muss es sehr rechenintensiv sein, nicht daten intensiv, sonst ist es egal ob CPU oder GPU, du wirst auf die daten warten.
wenn du hingegen compute limitiert bist, dann erstellst du die daten zumeist, da du keine 50GB/s per netzwerk oder festspeicher bekommst, in dem fall kannst du die daten doch wohl auf GPU erstellen, wie du es auf CPU machst, falls die PCIe geschwindigkeit das limitierende ist.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.Die CPU kann bestimmte Dinge schneller berechnen als die GPU und man macht es nur heute nicht so, weil es wegen der schlechten Anbindung zu teuer ist.
Architekturen und Vorgehensweisen wie man etwas macht, ändern sich mit steigendem Fortschritt in der Technik.
Das gilt hier auch.es ist auch oft ein marketing fortschritt wie ein problem zu loesen ist, z.b. hypen einige firmen zZ dass heterogenous computing die zukunft ist, weil _manche_ dinge schneller sind, aber die masse der probleme wird dadurch nicht beschleunigt, eher gehindert, denn nun hat jeder prozessor eine GPU die zu allermeist brach liegt oder heizt, platz den man meist effektiver nutzen koennte fuer die gaengigen berechnungen.
