Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
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.
-
PS4 schrieb:
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,
das waere unsinnig, und da du hier auf die PS4 ansprichst, auch da waere es unsinning, ein interesanter artikel der das nochmal verdeutlicht, dass die PS4 mehr asynchron gemacht wurde als standard GPUs
http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php?page=2 schrieb:
"The original AMD GCN architecture allowed for one source of graphics commands, and two sources of compute commands. For PS4, we’ve worked with AMD to increase the limit to 64 sources of compute commands -- the idea is if you have some asynchronous compute you want to perform, you put commands in one of these 64 queues, and then there are multiple levels of arbitration in the hardware to determine what runs, how it runs, and when it runs, alongside the graphics that's in the system."
also wenn sogar die von dir angeprisene PS4 asynchronitaet ausbaut, statt zu reduzieren wie du als argument gegen intel GPUs bringst, klingt deine argumentationskette ziemlich gebrochen, sorry.
was z.B. bei Physik sinnvoll ist, dann braucht man HW mit einer sehr geringen Latenz zwischen GPU und CPU.
physic laeuft normalerweise asynchron zum rest, das ist schon so seitdem es multi-core cpus gibt. game code ist normalerweise daran angespasst, sprich, die logik macht raycast queries zur physic und einige zeit spaeter steht das resultat bereit, das gilt auch so fuer rigid body physics, fuer fluids, sogar sound laeuft asynchron.
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.
das sind nicht die alten bahnen, das sind die die NVidia, AMD und sony bei der PS4 propagieren. so funktioniert heterogenous computing nunmal, wenn du es synchron ausfuehrst, wuerdest du ansonsten zuviel leistung verlieren, da immer eine unit arbeiten wuerde und der rest der units brach laegen. das ist echt nicht sinnvoll.
-
hustbaer schrieb:
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?kommt ganz drauf an wie du es programmierst und welches problem du darauf ausfuehrst, matrix*matrix ist auf GPUs etwas schneller (also eine titan ist etwas fixer als ein xeon-phi),wenn du hingegen aufwendige algorithmen hast z.b. gerade sowas wo du durch eigenes managen von 'jobs' was rausholen kannst, kannst du auf xeon-phi um einiges schneller sein.
kostet leider immer viel zeit sowas zu evaluieren, ich habe keine xeon-phi, hab lediglich einen virtuellen Larrabee gehabt mit profiling infos. (quasi software die auf einem extra PC laeuft und x-mal langsammer ist, aber dir dann die theoretischen timmings auf einige % genau ausgibt, natuerlich kann sie nicht 100% den speicher simulieren usw, da man es dann auf elektronischer ebene simulieren muesste).alle threads laufen solange wie der langsammste
Ist das echt immer noch so?
Uiiiiiiii...naja, pro warp/wavefront ist das so, wenn alle threads einer warp/wavefront durch sind, werden sie suspended, aber der 'threadblock'(im cuda slang) laeuft weiter und hat die SM(X) bzw CU reserviert bis er ganz durch ist. du brauchst leider einige warps/wavefronts um eine SM(X)/CU auszulasten, mit nur einer wirst du gegenueber 2 warp/wavefronts wohl kaum einen unterschied sehen was laufzeit betrifft.
deswegen sagte ich oben, dass es sehr vom task abhaengt wie schnell GPU vs Xeon phi ist, beim xeon phi verteilst du die berechnungen selbst auf die vector units. wenn du z.b. einen madelbrot laufen laesst, kannst du per 'lane' von der vector unit dir einen pixel bezorgen und bei jedem durchlauf einen neuen. du kannst auch mit dem x86 teil die verteilung managen und die vector units arbeiten einfach ab was du zuteilst. sowas kann man bei GPUs auch emulieren, nennt sich dann 'persitent threads', aber du kannst dadurch auch viel performance verlieren, da du dann quasi das thread-management der hardware aushebelst.
wenn du also sowas wie mandelbrot hast und im schnitt 50% der warps brach liegen, kommst du auf ca 2.2x performance mit persistant threads auf einer SM(X) (2.2 weil thread starten und schlafen legen bei so kurzen iterationen wohl viel mehr kostet als der atomic-inc um pro thread einen neuen pixel zu holen). wenn du allerdings zuwenig echt-threads laufen laesst, weil du sie ja emulierst, muss das nur jemand auf einer neueren GPU starten und ploetzlich liegen dort die meisten einheiten brach.
-
TravisG schrieb:
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.
ja, RGB->YCbCr ist langsam, laut intel bei deren IPP sind es 40% vom MPeg4 codec, allerdings bist du dort wohl ziemlich speicher limitiert, nicht so sehr compute. GPUs sind da schneller, weil der speicher schneller angebunden ist und speichertransformationen netter sind (gibt ja texture fetches usw). allerdings ist das nicht wirklich ein vorteil der heterogenen architektur denke ich, denn mit PowerPC (bzw Altivec um genau zu sein) und mit MIPS (VPR3 vector einheit der PSP) hast du pixel support, konvertierungen von z.b. R5G6B5 zu R8G8B8A8 sind eine instruktion, im optimalfall koenntest du dann mit SIMD ein R8G8B8A8 laden, 3 uint8-dot3 machen (so wie dot bei floats funktioniert) und dann ein YCbCrA rausschreiben oder in 3 seperaten planes. damit solltest du nur bandbreiten limitiert sein.
oder gibt es da etwas, was die GPU kann was die CPU nicht koennte fuer die farbkonvertierung?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.
war mir auch unbekannt bis ich vor kurzem einen intel typen fragte weshalb die das nicht wenigstens bei ultrabooks verbauen, aber liegt wohl an den ganzen zusatzchips. FullyBuffered DRam den man damals fuer Xeons brauchte hatte auch 9W verbrauch gegenueber gleich schnellem DDR3 mit 1W. aber ich bin da kein experte, nur was 'gehoert' habe.
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.
x264asm soll wohl sowas koennen. AVX ist eigentlich auch so ausgelegt (da arbeitet man ja zZ mit 2mal 128Bit und nicht mit 1mal 256Bit (bis auf speziaelle permutationsbefehle) und die breite ist wohl im op-code festgelegt. Allerdings hast du recht, sowas wie
rep vadd ...waere eigentlich zukunftssicherer.
-
hustbaer schrieb:
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?bin zufaellig drauf gestossen und musste an deine frage denken:
http://software.intel.com/en-us/articles/how-to-use-opencl-with-intel-vtune-amplifier-xe-2013-on-a-xeon-phi-coprocessor
http://software.intel.com/en-us/articles/opencl-design-and-programming-guide-for-the-intel-xeon-phi-coprocessor
