Vielleicht interessiert es ja (noch) jemanden:
Interessant. Ist wohl etwas ähnliches wie das bzw scheint vielleicht sogar das selbe zu sein :
https://code.google.com/p/aparapi/
Wollte mich da auch ein mal einlesen leider momentan nicht so viel Zeit.
Ja, Aparapi wird schon eine ganze Weile entwickelt. Der Hauptentwickler von Aparapi ist auch in der „Sumatra“-Gruppe, die sich um diesen Task kümmert. (Was der wegschafft :eek: ). Das, was da im Moment in Sumatra gemacht wird, ist dementsprechend stark von Aparapi geprägt. Aber jetzt soll die Funktionalität, die es in Aparapi schon gibt, „tiefer“ in den Hotspot eingeflochten werden (also dass der ganze Kram nicht „manuell“ oder zur Compilezeit compiliert wird, sondern dass der JIT das übernimmt). Das ganze ist natürlich nicht vollkommen trivial 
aber es gibt schon Vorarbeiten von verschiedenen Stellen, und … das rüttelt sich wohl langsam fest 
Also HSA ist ja erstmal nur für AMD cpus mit integrierter GPU verfügbar. Ich glaube nicht das irgendeine externe Grafikarte ob von AMD oder Nvidia bzw. Intel HSA unterstützt. Pläne bezüglich Umsetzung von OpenCL kann ich nicht finden.
Also erstmal ernüchtern. Lohnen tut sich das ganze dann für einen sehr sehr geringen Teil aller PC Nutzer.
Ansonsten ist das natürlich eine Klasse idee. Aber irgendwie erschreckend was da so alles im Hintergrund passiert und natürlich auch mögliche Fehlerursachen sein könnte.
Nun, HSA ist eigentlich ein offener Industriestandard - gepusht von AMD und anderen, aber dass NVIDIA gerne sein CUDA-Monopol aufrechterhalten will, ist ja klar 
Inwieweit das ganze dann „offen“ von/nach OpenCL übersetzt werden kann, ist nochmal eine andere Frage, aber es gibt keinen Grund anzunehmen, dass der Hotspot dann NUR für AMD-CPUs/GPUs compilieren kann: Die HSAIL in den jeweiligen Maschinencode zu übersetzen ist Sache des Hardwareherstellers, und ich könnte mir vorstellen, dass es ab einem gewissen Punkt schwierig wird, da NICHT mit aufzuspringen.
Moin,
ich hab mich mit HSA und der Parallel Stream API noch nicht sonderlich tief gehend befasst, deshalb mag es sein, dass ich vollkommen falsch liege, aber:
Ist ein zentraler Punkt bei HSA nicht, dass CPU und GPU relativ “dicht” bei einander liegen? Im Idealfall sogar auf den gleichen Speicher zugreifen und dabei ähnliche Zugriffszeiten haben? Gerade das dürfte Sumatra vereinfachen. Wenn CPU und GPU auf den gleichen Daten mit gleichen Zugriffszeiten arbeiten, lohnt es sich auch etwas einfaches wie eine Vektoraddition von der GPU berechnen zu lassen.
Wenn die Daten hingegen erst zweimal über den Bus müssen, lohnt es imho nicht mehr. Und gerade bei den dicken GPU Brummern, ist es nun mal so, dass sie mit eigenem Speicher und weitgehend unabhängig vom Rest des Rechners arbeiten. Zudem ist die Anbindung an den Rechner relativ “langsam”. Das macht es imho wesentlich schwieriger.
Die einzige Möglichkeit das Potenzial von dedizierten Grafikkarten auszunutzen ist imho das Problem ganz auf die Grafikkarte zu übertragen und komplett dort zu bearbeiten. Erst das Ergebnis kommt dann zurück zur CPU. Und dabei weiß ich nicht, ob die Parallel Stream API dazu mächtig genug ist. Lässt sich zum Beispiel damit formulieren das man gerne 1000 Iterationen von Game of Life hätte, ohne das der nach jeder Iteration Daten zur CPU synchronisiert? Oder lässt sich z. B. ein Runge Kutta komplett mit der Stream API abbilden, ohne das da (CPU-) synchronisierende Elemente dazwischenfunken?
Alles was ich bisher gesehen habe, waren trivial Beispiele, die aber imho nicht zur Arbeitsweise von dedizierten Grafikkarten passen. Und die derzeit erhältlichen HSA fähigen APUs sind imho so langsam das sie wohl niemand kaufen würde, der wirklich Performance braucht.
Viele Grüße
Fancy
Zugegeben, bei den technischen Details bin ich auch nicht so weit drin (wie ich sein sollte?). Aber…
- ich bin nicht sicher, ob die Ausrichtung auf HSA einen “harten Constraint” darstellt (oder ob das ganze nicht optional auch auf Architekturen mit verschiedenen Speicherbereichen übersetzt werden kann)
- ich gehe davon aus, dass die GPU und die CPU zusammenwachsen werden. Natürlich kann man auch davon ausgehen, dass NVIDIA und Intel da etwas bedröppelt aus der Wäsche schauen (weil nur AMD (“gute”) GPUs UND x86er herstellen kann), aber das wird sich sicher regeln.
Unabhängig davon glaube ich, das das etwas abstrakter und weiter gefasste Ziel von Sumatra formuliert werden könnte als: “Die Übersetzung von Java (zur Laufzeit!) in eine Intermediate-Sprache (HSAIL), die dann hochoptimiert auf die jeweilige Zielhardware gemappt wird”. Ja, das ist jetzt SO abstrakt, dass man meinen könnte, dass das “einfach nur der JIT” ist, aber es geht eben schon darüber hinaus…
Die HSA Architektur ist in erster Linie dazu gedacht unnötiges Kopieren von Daten zu verhindern. Dazu können CPU und GPU (oder eben beide Teile eine APU) nicht nur auf den selben Speicherbereich zugreifen, sondern dazu auch den selben Pointer benutzen. Entsprechend entfällt das von GKs bekannte, übliche Kopieren der Daten was für eine schnellere Abarbeitung sorgt. Dies kann der verfügbare HSA Emulationstreiber derzeit simulieren, indem er transparent die Daten kopiert und den Pointer ändert, dafür eben langsamer als HSA native Hardware.
Sumatra ist derzeit besonders für die Stream API gedacht, da hier nur Probleme mit abgehandelt werden, die sich extrem gut parallelisieren lassen. Dann wird der Java Bytecode per Graal in die HSAIL übersetzt (die Intermediate Language für HSA) und von dort entsprechend in den entsprechenden Code welcher vom Backend benötigt wird. Da können später theoretisch auch CUDA und OpenCL hinter liegen.
Die Idee von Sumatra ist halt am Ende automatisch parallelisierbare Vorgänge zu finden und entsprechend auf die GPU auszulagern, transparent, ohne das der Entwickler sich darum kümmern muss.
PS: Nicht wundern, ich experimentiere derzeit damit rum, da ich unter anderem gefragt wurde ob ich nicht mit daran basteln will, da ich mich ja eh dafür interessiere
Ist dann der Emulationstreiber nicht auch eine art “VM” ? Theoretisch müsste doch HSAIL für CPU und GPU entsprechenenden Code erstellen können. Dem Emulationstreiber sollte es also herzlich egal sein worauf er den Code übersetzt.
*** Edit ***
Edit gerade gefunden:
Der Treiber simuliert nur die native Hardware HSA Unterstützung (also Memory Copy und Pointer Rewrite), für die Übersetzung von HSAIL in GPU Code ist der Treiber zuständig.