GPGPU

Das heisst doch indirekt das Adobes CC mit AMD GPU läuft, interessant sinnst wird doch praktisch immer NV CUDA verwendet.
 
Adobe setzt doch schon länger auf OpenCL.
Viel spannender an dem Video finde ich etwas anderes. Adobe scheint OpenCL beim konvertieren von Video-Material, und hier besonders 4k Material, eine beeindruckende Performance zu entlocken (siehe Vergleich zur CPU gegen Ende des Videos). Und das ohne irgendwelche Qualitätseinbußen!

Bislang wurde das ja immer für unmöglich gehalten. Entweder man bemerkte kaum einen Geschwindigkeitsunterschied wie bei h264 oder es ging mit enormen Qualitätseinbußen einher.
 
Nvidia hat CUDA 6 herausgebracht, wie heise berichtet.

Darin: "...Sie erlaubt dank ein an das hUMA-Konzept (heterogeneous Uniform Memory Access) der Heterogeneous System Architecture (HSA) erinnerndes Unified-Memory-Programmiermodell den Zugriff auf CPU und GPU, ohne dass jemand die Daten vorher kopieren muss...."

Wie soll das zu verstehen sein, wo Nvidia doch nur die GPU liefert aber nicht die CPU (ich gehe mal von X86 aus) und beide doch eigenen Speicher haben?
MfG
 
Woerns schrieb:
Wie soll das zu verstehen sein, wo Nvidia doch nur die GPU liefert aber nicht die CPU (ich gehe mal von X86 aus) und beide doch eigenen Speicher haben?
MfG
Zum Vergrößern anklicken....

Die Frage habe ich mir auch gestellt. Vielleicht lösen sie es ähnlich wie AMD es mit GCN-GPUs macht und greifen direkt über PCIe auf den Arbeitspeicher zu.
Obwohl die Bezeichnung hUMA etwas zu weit geht, denn der Inhalt des Cache der CPU bleibt so aussen vor.
 
Woerns schrieb:
Nvidia hat CUDA 6 herausgebracht, wie heise berichtet.

Darin: "...Sie erlaubt dank ein an das hUMA-Konzept (heterogeneous Uniform Memory Access) der Heterogeneous System Architecture (HSA) erinnerndes Unified-Memory-Programmiermodell den Zugriff auf CPU und GPU, ohne dass jemand die Daten vorher kopieren muss...."

Wie soll das zu verstehen sein, wo Nvidia doch nur die GPU liefert aber nicht die CPU (ich gehe mal von X86 aus) und beide doch eigenen Speicher haben?
MfG
Zum Vergrößern anklicken....

Das ist ein reines Software-Feature. Der Programmierer muss sich nicht ums Umherkopieren kümmern. Es wird von der Laufzeitumgebung automatisch gemacht. Das hat aber wenig mit hUMA zu tun.
 
Aha, jetzt hat's Klick gemacht.
Gemeint ist demach nicht etwa, dass das kopieren entfällt, sondern vielmehr, dass es nicht extra programmiert werden muss.

Ist natürlich ein Vorteil, wenn das automatisch geht. Dasselbe würde ich mir bei AMD auch erhoffen, wobei es schwierig ist zu entscheiden, welche GPU die Aufgabe besser erfüllt, wenn eine APU mit einer dedizierten GPU gepaart ist. In der APU hat man weniger GPU Kerne, dafür entfällt der Kopieraufwand. Je nach Aufgabenstellung kann mal das eine mal das andere sinnvoll sein.
Danke und mfG
 
Intel liefert für seine GPUs ein OpenCL SDK, was AMD seinerseits dringend benötigt, um z.B. bei Kaveri die Handbremse zu lösen. Ist zwar nur OpenCL 1.2 und nicht 2.0, aber besser als gar nichts. Und es bietet Plug-Ins für Visual Studio und Eclipse!
MfG
 
Mein Eintrag wurde nicht richtig aktualisiert. Vielleicht jetzt.
 
Woerns schrieb:
Intel liefert für seine GPUs ein OpenCL SDK, was AMD seinerseits dringend benötigt, um z.B. bei Kaveri die Handbremse zu lösen. Ist zwar nur OpenCL 1.2 und nicht 2.0, aber besser als gar nichts. Und es bietet Plug-Ins für Visual Studio und Eclipse!
MfG
Zum Vergrößern anklicken....

Ein SDK mit Plugins gibt es von AMD aber auch. Um das Potential von Kaveri zu lösen ist schon OpenCL 2.0 notwendig.
Für Software zur Verarbeitung von Media-Daten gibt es kaum noch Applikationen die überhaupt keine OpenCL Unterstützung bieten. Und 2.0 wird noch mal einen Schub bringen, weil es wichtige Beschränkungen aufhebt und endlich hUMA unterstützt.
Wo es noch etwas rar aussieht, sind Spiele. Aber könnte AMD mit den Konsolen und Mantle im Rücken die Hürden ein gutes Stück senken. DirectX und OpenCL gilt nicht gerade als einfache Kombination.
 
Dade von Luxrender hat sich kürzlich über den katastrophalen Zustand von AMDs OpenCL-Compiler geäußert (Sogar der CPU-Compiler scheint einige Probleme zu haben). Ganz ehrlich, angesichts der Probleme bei Cycles und anderen Programmen die von OpenCL profitieren würden, ist mir nicht klar, warum AMD da nicht mehr Mühen reinsteckt.

Lieber erstmal OpenCL 1.2 ordentlich als halbgares Zeug zu veröffentlichen. Man kann nur hoffen, dass AMD momentan für openCL 2.0 das Ganze neu konzipiert und entsprechende Ressourcen investiert.
 
Probleme mit dem Compiler beklagen mehrere. Man muss die Fehler beheben wollen. Da ist es egal ob es für 1.2 oder 2.0 ist.
 
mariahellwig schrieb:
Um das Potential von Kaveri zu lösen ist schon OpenCL 2.0 notwendig.
Zum Vergrößern anklicken....
Ich möchte hoffen, dass es keine Möglichkeit gibt, das Potenzial von irgendwelchen AMD-Produkten zu lösen.
 
isigrim schrieb:
Dade von Luxrender hat sich kürzlich über den katastrophalen Zustand von AMDs OpenCL-Compiler geäußert (Sogar der CPU-Compiler scheint einige Probleme zu haben). Ganz ehrlich, angesichts der Probleme bei Cycles und anderen Programmen die von OpenCL profitieren würden, ist mir nicht klar, warum AMD da nicht mehr Mühen reinsteckt.

Lieber erstmal OpenCL 1.2 ordentlich als halbgares Zeug zu veröffentlichen. Man kann nur hoffen, dass AMD momentan für openCL 2.0 das Ganze neu konzipiert und entsprechende Ressourcen investiert.
Zum Vergrößern anklicken....

Ich werde auch bald mal mit dem Zeug arbeiten. Also unser Student, der u.a. für AMD GPU, Intel CPU u. Freescale i.MX6 OpenCL compiliert, hatte keine Probleme bei AMD.

Falls Dade einen Bug fand, ist das natürlich schlecht, sagt aber nichts über die Compilergeschwindigkeit aus.
 
War von Geschwindigkeit die Rede [ernsthafte Frage]?
 
Währenddessen machen sie weiter mit dem HSA Support für Linux/Kaveri. Wobei es relativ wenige änderungen gegeben hat seit dem letzten Version. Und das meisste ist Zeilen umherschieben.

@Unbekannter Krieger

Ja, unter anderem geht es um die Geschwindigkeit, zumindest im vom isigrim verlinkten Thread.
 
hm es geht da um Funktionen der neuen sdk die nicht gehen und zum teil den Compiler anhalten ;)
hab aber nicht tiefer reingeschaut was er den da wirklich versucht hatte
 
Während meiner Gehversuche mit dem SDK habe ich keine Schwierigkeiten gehabt. Ich habe mich aber auch mehr an den mitgelieferten Beispielen beschäftigt, so dass auch wenig Probleme zu erwarten waren.
 
Danke für die Info! Hatte ich bislang gar nicht gesehen. Ich hatte schon gedacht, dass da nichts mehr kommt, nachdem man länger nichts gehört hat.

Hab´s gerade mal auf meinem Richland-Notebook getestet, da geht´s mit 14.12 und 15.3 Beta nicht. Entweder nur transparent oder ein paar schwarze Blöcke.
Jetzt mal sehen, ob´s auf dem Desktop Trinity geht...
Alle erfolgreichen Tests bei Blenderartists waren bislang mit GCN, könnte also schwierig werden mit VLIW4.
 
Mit den freien Treibern ist da noch nichts zu wollen oder?
Sonst würde ich auf meiner HD7770 mal testen.
 
Ich muss gestehen, dass ich keine Ahnung habe, wie weit die offenen OpenCL-Treiber sind. GalliumCompute scheint aber von "tauglich" noch ziemlich weit entfernt zu sein.
AMD hat neue Programmierer für die OpenSource-Entwicklung eingestellt, kann also sein, dass da bald ein bisschen was kommt. Aber momentan ist das glaube ich verlorene Liebesmüh.

Bei mir funzt es auf VLIW4 jedenfalls nicht. Keine Ahnung, ob man bei AMD an die Prä-GCN-Architekturen nicht mehr denkt. Wäre für den Laptop schön gewesen, wenn man die GPU-Leistung zur Verfügung gehabt hätte.

Im Prinzip gibt der Patch aber Hoffnung, dass jetzt für Blender, insbesondere Cycles intensiv an OpenCL weitergearbeitet wird. Bislang war der Megakernel und die damit verbundenen Probleme bei AMD und Intel ja der Grund, warum die OpenCL-Entwicklung auf Eis gelegt wurde.

Das bringt dann auch mehr Leuten einen Nutzen als CUDA (auch wenn ich mir nur für Blender eine 970 geholt habe) und dann gibt´s auch gleich eine Verwendung für Fiji :D
 
Zuletzt bearbeitet:
Anfangs wird AMD wohl an der aktuellen Hw testen.Gleich wie bei oss bemühungen bei AMD da gab es auch schon features welche erst bei radeonsi kamen und nachher auf r600g angepasst wurden und umgekehrt.
Wie wirkt sich der Patch eigentlich auf Nv/Intel aus bei Verwendung von OpenCl?
 
Zurück
Oben Unten