AMD präsentiert HSA-Details auf der Hot Chips 25 [Update]

Auf der gerade stattfindenden Hot-Chips-Konferenz hat AMD in Zusammenarbeit mit den HSA-Partnern Qualcomm und ARM Details zur ihrer gemeinsamen heterogenen Systemarchitektur (HSA) preisgegeben. Die Grundlagen von HSA sind schon seit deren Gründung 2012 bekannt, ein Eckpfeiler der Architektur ist u.a. die Unterstützung von gemeinsam benutztem, heterogenen Systemspeicher, der unter dem Schlagwort hUMA beworben wird. Aktuell ist der Begriff aufgrund der eventuellen hUMA-Unterstützung der PS4 im Gespräch. In der Präsentation wurde anfangs durch AMDs Fellow und HSA-Präsidenten Phil Rogers nochmals die oberste HSA-Ebene erklärt:

Gemeinsamer Adressraum quer über alle eingesetzten Prozessoren des HSA-SoCs: Der GPU-Compute-Prozessor nutzt die gleichen Adressen und Pointer wie die CPU.
Mögliches Nutzen einer Speicher-Auslagerungsdatei auf der Festplatte.
Speicherkohärenz: Alle Threads können auf die Ergebnisse anderer Threads zugreifen.
User Mode Dispatch: Applikationen und Bibliotheken können die Hardware direkt, ohne Umweg über Treiberroutinen, nutzen.
Architected queuing language: Rechenpakete für GPU-Compute haben ein identisches, hardware-unabhängiges Format.
Hochsprachenunterstützung für GPU-Compute (Java, C++, etc.)
Preemption und Kontextswitching: Aufgrund des höheren Nutzungsgrads durch viele Threads werden Zeitscheibenmodelle auch für die GPU benötigt.

Wie man also sieht, ist HSA unabhängig von speziellem Maschinencode wie x86 oder ARMv8, stattdessen gibt es eine Zwischenschicht namens HSAIL (HSA Intermediate Layer), d.h. Programmcode wird mittels eines Echtzeit-Compilers auf die entsprechende Zielplattform übersetzt. Schließlich ging es dann in den Praxisteil über. Den Anfang machte die Planung zu AMDs Aparapi. Dieses Softwaretool gibt es seit 2012 und ermöglicht es, Java-Applikationen auf GPUs laufen zu lassen. Für die im Jahre 2015 geplante Java-Version 9 ist erstmals eine vollständige Integration in die JVM mit dem Codenamen “Sumatra” vorgesehen:

Kernpunkt der Unterstützung ist der bei Java 8 eingeführte Lambda-Ausdruck. Verwendet man diesen bereits in seinem Java-Code, so wird Java 9 automatisch Teile davon auf der GPU ausführen können. Anschließend wurden Leistungsbeispiele gebracht. So kann man bei Algorithmen zur Gesichtserkennung, die in mehreren Stufen (im Beispiel 22) erfolgen, durch die abwechselnden Berechnungen auf CPU und GPU eine Leistungsverbesserung bzw. eine Energiekostenminderung um den Faktor 2,5 ermöglichen:

Wie man dem obigen Bild entnehmen kann, ist das Leistungsmaximum der APU bei Auslagerung der ersten drei Berechnungsschritten auf die GPU erreicht. Der Rest der Schritte wird dann auf der CPU ausgeführt, da der Parallelisierungsgrad stark abnimmt. Während die CPU also den Ausschnitt zu Ende rechnet, beginnt die GPU mit den Berechnungsschritten des nächsten Bildausschnitts. Exklusives Rechnen auf der CPU (blau, links) bzw. GPU (grau, rechts) liefert jeweils eine schlechtere Leistung. Während die wenigen CPU-Kerne anfangs mit der Datenmenge überfordert sind, bricht die GPU in den hinteren Berechnungsstufen aufgrund der stark gesunkenen Threadanzahl und ihrer geringen Single-Thread-Leistung ein. Ein kombinierter Ansatz ist somit die Ideallösung. Neben diesem bereits früher gezeigten Beispiel gab es auch noch andere, ebenfalls schon bekannte Fälle. Als neu fiel dagegen der Anwendungsfall “Gameplay Rigid Body Physics” auf, der mit an Sicherheit grenzenden Wahrscheinlichkeit aus der Zusammenarbeit mit den Spielekonsolenherstellern entstammen dürfte, schließlich ist zumindest Sony offizielles Mitglied der HSA-Foundation. Zuerst eine Übersichtsfolie als Einsteig:

Wie man sieht, wird die realistische (physikalische) Starrkörperanimation bisher nur in Effekten, aber nicht direkt im Spiel als Interaktion genutzt. Auf der nächsten Seite wird erklärt, wie der Algorithmus funktioniert. Zuerst laufen drei Phasen der Kollisionserkennung, dann werden die Kontaktpunkte berechnet, danach die Einschränkungen gelöst:

Die nächsten beiden Folien liefern dann allgemeine Gründe, wieso HSA bzw. hUMA Vorteile bei der Verwendung mit Starrkörpern und deren realistischer Animation und Interaktion bringt:

Zusammenfassend kann man sagen, dass HSA v.a. Vorteile bei vielen, interaktiven Objekten bietet, da der gesamte Speicherraum und nicht nur das begrenzte VRAM zur Verfügung stehen. Außerdem kann durch eine verbesserte Kooperation zwischen CPU und GPU eine höhere Bildwiederholrate garantiert werden. Fazit: Die Möglichkeiten von HSA sind vielversprechend, aber langsam sollten den Worten auch Taten in Form von funktionstüchtiger und kaufbarer Hardware folgen. Dass AMD hinter dem Zeitplan liegt, sieht man schon allein an dem Umstand, dass die Präsentation nur wenig Neues enthielt. Vieles stammte aus einer früheren Präsentation des letzten Jahres: ARM Techcon Keynote 2012. Aber immerhin, die Softwareentwickler scheinen sich durch den zögerlichen Hardwarestart nicht aus dem Rhythmus bringen zu lassen und die Spielekonsole(n) scheinen eine treibende Kraft zu sein. Je später die Hardware am Ende erscheint, desto größer wird die Softwareauswahl sein. Zum Abschluss alle Folien in der Übersicht:

[Zeige eine Slideshow]