Alles über/um HSA (aus dem Kabinithread)

[isigrim]

AMD muss erstmal sehen, dass deren OpenCL-Treiber ordentlich funktionieren. Die OpenCL-Unterstützung für Cycles scheitert derzeit praktisch noch komplett an AMDs Mangel, function calls auf der GPU zu unterstützen. (Das Problem zieht sich inzwischen seit mehr als einem Jahr). Bei SmallLuxGPU4 gab's auch Probleme und ReconstructMe hat gerade auf den GCN-GPUs gestreikt, wohl auch wegen Treiber-/Compilerproblemen bei OpenCL.
Die neuen Beta-Treiber bringen da wohl endlich Besserung, aber AMD möchte bei GPGPU ja eigentlich vorneweg gehen, nicht hinterhergurken. Und momentan scheiterts dank der hervorragenden GCN-Architektur nicht mehr an der Hardware, sondern an der Software. Da ist Nvidia schon einen Schritt weiter und wenn AMD weiter im Profi-Segment zulegen möchte, sollten sie mal langsam ihre Software-Abteilung auf Vordermann bringen.

Gut ist nun, dass Apple für die neuen MacPros voll auf OpenCL setzen will (daher haut da Adobe wohl auch so drauf) und ich denke Apple lässt da dann auch ordentlich Geld springen. Das wirkt sich auch positiv auf den restlichen PC-Markt aus.

 

[Complicated]

Bin eben erneut über den Thread gestolpert und dachte ich aktualisiere mal neu bekanntes:
Gute Übersicht über HSA und AMDs Hardware-Features die damit verbunden sind, wie GPU, VCE, UVD und TreuAudio:
http://www.tweakpc.de/hardware/tests/cpu/amd_a10-7850k_a10-7700k/s04.php

Heterogene Anwendungen:
Ein paar HSA Benchmarks: http://www.extremetech.com/computin...-wait-for-the-first-true-heterogeneous-chip/5

Hier hatte die HSA Beschleunigung aus irgendeinem Grund nicht geklappt wie dem dortigen Text zu entnehmen ist.

Weitere Benchmarks: http://wccftech.com/amd-kaveri-i54670k-benchmarks-showdown-continued-hsa-features-test/

--- Update ---

Hier auch eine Powerpoint Präsentation die beschreibt wo der Unterschied zwischen OpenCL on GPU und OpenCL mit SVM (Shared Virtual Memory) bei Corel AfterShot ist. Inkl. Code wie es umgesetzt wird und welche Probleme gelöst werden indem man Shared Memory nutzen kann.
http://de.slideshare.net/DevCentralAMD/hc-4020-michaelwootton

--- Update ---

Referenz System der HSA Foundation und Installationsanweisungen
https://github.com/HSAFoundation/HSA-Docs-AMD/wiki/HSA-Platforms-&-Installation
Ressourcen für HSA bei github:
https://github.com/HSAFoundation
https://github.com/HSAFoundation/HS...tations,-Drivers,-Compilers,-Tools,-Libraries

Es scheint derzeit nur auf Ubuntu 14.04 HSA aktivierbar zu sein.

--- Update ---

Und hier eine Präsentation für Software Implementierung, die sicherlich vieles klären kann:
http://www.slideshare.net/hsafoundation/hsa-from-a-software-perspective

 

[Complicated]

Ein wichtiger Punkt der immer wieder diskutiert wird wenn es um HSA geht:
Ab wann gilt eine APU als HSA fähig und warum soll Llano schon HSA Features haben.

Hier ist eine weit verbreitete Meinung dass erst mit hUMA und HQ "echtes" HSA Einzug hielt. In diesem Artikel ist die Entwicklung des gemeinsamen Speichermodells schön zusammen gefasst und auch welche Unterschiede zwischen Llano, Trinity und Kaveri hierbei bestehen:
http://techreport.com/review/25908/amd-a8-7600-kaveri-processor-reviewed/2

AMD outlined the basic HSA architecture several years ago, and it has been slowly adding features to its chips to make this vision a reality. The first APU, Llano, had a 128-bit Fusion Compute Link that allowed the GPU to access CPU-owned memory in certain cases. This link was an add-on created specifically for mixed-mode computing, since the integrated Radeon had a 512-bit bus of its own. Trinity expanded the FCL to 256 bits wide and changed its path, routing it through an IOMMU and into a unified north bridge between the CPU and graphics cores. Kaveri retains the 512-bit Radeon bus and the 256-bit FCL, and it adds a third 256-bit link from the GPU to the north bridge.

This new link is notable because it provides coherent access to memory. That is, the GPU can read and modify memory locations over this link without worrying about whether the same data is being held or modified in the CPU caches. Much like in a multi-socket server, Kaveri's hardware ensures that its CPU and GPU cores are properly synchronized and working on correct, up-to-date data. Programmers and compilers need not worry about the hazards created by the GPU reaching into main memory and making a change. Coherent communication is one of the keys to unlocking the GPU's full participation in heterogeneous computing, and Kaveri is the first chip from AMD to offer this capability.

Kaveri's coherent FCL pairs up with a couple of other HSA-enabling features to open some new possibilities for programming an APU. Thanks to a feature called hUMA, or hetergenous uniform memory architecture, the CPU and GPU can share up to 32GB of memory and access it via a common addressing scheme. hQ, or heterogeneous queuing, allows the GPU to create and dispatch work for itself—or for the CPU. Kaveri's graphics unit includes eight dedicated asynchronous compute engines (ACE), independent of the graphics command processor, for scheduling parallel computing work. And Kaveri supports the atomic operations needed for synchronization between the CPU and GPU cores.

At the Kaveri press event, AMD HSA honcho Phil Rogers offered several examples of how an HSA-compliant APU could intermix CPU and GPU operations for higher performance using simple, less repetitive code. Kaveri is the first chip capable of running that code natively, making it the first real development platform for HSA. If AMD somehow is able to persuade the rest of the industry to standardize on its vision for heterogeneous programming, that could be an even bigger coup than the adoption of the x86-64 ISA back in the Athlon 64 days.

Wenn der englische Text nicht eingängig ist, übersetze ich ihn hier gerne auf Anfrage.

In jedem Fall kann man Kaveri als erste Entwicklerplattform für HSA sehen. Nicht aber die erste APU mit HSA Features verbaut.

 

[Complicated]

Wie schon von mir vermutet, verdichten sich die Hinweise darauf, dass Tonga HSA Features in diskrete GPUs bringt. Nur geht jetzt wieder die selbe Diskussion los die wir eben bzgl. Kaveri hatten:
http://www.winboard.org/artikel-new...cherinterface-sowie-hsa-bestaetigt-haben.html

Laut AMD sollen die neuen Grafikkarten, die auf Tonga basieren, vollständig zur Heterogeneous System Achitecture (HSA) kompatibel und somit auch den aktuellen Kaveri-APUs voraus sein. AMD würde mit Tonga sein erstes HSA-fähiges Produkt auf den Markt bringen.

Kaveri entspricht laut einer bereits älteren AMD-Folie der dritten "HSA-Ausbaustufe", während der neue Tonga-Chip schon der vierten und somit vorerst finalen Stufe entsprechen dürfte.

Gerade hat man noch diskutiert ob Kaveri das erste "echte" HSA Produkt ist. Dies kann man nun natürlich bis in alle Ewigkeit fortführen mit jeder Verbesserung bei HSA. Es wäre aber besser das so zu betrachten wie bei den DX Features mit jeder Ausbaustufe, da es eine kontinuierliche Entwicklung ist.

Allerdings hält HSA damit Einzug auf Nicht-AMD Plattformen in Form einer diskreten GPU. Bin wirklich gespannt, welche Einschränkungen herrschen wenn eine nicht-HSA CPU verbaut ist oder ob die dGPU hUMA und HQ auf Intel Systemen möglich macht.

 

[ONH]

Naja, demnach hat tonga features von der vierten/letzten Spalte auf der fusion /hsa Folien wenn man soweit geht dann kann man sagen llano besitzt schon hsa oder carrizo ist die erste richtige hsa apu. Alles dazwischen ist ein Witz.

 

[Complicated]

Hängt davon ab ob eine HSA GPU auch schon mit Llano gemeinsam Effekte erzielen kann. Es wird sicherlich interessant sein mit der ersten HSA GPU die verschiedenen APU Generationen zu testen.

 

[Complicated]

Neues an der HSA Front bei Cortel Afftershot 2.1
http://www.planet3dnow.de/cms/12386...to-mac-and-linux-adds-support-for-17-cameras/

Enhanced User Experience: Thumbnail improvements, increased OpenCL 2.0 performance,

Wenn jemand erste HSA-Benchmarks auf Kaveri sichtet wäre schön wenn er diese hier posten könnte.

 

[clearlake]

AMD muss erstmal sehen, dass deren OpenCL-Treiber ordentlich funktionieren. Die OpenCL-Unterstützung für Cycles scheitert derzeit praktisch noch komplett an AMDs Mangel, function calls auf der GPU zu unterstützen. (Das Problem zieht sich inzwischen seit mehr als einem Jahr). Bei SmallLuxGPU4 gab's auch Probleme und ReconstructMe hat gerade auf den GCN-GPUs gestreikt, wohl auch wegen Treiber-/Compilerproblemen bei OpenCL.
Die neuen Beta-Treiber bringen da wohl endlich Besserung, aber AMD möchte bei GPGPU ja eigentlich vorneweg gehen, nicht hinterhergurken. Und momentan scheiterts dank der hervorragenden GCN-Architektur nicht mehr an der Hardware, sondern an der Software. Da ist Nvidia schon einen Schritt weiter .....

Intel legt sich wohl auch ins Zeug, was OpenCL 2.0 angeht. Core M ist laut Intel die erste OpenCL 2.0 - certifizierte Platform. Außerdem bietet Intel mit seinen Werkzeugen vollen Cross Platform Support (Windows, Android, Linux; https://software.intel.com/en-us/intel-opencl/details). Siehe auch hier: http://www.heise.de/newsticker/meld...-und-effizienter-Angriff-auf-AMD-2390225.html . In 2015 gibt's außerdem (mit Skylake) eDram auch für Desktop ...

 

[Atombossler]

Intel legt sich wohl auch ins Zeug, was OpenCL 2.0 angeht. Core M ist laut Intel die erste OpenCL 2.0 - certifizierte Platform. Außerdem bietet Intel mit seinen Werkzeugen vollen Cross Platform Support (Windows, Android, Linux; https://software.intel.com/en-us/intel-opencl/details). Siehe auch hier: http://www.heise.de/newsticker/meld...-und-effizienter-Angriff-auf-AMD-2390225.html . In 2015 gibt's außerdem (mit Skylake) eDram auch für Desktop ...

Die Software ist wirklich das ewige Problem von AMD, das kriegen die einfach nicht gebacken.
Wundern sich aber das die APUs nicht so laufen ...

 

[clearlake]

was willste da machen, außer entgeistert zuschauen und über die Gründe spekulieren. Bei anderen sehen die Dinge oft wie aus dem Hut gezaubert aus, AMD spricht gefühlt schon ewig von Fusion. AMDs Ankündigungs- und Kommunikationspolitik, gerade was umfassende Großprojekte (weil Hardware und Software betreffend) wie Fusion angeht, ist mir ein Rätsel.

 

[gruffi]

Intel legt sich wohl auch ins Zeug, was OpenCL 2.0 angeht. Core M ist laut Intel die erste OpenCL 2.0 - certifizierte Platform. Außerdem bietet Intel mit seinen Werkzeugen vollen Cross Platform Support (Windows, Android, Linux; https://software.intel.com/en-us/intel-opencl/details). Siehe auch hier: http://www.heise.de/newsticker/meld...-und-effizienter-Angriff-auf-AMD-2390225.html . In 2015 gibt's außerdem (mit Skylake) eDram auch für Desktop ...

Wäre ein weiterer Todesstoss für CUDA, wenn nun auch Intel so stark auf OpenCL setzt. Gut so.

Die Software ist wirklich das ewige Problem von AMD, das kriegen die einfach nicht gebacken.
Wundern sich aber das die APUs nicht so laufen ...

Was willst du uns damit sagen? Die OpenCL 2.0 Treiber von AMD sind schon seit einigen Wochen am Start. Sowohl für Windows als auch Linux.

 

[Atombossler]

... und was sollen die Treiben??
Wo ist das SDK, Integration in einschlägiges IDEs, passender Compiler, Musterlösungen + Anwendungen at all?

 

[gruffi]

Hast du dich schon mal auf der Developer Zone bei AMD umgesehen? Da gibt's das alles. Und mehr. Und dir ist schon klar, dass du mit jedem x-beliebigen OpenCL SDK OpenCL Anwendungen entwickeln kannst? Du brauchst dafür nicht zwangsläufig das von AMD. Damit es auf AMD läuft, brauchst du lediglich das entsprechende Treiberpaket. Und das gibt es wie gesagt seit einigen Wochen.

 

[Dr@]

Es gibt einen Treiber der fernab von einem stabilen Release-Treiber ist. Es gibt ein OpenCL 2.0 SDK von AMD, aber nur für ausgewählte Entwickler (ist nicht frei zugänglich).

Es gibt nach wie vor kaum Anwendungen in denen APUs von ihrer GPU profitieren.

Obwohl die Kaveri-APUs seit Anfang des Jahres im Verkauf sind, gibt es keinen HSA Stack. Es sind lediglich Pre-Alpha-Versionen für den Linux-Open-Source-Treiber verfügbar.


Die softwareseitige Unterstützung des APU-Konzepts ist mehr als mau.

 

[gruffi]

Ist doch besser als gar nichts, oder? Oder erwartest du alles von heute auf morgen? Das wäre reinste Utopie. Was gibt es denn von Nvidia bezüglich OpenCL 2.0? Oder was haben andere Mitglieder der HSA Foundation bisher vorzuweisen? ARM? Qualcomm? Samsung? Es gibt schliesslich nicht nur AMD.

 

[Unbekannter Krieger]

ein weiterer Todesstoss für CUDA

Mehr als ein Todesstoß für ein und dasselbe Ziel?

 

[Raspo]

Naja Gruffi, wenn AMD behauptet wie toll doch die Computecores von Kaveri sind und damit Werbung machen (Sandwich YouTube Video) sollten sie dringend mehr tun.

Eigentlich hätte es beim Kaveri-Launch irgendwas Produktives für die Presse und Berichterstattung geben müssen.

Meine Meinung.

 

[gruffi]

Gab es doch.

 

[Atombossler]

Gab es doch.

?? Der jpeg Kram? Na wie toll, wo ist der denn drin, in welchem Bildbetrachter?
Der Libre Office Demo Quatsch? In welcher realen Trading Soft wurde das integriert, wo es wirklich zum tragen kommt?
Wer lässt sich denn einen Datenstream in Excel oder Konsorten reinkotzen??
Was gabs noch? Ach ja x264Lookahead@ocl na suuper, war der burner ...
Bleibt nur irgendwelcher Gesichtskram aufm Notebook, wofür auch immer das gut sein soll.

Nicht vergessen, Kaveri war zwar die erste richtige HSA APU, aber das Gebastel geht ja jetzt schon seit Trinity und das Ergebnis ist genau was?

 

[isigrim]

AMD hat halt mal wieder das Problem des Marktanteils. So lange Intel kein HSA unterstützt ist es denkbar schwierig, einen Entwickler zu überzeugen, da Hirnschmalz reinzustecken, es sei denn man bezahlt ihn explizit dafür.

Es ist immer wieder zum Sche**e brüllen. AMD hat etwas wirklich nützliches und es wird nicht genutzt, weil Intel den Löwenanteil am Markt hält und Konzepte erst unterstützt, wenn man selbst die entsprechende Hardware am Start hat. Damit ist AMDs Vorstoß dann allerdings zu diesem Zeitpunkt verschwendetes Kapital.

 

[Woerns]

Für mich ist das weniger eine Frage des Marktanteils als vielmehr, wo AMD investiert.
Offenbar sind die Softwareentwickler jeweils die ersten, die rausgeworfen werden, wenn AMD seine Mitarbeiter dezimiert.
Während auf der anderen Seite die Werbeabteilung (zugegeben mit oft schlechten Folienpraktikanten) das Blaue vom Himmel verspricht.

Die direkte Konkurrenz Intel und Nvidia profitiert enorm von ihren Vorarbeiten in Software.
Der Intel Compiler ist dem schon recht guten Microsoft-Compiler und erst recht dem GNU-Compiler deutlich voraus. Eine Firma wie Apple, die im X86-Bereich Intel-only ist, kann alleine durch Compilieren rund 20% Performance jenseits von Hardware-Investitionen gewinnen.
Nvidia bietet viel bessere Treiberunterstützung im Profibereich und beherrscht mit CUDA immer noch den GPGPU-Markt.

AMD hätte hardwareseitig die meisten Bausteine beisammen, aber pfuscht verheerend bei der Software. Wahrscheinlich liegt es am Management, ich kenne es selbst, wenn Controller aus den USA glauben, sie könnten in der Softwareabteilung mitreden. Da geht es nur darum, Geld zu sparen, weil das aus deren Exceltabellen vermeintlich so hervorgeht. Die denken sich, in Burkina Faso geht es noch billiger als in Indien, also entlassen wir in Indien 18 Leute und stellen in Burkina Faso 22 neue ein.
Was aber in der Softwareentwicklung gefragt ist, ist Kontinuität und das Halten von Knowhowträgern.
MfG

 

[gruffi]

?? Der jpeg Kram? Na wie toll, wo ist der denn drin, in welchem Bildbetrachter?
Der Libre Office Demo Quatsch? In welcher realen Trading Soft wurde das integriert, wo es wirklich zum tragen kommt?
Wer lässt sich denn einen Datenstream in Excel oder Konsorten reinkotzen??
Was gabs noch? Ach ja x264Lookahead@ocl na suuper, war der burner ...
Bleibt nur irgendwelcher Gesichtskram aufm Notebook, wofür auch immer das gut sein soll.

Wenn man so "argumentiert", kann man alles schlechtreden. Was habe ich denn von Intels QuickSync Grütze? Gar nichts. Und was bringt mir Nvidias CUDA Murks? Noch weniger.

Der Intel Compiler ist dem schon recht guten Microsoft-Compiler und erst recht dem GNU-Compiler deutlich voraus.

Nicht wirklich. GNU ist Intel überlegen bezüglich Portabilität und Standardunterstützung. Und der Microsoft Compiler war nie wirklich gut. Nur halt am meisten verbreitet unter Windows.

 

[Atombossler]

Für mich ist das weniger eine Frage des Marktanteils als vielmehr, wo AMD investiert.

Nicht nur WO, sondern auch WIE.
Ausserdem steht und fällt die Hardware nun mal mit der Softwareunterstützung, das ist weniger eine Sache des schieren Marktanteils.
Wenn ein Paket überzeugt, dann ist der Marktanteil erstmal zweitrangig, es wird gekauft -> sog. Selbstläufer

Offenbar sind die Softwareentwickler jeweils die ersten, die rausgeworfen werden, wenn AMD seine Mitarbeiter dezimiert.
Während auf der anderen Seite die Werbeabteilung (zugegeben mit oft schlechten Folienpraktikanten) das Blaue vom Himmel verspricht.

Die direkte Konkurrenz Intel und Nvidia profitiert enorm von ihren Vorarbeiten in Software.
Der Intel Compiler ist dem schon recht guten Microsoft-Compiler und erst recht dem GNU-Compiler deutlich voraus. Eine Firma wie Apple, die im X86-Bereich Intel-only ist, kann alleine durch Compilieren rund 20% Performance jenseits von Hardware-Investitionen gewinnen.
Nvidia bietet viel bessere Treiberunterstützung im Profibereich und beherrscht mit CUDA immer noch den GPGPU-Markt.

AMD hätte hardwareseitig die meisten Bausteine beisammen, aber pfuscht verheerend bei der Software. Wahrscheinlich liegt es am Management, ich kenne es selbst, wenn Controller aus den USA glauben, sie könnten in der Softwareabteilung mitreden. Da geht es nur darum, Geld zu sparen, weil das aus deren Exceltabellen vermeintlich so hervorgeht. Die denken sich, in Burkina Faso geht es noch billiger als in Indien, also entlassen wir in Indien 18 Leute und stellen in Burkina Faso 22 neue ein.
Was aber in der Softwareentwicklung gefragt ist, ist Kontinuität und das Halten von Knowhowträgern.
MfG

Das SDK als Beta ist da, ja, aber die versprochenen Media APIs fehlen bis auf weiteres, und genau auf die käme es an.
Selbst die von AMD unterstützte Entwicklung von x265 wird vornehmlich auf avx2 optimiert, welches kein AMD Chip bisher beherrscht.
OCL, HSA?? ist da komplett kein Thema.
Ein kleines, exquisites Softwareteam für Leuchtturmprojekte würde sich definitiv rechnen, sollen Sie eben die entsprechende Anzahl Marketingluschen
freisetzen, die sind absolut verschmerzbar.

Selbst die Investoren wundern sich, wieso sich RR zB. auf einen Preiskampf bei Notebooks/Tablets im Billigsegment mit In*el eingelassen hat, wo doch jeder weiss,
das die Ihre Chips für umsonst auch noch in Benjamin Franklin Geschenkpapier einwickeln und frei Haus liefern.
Dringender als alles andere müssen Die Ihr Management auf die Reihe bekommen.
So wird das sonst nichts.

--- Update ---

Wenn man so "argumentiert", kann man alles schlechtreden. Was habe ich denn von Intels QuickSync Grütze? Gar nichts.

Würd ich so jetzt nicht sagen.
Das es qualitativ besser geht (mit x264) steht ausser Frage, aber schnell ist der Kram und liefert anständige Ergebnisse bei kaum Verbrauch.
Lässt sich zudem von vielen Standard Tools aus ansteuern und ist sogar in mindestens einem Synology NAS drin und kann dort on the fly transcoden.
Nichts dergleichen auf seiten von HSA.

 

[gruffi]

Selbst die von AMD unterstützte Entwicklung von x265 wird vornehmlich auf avx2 optimiert, welches kein AMD Chip bisher beherrscht.

Kommt in Kürze mit Carizzo. Was soll AMD denn deiner Meinung nach machen? x265 für XOP optimieren, was über 80% der Prozessoren auf dem Markt nicht unterstützen?

Das es qualitativ besser geht (mit x264) steht ausser Frage, aber schnell ist der Kram und liefert anständige Ergebnisse bei kaum Verbrauch.

Das kann ich über die HSA Beispiele von dir oben aber genauso sagen. Anwendungen wie LibreOffice nutze ich wenigstens. Video Konverter mit QuickSync Unterstützung habe ich aber keinen.

 

[Complicated]

und ist sogar in mindestens einem Synology NAS drin und kann dort on the fly transcoden.
Nichts dergleichen auf seiten von HSA.

Nur dass dieses Synologie NAS nicht existiert. Das ist typisch in der Argumentation. HSA Software wird geleugnet und Intel werden Dinge zugeschrieben die gar nicht existieren. Core Aftershot z.B nutzt sehr effektiv HSA und nun sogar bei OpenCL. Matle ist ein API mit HSA Elementen und der Nutzen ist eindeutig vorhanden auch ohne HSA API und Treibern. Und welches anderes Unternehmen hat so viele Softwareentwucklungen gemacht wie AMD in den letzten 3 Jahren.