Günstiger Datentransport zwischen CPU und GPU bald auch mit Intel?
-
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
-
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.
