Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
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.
-
am schoensten programmiert man die dinger
Am schoensten waere es mit conditional execution und gleichzeitiges Laden mehrerer Register. Aber das wirds wohl nicht geben.
-
rapso schrieb:
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.Wie schon gesagt, man programmiert heute so!
Heute packt man das zu berechnete in eine Queue und schickt das ab, weil alles andere ineffizient wäre.Aber wenn man anders programmieren kann, auf eine Queue zwecks der Wahl eines z.B. besseren Algorithmus verzichten kann, eine Queue aus mehreren Daten also nicht zustande kommt, sondern kleine Datenhäppchen, die von der GPU zur CPU geschickt werden und wieder zurück, was z.B. bei Physik sinnvoll ist, dann braucht man HW mit einer sehr geringen Latenz zwischen GPU und CPU.
Du denkst hier leider immer noch, nach 3 Seiten Thread, in alten Bahnen.
Du glaubst, man muss Daten erst vorbereiten um das alles in einem Rutsch zur Queue zu schicken und erst dann arbeitet die GPU das ab.Das hier dann auf so manche Algorithmen verzichtet werden muss, und man den Code dann genau so programmiert, das man so ne Queue zusammenbringt, damit man überhaupt in der Lage ist, die gegebene HW effizient zu nutzen, dass übersiehst du leider.
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.
Beides trifft zu.
n Pins müssen auch erstmal verbunden werden und das geht bei Leiterplatten nicht so präzise wie bei einem Die, also ist es auch eine Frage der Mechanik.
Zudem wird so ein Board durch Temperatur und Beigung (anbringung des CPU Lüfters usw.) belastet und da können die kleinen Äderchen schonmal kaputt gehen, deswegen kann man so eine Leitung auch nicht unendlich dünn machen und damit ist die Anzahl der Leitungen mechanisch begrenzt.
-
rapso schrieb:
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.
(...)
Cool
Hast du ne Ahnung wie sich das Ding im Vergleich zu dicken Quadro Karten o.Ä. schlägt?alle threads laufen solange wie der langsammste
Ist das echt immer noch so?
Uiiiiiiii...
-
rapso schrieb:
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. ?
Klar, und das hab ich auch gemacht. Es gibt aber einige Probleme (denke an Algorithmen die fast oder komplett branch-less sind, z.B. Farbtransformationen) wo selbst eine High-End CPU nichtmal annähernd an eine halbwegs aktuelle Grafikkarte hinkommen würde. Wenn es diese hypothetische CPU-GPU geben würde, auf der ich normalen C-Code laufen lassen könnte (der dann höchstens ein paar API funktionen benutzt), wäre der Zeitaufwand bei beiden Versionen der Parallelisierung wahrscheinlich gleich, aber die GPU Version wäre einfach viel schneller, so dass ich mir an anderen Stellen Arbeit spare.
rapso 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. 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.
Jop. Mir ist aber neu dass GDDR5 so viel mehr Strom verbraucht? Interessant.
rapso schrieb:
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.
Jop. Was mich bei dem MMX/SSE/AVX Ansatz von der Anwendung aber ziemlich stört ist dass eine passende Abstraktionsebene fehlt, die komplette Hardwareabhängigkeit zulässt. Wäre schöner, wenn man der CPU sagen könnte "hier sind zwei zusammenhängende Blöcke an Speicher. Addiere so viele davon gleichzeitig wie du kannst, und sag mir dann irgendwo wie viele du addiert hast". Dann würde Code der in 5 Jahren geschrieben wird auch auf meiner aktuellen 256 Bit-AVX CPU laufen. Im Moment muss man sich selbst darum kümmern und mit ifdefs oder sonstigen Mitteln arbeiten, die dann enstprechende alternativen für die verschiedenen CPUs implementieren, oder man muss sich auf APIs von Compiler-Herstellern oder irgendwem anderen verlassen (was ich unschön finde).
Keine Ahnung, vielleicht kommt ja was in der Richtung. Es ist allerdings ziemlich offensichtlich, dass es nicht bei den momentanen Vektorgrößen bleiben wird, also fällt mir gerade wenig ein (abseits Verkaufspolitischer Gründe) das derartiges verhindern sollte.
-
TravisG schrieb:
Jop. Mir ist aber neu dass GDDR5 so viel mehr Strom verbraucht? Interessant.
Schätze mal das wird auf den Takt ankommen, und auf die Spannung mit der man drauffahren muss um diesen Takt hinzubekommen.
Auf vielen der dickeren Grafikkarten sind die RAMs aktiv gekühlt - bei DDR3 Hauptspeicher hätte ich das noch nie gesehen.
-
TravisG schrieb:
Jop. Was mich bei dem MMX/SSE/AVX Ansatz von der Anwendung aber ziemlich stört ist dass eine passende Abstraktionsebene fehlt
C++ arbeitet ja dran, zumindest den Source-Code unabhängig zu bekommen.
