Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
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
-
PS4 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.
Zumindest war es das AFAIK noch nicht beim Sandy Bridge."Cache is shared across all 4 cores and processor graphics"
http://download.intel.com/newsroom/kits/core/3rdgen/pdfs/3rd_Generation_Intel_Core_Product_Information.pdf
Der Controller ist dahinter, daraus kannst du entnehmen, dass die Adressierung so ist, wie es AMD bald haben will: http://www.heise.de/newsticker/meldung/AMDs-Unified-Memory-Mehr-Performance-und-Energieeffizienz-fuer-Kaveri-und-Co-1850975.htmlAFAIK ist es auch so, dass die GPU abgeschaltet wird, sobald eine normale Grafikkarte im Rechner steckt.
AFAIK macht das nur Windows 7, in Windows 8 geht das problemlos: http://software.intel.com/en-us/forums/topic/387496
-
ohjee schrieb:
AFAIK ist es auch so, dass die GPU abgeschaltet wird, sobald eine normale Grafikkarte im Rechner steckt.
AFAIK macht das nur Windows 7, in Windows 8 geht das problemlos: http://software.intel.com/en-us/forums/topic/387496
Also was definitiv geht (weil ich es so betreibe), ist unter Windows 7 die Intel iGPU plus ne normale Grafikkarte gleichzeitig zu betreiben. Zur Grafikausgabe.
Die iGPU scheint aber irgendwie abgedreht/ignoriert zu werden wenn beim Booten kein Monitor an der iGPU angesteckt war, denn bevor ich nen Monitor am internen Anschluss angeschlossen hatte war das Gerät in Windows einfach nicht da.
Kann aber sein dass es geht wenn man im BIOS was umstellt. Keine Ahnung.
-
steht da scheinbar auch im forum
moozoo Thu, 04/25/2013 - 20:19 schrieb:
Windows 8 has WDDM 1.2 (Windows Display Driver Model).
In the Windows driver stack, OpenGL,OpenCL and DirectX sit on top of the WDDM driver.
My understanding is that its WDDM 1.2 that supports the graphics hardware being active without a monitor attached.
-
Sehr ihr, ich hatte Recht, wie folgender neue Artikel aufzeigt.
http://<snip>*
* Der Link wurde von mir Vorsorglich gelöscht, da Beiträge hier sowieso gelöscht werden und sich der Mod nicht einmal dafür entschuldigt.
-
PS4 schrieb:
Sehr ihr, ich hatte Recht, wie folgender neue Artikel aufzeigt.
ohjee hat deine beiden Kernargumente widerlegt.
http://<snip>*
* Der Link wurde von mir Vorsorglich gelöscht, da Beiträge hier sowieso gelöscht werden und sich der Mod nicht einmal dafür entschuldigt.Ich frage mich immer wozu ihr Trolle das trotzdem weiter macht :(, mir perönlich wäre es zu peinlich mich so zu verhalten.
