News HSA-Entwicklerplattformen ab Anfang 2014

[Headcool]

Dann sprichst du aber von einer anderen Optimierung als am Anfang der Diskussion. Der Programmierer von "Software XY" nimmt eine Bestimmte API/Compiler und lässt Code einfach weg. Der muss sich nichtmehr mit AMD's HSA auseinandersetzen auf der ebene. AMD und entsprechende Partner haben vorher die (Programmier) Arbeit schon gemacht. Es ist also wenn auf der ebene der API/Prog.-Sprachen/Compiler Optimierungs bedarf nötig. Deshalb macht der Vergleich mit AVX512 auch keinen Sinn. Ohne bestimmte Funktionen/werte kannst aus AVX512 ja gar keinen Vorteil ziehen.

Natürlich kann man Optimierungen in Libraries und APIs reinziehen und erreicht so ein höheres Publikum. Nur müssen die entsprechenden Softwareentwickler das auch nützen. Auf den Konsolen nicht ganz unwahrscheinlich.
Auf dem PC und sonstwo hingegen schon, denn dort gibt es fast keine Entwickler die AMD spezifische APIs/Libs verwenden.

AVX512 kann für sogut wie alles verwendet werden, was man mehr als ein paar mal macht, also wenn man Daten seriell verarbeitet. Da braucht man keine speziellen Anwendungsfälle, denn sogut wie jedes Programm hat solche Stellen und im Normalfall sind diese Stellen auch die Flaschenhälse.

Ein gutes Beispiel ist Skyrim. Dank Patch eines Fans war das Spiel dann um ca 50% schneller. Alles was der Typ gemacht hatte war Funktionen die die FPU benutzen durch Funktionen die die SSE-Einheiten nutzte auszutauschen.
Und SSE ist ziemlich alt, AVX oder gar AVX512 dürfte da noch einen ordentlichen Schub geben.

Dieser FanPatch hat die Arbeitszeit von weniger als 2 Monaten eines einzelnen Programmierers gebraucht, der dazu noch Reverse Engineering betreiben musste.

Wenn man sich dagegen anschaut, dass man bis zu 20% Mehrleistung durch Mantle kriegt(laut Thief Entwickler), dafür aber Mantle zusätzlich zu D3D oder OGL verwenden muss, was ziemlich viel Aufwand bedeutet.

http://hsafoundation.com/f-a-q/

OpenCL integration ist eine schöne Sache. Da aber OpenCL Software nach wie vor nicht häufig Verwendung findet, v.a. dort wo APUs am Werk sind bringt auch das nichts. Und C++AMP ist zwar keine schlechte Idee, verwendet aber keiner.

Spoiler: PCIe vergleich und anderes OT:

Also bitte
1. Der Sinn GDDR5 Speicher mit 256-512Bit der je nach Taktrate so zwischen 100 bis über 200 GByte/s erreicht und über PCIe 2.0 x16 mit 8 GByte/s (in beide Richtungen) für externen Zugriff angebunden ist mit DDR3 1600 der maximal 25,6 GByte/s erreicht zu vergleichen erschließt sich mir nicht.
2. Teilt sich die GPU den ganzen Spaß auch noch mit der CPU, die "normale Grafikkarte" hat die Ressourcen aber für sich alleine zur Verfügung.
3. Gab es schon Tests in denen der Speichertakt bei APU Systemen erhöht wurde, wodurch die Gesamt Performance leicht gestiegen ist. Wie soll dort also kein Flaschenhals vorliegen? Wenn nun zukünftige APU's den gleichen Speicher verwenden, die GPU&CPU teile aber an Performance zulegen der Flaschenhals größer werden sollte.
4. Wenn heutiger Speicher kein Flaschenhals ist, wieso Microns, Intels und HPs Initiative DDR Speichersystem Nachfolger zu Entwickeln?
(bspw. HMC)

1. Wenn die Speicherkopiererei zwischen CPU und Grafikkarte bei 8GByte/s kein Flaschenhals ist(was das Pcie 2.0 vs 3.0 zeigt) dann ist es auch im RAM der mit 25,6GByte/s angeschlossen ist kein Flaschenhals. Genau deswegen bringt sich das auch nichts.

2. Das ist kein Problem, in einem nicht-HSA System haben CPU und GPU halt ihren eigenen Bereich. Daten zwischen den Bereichen herumzuschieben geht trotzdem schneller als bei einer CPU und Grafikkarte weswegen wir wieder bei 1. sind.

3. Der Speicher ist ein Flaschenhals, aber nicht die Speicherkopiererei von CPU-RAM-Bereich zu GPU-RAM-Bereich. Letzteres Problem ist nämlich sequentiell, weswegen die CPU alles vor Verwendung in den Cache laden kann und keine Cache Misses auftreten.
Der Speicher ist aber nur dann ein Flaschenhals wenn es zu Cache Misses kommt und die CPU deswegen brach liegt, was zb. bei zufälligeren Zugriffen häufig stattfindet.

4. Ist er, aber nicht für sequentielle Zugriffe.

Und es ist immer noch Falsch HSA nur auf GPGPU zu beschränken, nimm dich doch mal dem HSA Konzept an anstatt Sachen zu behaupten die so nicht stimmen. AMD hat einen Windows 8 JPEG Dekoder gezeigt, der CPU+GPU teil von Kaveri nutzt, und halb solange brauch wie der Windows eigene. Und auch da kann ich nur sagen, warte erstmal die HSA Entwicklerplattform ab, benutze jene, dann kannst du aussagen darüber machen was Sache ist und was nicht, anstatt vermutungen Aufzustellen, die auf teilweise falschen Annahmen Fußen.

Schön, die Lösung von AMD greift aber nebst der CPU auch auf GPGPU zurück wie du selbst sagst. Dazu braucht man aber kein HSA. Auch ohne HSA sollte es kein Problem sein die Performance der AMD Implementierung zu erreichen.

Ja, und warum nutzt man solche Programmiersprachen? Weil die jeweilige Person lange nicht soviel wissen benötigt wie bei der vorherigen Sprache und jeder Fall schon "einfach Abstrahiert" ist(API Bauteile von Java). Das gleiche trifft aber genau so auf x86 zu. Ist nicht am Effizientesten, sondern am meisten "Kompatibel" und deckt einiges ab.

x86 bietet sowohl primitive Operationen die man sich auf einem RISC System erwarten würde, als auch Operationen für spezielle Aufgaben. Nur lassen sich diese komplexeren Operationen nicht durch die primitiveren Operationen ersetzen wenn man die gleiche Geschwindigkeit haben will.
Bei Programmiersprachen ist das genau anderstrum, dort bezahlt man mit Performance je abstrahierter man programmiert.

Nein, gesamt Betrachtet geht es um die Effiziente Verschmelzung von allen Einheiten in der APU, und das Aufgaben Sinnvoll abgearbeitet werden. Heute hat man eher das Problem, entweder ein Programm lässt sich garnicht oder nur mit Hindernissen auf der GPU Berechnen(teils Probleme mit Parallelisierung) oder aber da Programmiert jemand mit dem Ziel etwas NUR auf der GPU Auszuführen. Der Ideale weg ist aber, das die APU alles auf der Einheit Ausführt, auf der es am Besten möglich ist. Ein hindernis dabei ist ja durch hUMA bald beseitigt. Innerhalb eines Programm(ablaufs) können CPU und GPU dann auf die gleiche Adresse zugreifen und Schreiben. GCN war mit der Möglichkeit auf der GPU C++AMP und OpenCL Schnittstellen zu nutzen der erste Schritt.

Man braucht kein huma um CPU und GPU gleichzeitig rechnen zu lassen. Afair machen BOINC Clients das seit Beginn von GPGPU so.
Das Problem mit der Parallelisierung fällt auch mit huma und hsa nicht weg.

Nein, HSA ist das ganze Konzept. Darauf wurde die Hardware Angepasst, wobei hUMA der teil ist der sich um die von dir Angesprochenen Speicherprobleme kümmert, und nicht HSA Allgemein. HSA Allgemein sind Hardware und Software Spezifikationen/Standards/Paradigmen.
Daraus Resultierten Hardware Seitig die GCN(1.0/1.1/2.0) Ausbaustufen und Bald die erste richtige "vollwertige" HSA Apu Kaveri.
Software Seitig: HSA Entwicklerplattform, die Vermutlich auch Bolt, HSAIL, Standard Compiler usw. beinhalten. Mantle ist eher als Teilergebnis von HSA anzusehen.

Das Konzept ja, aber nicht die Architektur. Zu sagen ein x86 AMD Chip mit HSA und ein ARM Chip mit HSA hätten die gleiche Architektur wäre gleich wie zu sagen, ein Haus mit rotem Anstrich ist das gleiche Gebäude wie eine Brücke mit rotem Anstrich.
Die Implementation von HSA ist auf dem die nur ein kleiner Teil, die Architektur bleibt größtenteils wie sie ist.

BTW: HSA kommt garnicht auf die kleinen Dies von Mobile SoC's. Die News gab es auch hier bei CB. (Beema&Mullins)

Blöd das du vor ein paar Posts damit argumentieren wolltest, wie toll es doch ist dass die ganzen ARM-Lizenznehmer der HSA Foundation beigetreten sind.
Denn die machen nur solche kleinen Dies und das wird sich in den nächsten Jahren nicht großartig ändern.

Ich meinte auch die Software, nicht die Hardware. Die sollte nächsten Monat versendet werden. Die Softwareseitige Entwicklerplattform wird denke ich mal momentan noch mit den Kaveri ENG Samples "getestet", würde dann auch Zeitlich passen, Januar solls Kaveri im Handel geben, und Entwicklerplattform auch ab nächstes Jahr. Und vermutlich erst dann bekommt man auch die Vollständige Dokumentation usw. Wer weiß was die HSA Foundation Mitglieder jetzt schon zur Verfügung hat.

Ich behaupte, dass wenn die HW fertig ist und SW fast fertig ist, sich die Spezifikationen nicht mehr oder nur geringfügig ändern.

Und das Intel Dokument: Soweit ich das sehe ist ab Seite 100 von SSE, AVX128, AVX256 und AVX512 die Rede.

Der Eindruck entsteht dadurch, dass die AVX512 Befehle eventuell gleich heißen wie AVX&SSE Befehle und sich nur die Operanden ändern. Dann werden natürlich alle möglichen Operanden-Kombinationen mitangegeben, auch SSE und AVX. Zu jedem aufgeführten mnemonic gibt es aber eine/mehrere entsprechende AVX512 Operationen.
Desweiteren wurde AVX512 so integriert, dass es zu keinen Performanceproblemen führt wenn man AVX512 mit AVX oder SSE mischt. Deswegen gibt es auch eine Menge Befehle bei denen es um die Interaktion zwischen AVX512 und AVX/SSE geht.

 

[Dystop1an]

Natürlich kann man Optimierungen in Libraries und APIs reinziehen und erreicht so ein höheres Publikum. Nur müssen die entsprechenden Softwareentwickler das auch nützen. Auf den Konsolen nicht ganz unwahrscheinlich.
Auf dem PC und sonstwo hingegen schon, denn dort gibt es fast keine Entwickler die AMD spezifische APIs/Libs verwenden.

Wenn man sich dagegen anschaut, dass man bis zu 20% Mehrleistung durch Mantle kriegt(laut Thief Entwickler), dafür aber Mantle zusätzlich zu D3D oder OGL verwenden muss, was ziemlich viel Aufwand bedeutet.

Das ist aber wiedereinmal nur eine Vermutung deinerseits. Das Verhalten der Entwickler mit bspw. Mantle widerspricht dem aber ganz Entsprechend. Rebellion hat nun als 3 Partei im Bunde, nach Dice mit Frostbite 3 Engine und Oxide Games mit Nitrous Engine, bekannt gegeben ebenfalls in seiner Spiel Engine "Asura" Mantle zu Unterstützen. Damit ist doch eindeutig ein klarer Trend zu erkennen, den man nunmal nicht leugnen kann.

Spoiler: OT

3. Der Speicher ist ein Flaschenhals, aber nicht die Speicherkopiererei von CPU-RAM-Bereich zu GPU-RAM-Bereich. Letzteres Problem ist nämlich sequentiell, weswegen die CPU alles vor Verwendung in den Cache laden kann und keine Cache Misses auftreten.
Der Speicher ist aber nur dann ein Flaschenhals wenn es zu Cache Misses kommt und die CPU deswegen brach liegt, was zb. bei zufälligeren Zugriffen häufig stattfindet.

Und trotzdem, wenn durch Speicherkopiererei was kein Flaschenhals darstellt, der Speicher der ein Flaschenhals ist zusätzlich belastet wird, kommt es zu Performance Einbrüchen. Dadurch das durch hUMA weniger Kopiert wird, steht in dem Moment auch mehr Speicherbandbreite für andere Zwecke zur Verfügung. Ich hab an keiner Stelle behauptet das der Kopier Vorgang an sich einen Flaschenhals darstellt.

Man braucht kein huma um CPU und GPU gleichzeitig rechnen zu lassen.

Habe ich auch nicht behauptet, lies doch nochmal das was du da Zitiert hast. hUMA hat EIN Hindernis behoben, und zwar das bei Programmen die CPU&GPU gleichzeitig nutzen der Entwickler sich umständliches hin und her Kopieren sparen kann, und er direkt auf Gemeinsame Ressourcen zugreifen kann. Ansonsten bringt es ja nicht viel, wenn sich beide Einheiten ergänzen würden, aber dann für jeden furz eine Kopieroperation stattfinden muss weil die GPU nicht auf das Ergebnis von der CPU zugreifen kann.

Das Konzept ja, aber nicht die Architektur. Zu sagen ein x86 AMD Chip mit HSA und ein ARM Chip mit HSA hätten die gleiche Architektur wäre gleich wie zu sagen, ein Haus mit rotem Anstrich ist das gleiche Gebäude wie eine Brücke mit rotem Anstrich.
Die Implementation von HSA ist auf dem die nur ein kleiner Teil, die Architektur bleibt größtenteils wie sie ist.

Und auch das habe ich nicht geschrieben, in dem Zitat steht nichts von Architektur. In deinem Satz davor stand allerdings:

HSA ist nur der Teil in CPU&GPU der dafür sorgt dass keine Fehler entstehen wenn CPU & GPU auf die gleichen Daten zugreifen.

Und das stimmt nunmal nicht, was du da nennst ist wieder nur ein teil von HSA.

Blöd das du vor ein paar Posts damit argumentieren wolltest, wie toll es doch ist dass die ganzen ARM-Lizenznehmer der HSA Foundation beigetreten sind.
Denn die machen nur solche kleinen Dies und das wird sich in den nächsten Jahren nicht großartig ändern.

Was ist mit den Ankündigungen seitens Qualcomm, Samsung, Texas Instruments und AMD Server Chips auf ARM Basis nächstes Jahr anbieten zu wollen? Die werden dann nichtmehr ganz so klein wie die Mobile SoC's.
Blöd aber das du in den letzten Post's Argumentiert hast das HSA nur die Referenzierung von CPU&GPU ist. Dann dürfte die DIE Size ja eigentlich nicht wirklich steigen.

Ich behaupte, dass wenn die HW fertig ist und SW fast fertig ist, sich die Spezifikationen nicht mehr oder nur geringfügig ändern.

Würde ich auch sagen, und in dem Zitat steht auch nichts von Änderungen an den Spezifikationen. Sondern das die Vollständige Dokumentation von AMD erst kommt, wenn man seine dazugehörige Software und die Software der Drittanbieter genug getestet hat und die meisten Fehler ausgebügelt worden sind.

Also warte doch einfach die Entwicklerplattform ab, dann kannst du immernoch Aussagen dazu tätigen, die man dann sogar mit Fakten untermauern kann, oder auch nicht.