Ich habe das hier gelesen: http://de.wikipedia.org/wiki/Accelerated_Processing_Unit Nach dem Lesen frage ich mich, wie das konkret abläuft, wenn die GPU der CPU Arbeit abnimmt. Ich stelle es mir so vor: Eine bestimmte Software auf einem Betriebssystem wie Windows oder Linux wird so eingestellt, dass sie zum Einen mehrere CUP-Kerne nutzten kann und zum Anderen Spezialaufgaben, für die die GPU der beste Rechenknecht ist, an die GPU übergibt. Ist das in der Realität so? Oder wird eine solche Arbeitsverteilung auf der Ebene des Betriebssystems gemacht und die Software bemerkt das gar nicht? Kann mir jemand einen typischen Fall beschreiben, wo die GPU Arbeiten erledigt, für die sie besser geeignet ist als die CPU, und wie genau die Verteilung der Arbeitspakete abläuft, also z.B. auf welcher Ebene in der ganzen Software bestehend aus Betriebssystem und Anwendungssoftware? Was passiert, wenn die GPU durch ein Spiel mit anspruchsvoller Graphik schon genug zu tun hat und dann ein Programm Arbeitspakete hat, für die die GPU besser geeignet ist als die CPU?
Na das muss von den Entwicklern schon so programmiert sein. Z.B. per DirectX oder Mantle oder OpenCL. Damit lassen sich Funktionen bei denen es sinnvoll ist, auf die GPU auslagern. Von alleine nutzt das OS höchstens für sowas wie Windows Aero.
Rolf R. schrieb: > Nach dem Lesen frage ich mich, wie das konkret abläuft, wenn die GPU der > CPU Arbeit abnimmt. Na so wie bisher auch. Nur das man früher die GPU in Form einer Grafikkarte im PC hatte und sie jetzt in den Hauptprozessor integriert ist. Angesprochen wird das Ganze über CUDA, OpenCL oder ähnliche Schnittstellen.
Sowas wird in OpenCL geschrieben. Dabei läuft auf der Mutter CPU ein Programm dass einzelne Funktionen an sogenannte Compute Devices übergeben kann. Das kann eine GPU, eine CPU, ein DSP, oder etwas ganz anderes sein. Dabei kann der Programmier nach mehreren Kriterien Festlegen welches Gerät ausgewählt wird, vom OS kommt meistens nur die info was vorhanden ist. Wenn gleichzeitig gespielt werden soll laggts halt, (und zwar ganz gewaltig) da GPUs (bei den neuesten bin ich mir nicht ganz sicher) kein Multithreading unterstützen und es dann solange kein neues Bild gibt bis die aktuelle Funktion fertig gerechnet hat(oder der ati treiber nach 3 sec denkt die Gpu ist abgestürzt und einen Reset macht) Typischer Anwendungsfall in diesem Board: Die Matlab FFT kann auf der GPU gerechnet werden.
Eine APU ist nicht nur eine GPU neben der CPU auf einem Chip, mit der neusten Entwicklungsstufen, ermöglichte AMD beiden Einheiten den Zugriff auf den selben logischen Speicher (Also müssen die Daten nicht erst vom "CPU-Speicher" in dem "Grafikspeicher" kopiert werden). Das ganze wird von AMD unter HSA (Heterogeneous System Architecture) Zusammengefasst und erlaubt den schnellen wechsel des Programms von GPU zu CPU und umgekehrt. Dadurch hat man den Vorteil gegenüber den üblichen GPGPU Berechnungen, bei denen die Daten erst von einem Addressbereich des RAMs in einen anderen Kopiert werden oder sogar über den PCIe-Bus geschickt werden mussten. Voraussetzung damit das alles genutzt wird ist allerdings die Software und hier sieht es leider noch mau aus. Die neuste OpenGL-Version müsste das Konstrukt theoretisch unterstützen, wird aber noch nicht verwendet, JAVA 7 wird mit HSA-Support 2015 erwartet, ... Aktuell gibt es ein ein paar Techdemos, wie eine beschleunigte Libreoffice Calc Simulation/Berechnung (5x so schnell), einen umgeschirebenen Jpeg-Encoder für Windows (2x schnell), ... Der Vorteil der GPU liegt darin, dass sie viele Hundert Kerne besitzt, die alle parallel rechnen können. So hat bei den Kaveri APUs zB. die CPU nur 60GFlops (single precision) die GPU das über zehnfache. Vorteile bringt das ganze also bei Workloads, die sich stark parallelisieren lassen. Im Prinzip die selben Anwendungen, in denen GPGPU auch jetzt schon genutzt wird: Photo und Videobearbeitung, Rendering, Physikberechnung, Physik Simulationen, Gesichts-/Objekterkennung müsste auch gut klappen, ... Für das Spielen ist das ganze im Prinzip auch was, denn es ist zB. möglich die komplette Physikberechnung in Spielen und die KI auf der GPU der APU zu berechnen und die externe Grafikkarte für die Bildausgabe zu nutzen. Es wurde aber leider noch keine Grafikengine angekündigt, die das kann. Das dürfte aber nur eine Frage der Zeit sein, denn zumindest die PS4 besitzt auch vollen HSA Support und für die Konsolen wird idr. Entwickelt. Achso, zum Spielen ist der Grafikteil aber nur bedingt geeignet (er ist schneller als alles was Intel hat (außer die Iris Pro, aber die kostet auch das 4-fache) und vergleichbar mit einer Nvidia GT640) und reicht auch locker für ältere Spiele, aber bei neueren Titeln fehlt doch noch etwas Leistung. Im Prinzip beschränkt sich das ganze auch nicht nur auf die CPU und GPU, es können auch noch weitere Module mit dazu geholt werden, DSPs (Hat AMD mit TrueAudio zB. schon in Kaveri drin), FPGAs, spezielle De-/Encoder, ... Also wie der Name schon sagt, alles was das System beschleunigen kann. Ach und noch was, aktuell werden die APUs sehr stark vom Arbeitsspeicher beschränkt, mit DDR4 dürfte sich noch mal ein großer Schritt nach vorne ergeben. Eine GPU müsst meines Wissens zumindest pro Compute Unit einen eigenen "Thread" abarbeiten können, also müsste die Software sich einen Teil der Rechenleistung in form einer CU "reservieren" können. Die GPU von Kaveri hat im Maximalausbau meines Wissens 8CUs mit je 64 "Kernen"
Achim schrieb: > Eine APU ist nicht nur eine GPU neben der CPU auf einem Chip, mit > der > neusten Entwicklungsstufen, ermöglichte AMD beiden Einheiten den Zugriff > auf den selben logischen Speicher (Also müssen die Daten nicht erst vom > "CPU-Speicher" in dem "Grafikspeicher" kopiert werden). Das ganze wird > von AMD unter HSA (Heterogeneous System Architecture) Zusammengefasst Ich enttäusche dich nur ungern, aber das Konzept, den Grafikspeicher in den Adreßbereich der CPU einzublenden (oder, vielleicht richtiger: ihn sich von dort zu "klauen"), ist so alt wie (vermutlich) du selber. Das mach(t)en schon der ZX Spectrum und C64 so. XL
Rolf R. schrieb: > Nach dem Lesen frage ich mich, wie das konkret abläuft, wenn die GPU der > CPU Arbeit abnimmt. Sieh es einfach als eine Neuauflage des Coprozessor-Konzeptes an, wie es historisch mit dem 80x87 entstanden ist. Der Unterschied ist, daß es nur eine 8087 Implementierung gab, aber einige Dutzend verschiedene Shader-Implementierungen. CUDA & Co. abstrahieren das (oder versuchen es zumindest), so daß aus Sicht des Programms verschiedene Grafikeinheiten wieder relativ ähnlich aussehen. Auf jeden Fall muß das Programm von vornherein so geschrieben sein, daß es von den "Coprozessoren" überhaupt Gebrauch macht. Automatisch geht da nix. Früher<tm> hat man auch mal einen Coprozessor emuliert. Heutzutage ist es gebräuchlicher, daß die Software sich auf dem System erst mal umschaut, welche Möglichkeiten es denn gibt (nicht nur CUDA, auch SSE & Co) und dann aus verschiedenen Implementierungen (die alle eingebaut sind) diejenige auswählt, die auf der gerade verwendeten Hardware am schnellsten läuft. XL
Axel Schwenke schrieb: > Ich enttäusche dich nur ungern, aber das Konzept, den Grafikspeicher in > den Adreßbereich der CPU einzublenden (oder, vielleicht richtiger: ihn > sich von dort zu "klauen"), ist so alt wie (vermutlich) du selber. Das > mach(t)en schon der ZX Spectrum und C64 so. Allerdings leiden die bisher in PCs gängigen Verfahren zur Kooperation zwischen CPU und GPU trotz gemeinsamen Speichers mitunter an Ineffizienz beim Datenaustausch, wenn die GPU nicht in das Cache-Kohärenzverfahren der CPUs integriert ist.
:
Bearbeitet durch User
Axel Schwenke schrieb: > Ich enttäusche dich nur ungern, aber das Konzept, den Grafikspeicher in > den Adreßbereich der CPU einzublenden (oder, vielleicht richtiger: ihn > sich von dort zu "klauen"), ist so alt wie (vermutlich) du selber. Das > mach(t)en schon der ZX Spectrum und C64 so. Das Konzept, den selben physischen Speicher für die GPU und CPU zu nutzen ist alt, diese hatten aber dann meines Wissens immer ihre eigenen logischen Speicherbereiche auf die nur sie Zugriff hatten. Bzw. hatte die CPU die Hoheit über den gesamten RAM und musste der GPU die Daten erst zuschaufeln. Das hat man dann Shared-Memory oder sonst wie genannt. Aber das beide Recheneinheiten einen Vollzugriff auf den gesamten Arbeitsspeicher haben, ist auf Grund der über mir erwähnten Kohärenz-Probleme so weit ich weiß noch nicht umgesetzt worden, außer eben bei den APUs. 100% festlegen will ich mich hier aber nicht, könnte nämlich sein, dass ich da vllt. doch was verpasst habe. Aber zumindest im Consumer Bereich dürfte das neu sein. Die C64 GPU konnte zB. nur 16kB Adressieren, reicht also nicht für die vollen 64k des C64. (Quelle: Wikipedia) GPGPU, also Berechnungne auf der GPU und eben nicht nur Bilder Anzeigen, für das HSA ja am interessantesten ist, da man ja so schnell an die Ergebnisse der GPU kommt, kannte man damals auch noch nicht. Der C64 war übrigens noch nicht vor meiner Zeit, sondern eher der Erste Kontakt zu Computern (genauso wie ein Amiga 500). Damals hat mich die Hardware aber leider nicht wirklich erklärt.
Achim schrieb: > Axel Schwenke schrieb ... > Das Konzept, den selben physischen Speicher für die GPU und CPU zu > nutzen ist alt, diese hatten aber dann meines Wissens immer ihre eigenen > logischen Speicherbereiche auf die nur sie Zugriff hatten. Nun, eine logische Aufteilung muß es auch bei der APU geben (und gibt es). OK, die Aufteilung ist heute komplett durch Software gesteuert und nicht wie früher zumindest teilweise durch Hardware. Richtig ist, daß z.B. der VIC des C64 nicht selber in den Speicher geschrieben hat. Die diversen Coprozessoren im Amiga allerdings schon. > Aber das beide Recheneinheiten einen Vollzugriff auf den gesamten > Arbeitsspeicher haben, ist auf Grund der über mir erwähnten > Kohärenz-Probleme so weit ich weiß noch nicht umgesetzt worden, außer > eben bei den APUs. Cache-Dekohärenz ist ebenfalls ein sehr altes Phänomen. Das kennt man seit den ersten Multiprozessorsystemen (dürfte IBM gewesen sein) wo die Prozessoren jeweils eigene Caches hatten. Ich zweifle auch, daß die APU da groß Gedöhns machen. Die GPU selber hat wahrscheinlich gar keinen Cache. Und die CPU schaltet den Cache einfach ab, wenn sie auf Speicher zugreift, der der GPU zugeteilt ist. Das ist auch nicht weiter tragisch, weil es keinen Grund gibt, warum CPU und GPU wirklich konkurrent auf den gleichen Speicherbereich zugreifen müßten. Das ist ein reines Producer-Consumer Setup. In einen Speicherbereich schreibt die CPU Aufgaben für die GPU, in einem anderen schreibt die GPU Ergebnisse für die CPU. Ein Cache nutzt da gar nix. > Die C64 GPU konnte zB. nur 16kB Adressieren, reicht also nicht für die > vollen 64k des C64. (Quelle: Wikipedia) Nur halb richtig. Der VIC im C64 hat in der Tat nur 14 Adreßleitungen, kann also nur 16KB am Stück ansprechen. Allerdings hat eine CIA die anderen beiden Adreßbits geliefert (Bankswitching, eine noch ältere Technik) so daß am Ende die vollen 64K zumindest im Prinzip nutzbar waren. Wie gesagt: die Technik die in aktuellen APU steckt (egal ob AMD oder Intel) ist nur dahingehend neu, daß sie viele, teilweise steinalte Konzepte auf einem Chip vereint. Das ist keine Revolution, sondern nur Evolution; im wesentlichen gedankt der Tatsache daß man die Halbleiterprozesse besser im Griff hat als früher und so größere Chips machen kann ohne daß der Yield in den Keller fällt. XL
Axel Schwenke schrieb: > Cache-Dekohärenz ist ebenfalls ein sehr altes Phänomen. Das kennt man > seit den ersten Multiprozessorsystemen (dürfte IBM gewesen sein) wo die > Prozessoren jeweils eigene Caches hatten. Je mehr die GPUs in eine CPU-artige Rolle (=APU) gedrückt werden, desto mehr Features von CPUs kommen zu ihnen hinzu. Dazu gehört die genannte cache coherency, aber auch paging und context switches. > Wie gesagt: die Technik die in aktuellen APU steckt (egal ob AMD oder > Intel) ist nur dahingehend neu, daß sie viele, teilweise steinalte > Konzepte auf einem Chip vereint. Das ist keine Revolution, sondern nur > Evolution; Richtig. Nichts davon ist grundlegend neu. Man muss es nur tun. > Ich zweifle auch, daß die APU da groß Gedöhns machen. Die GPU selber hat > wahrscheinlich gar keinen Cache. GPUs mit Caches sind nicht ungewöhnlich (z.B. NVidia Fermi, 2 Levels). > Und die CPU schaltet den Cache einfach > ab, wenn sie auf Speicher zugreift, der der GPU zugeteilt ist. Das genau ist ja das Problem. Wenn die CPU auf allen Speicher, den sie mit der GPU teilt, grundsätzlich non-cachable zugreifen muss, dann ist das ziemlich ineffizient und Massnahmen zur Effizienzsteigerung sind programmtechnisch umständlich. Der Sinn dieser Entwicklung besteht gerade darin, dass bisherige Konzept einer völlig separat vor sich hin werkelnden und nur durch device driver kontrollierten GPU durch eines abzulösen, in der eine GPU funktional wie eine weitere CPU arbeitet, nur mit anderem Befehlssatz und anderen Möglichkeiten. Bei Programmen mit mehreren x86 Threads geht man ja auch davon aus, dass sie kohärent auf den Speicher zugreifen können. Der Programmierer also nicht selber für Kohärenz sorgen muss, und keinen Speicher eigens deshalb im RAM festpinnen muss, damit das Paging nichts zerhagelt. > Das ist auch nicht weiter tragisch, weil es keinen Grund gibt, warum CPU > und GPU wirklich konkurrent auf den gleichen Speicherbereich zugreifen > müßten. Je kleinräumiger die Zusammenarbeit zwischen CPU und GPU wird, desto wichtiger wird das. In diese Richtung zielen auch Massnahmen zur Reduktion der Latenzzeit der APIs.
:
Bearbeitet durch User
> Ich enttäusche dich nur ungern, aber das Konzept, den Grafikspeicher in > den Adreßbereich der CPU einzublenden (oder, vielleicht richtiger: ihn > sich von dort zu "klauen"), ist so alt wie (vermutlich) du selber. Das > mach(t)en schon der ZX Spectrum und C64 so. Bloss, dass bei diesen Systemen nur entweder CPU oder GPU Zugriff auf den Speicher hatte.
MCUA schrieb: > Bloss, dass bei diesen Systemen nur entweder CPU oder GPU Zugriff auf > den Speicher hatte. C64 ist nicht meine Welt, aber das gabs damals schon mit gemeinsamem Zugriff. Beispielsweise ein 6809 System mit Display-Controller als TTL-Grab (Eurocom, oder so ähnlich). Bei 65xx/68xx lag es ja nahe, in Φ1 das Display und in Φ2 den Prozessor ran zu lassen. Auch Sinclair ZX80 und ZX81 verwendeten das normale RAM als Display-Speicher. Und das ausserdem in sehr kreativer Weise, mit dem Prozessor als Display-Controller.
:
Bearbeitet durch User
bei diesen bisherigen Systemen (zB bei HCs oder auch bei STPC) wird (aus Kostengründen) nicht nur Speicher, sondern auch Speicher-Bandbreite abgezwackt. CPU u GPU müssen sich also die Bandbreite teilen.
MCUA schrieb: > bei diesen bisherigen Systemen (zB bei HCs oder auch bei STPC) wird (aus > Kostengründen) nicht nur Speicher, sondern auch Speicher-Bandbreite > abgezwackt. CPU u GPU müssen sich also die Bandbreite teilen. Richtig. Aber das tun 2 Cores einer CPU auch. Getrennter Speicher und unterschiedliche Vorgehensweise bei Cache-Kohärenz erschweren die Programmierung kooperierender Programme. Sowohl bei klassischen homogenen CPUs als auch bei heterogenen Gebilden aus CPU und GPU. Ist halt die Frage, was man erreichen will.
>Aber das tun 2 Cores einer CPU auch.
Nö. Es kommt (immer) auf die Verschaltung an.
MCUA schrieb: >>Aber das tun 2 Cores einer CPU auch. > Nö. Es kommt (immer) auf die Verschaltung an. Deshalb hatte der Cell Prozessor ja auch so durchschlagenden Erfolg im Markt, jenseits der Playstation.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.