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

Auf der gera­de statt­fin­den­den Hot-Chips-Kon­fe­renz hat AMD in Zusam­men­ar­beit mit den HSA-Part­nern Qual­comm und ARM Details zur ihrer gemein­sa­men hete­ro­ge­nen Sys­tem­ar­chi­tek­tur (HSA) preis­ge­ge­ben. Die Grund­la­gen von HSA sind schon seit deren Grün­dung 2012 bekannt, ein Eck­pfei­ler der Archi­tek­tur ist u.a. die Unter­stüt­zung von gemein­sam benutz­tem, hete­ro­ge­nen Sys­tem­spei­cher, der unter dem Schlag­wort hUMA bewor­ben wird. Aktu­ell ist der Begriff auf­grund der even­tu­el­len hUMA-Unter­stüt­zung der PS4 im Gespräch. In der Prä­sen­ta­ti­on wur­de anfangs durch AMDs Fel­low und HSA-Prä­si­den­ten Phil Rogers noch­mals die obers­te HSA-Ebe­ne erklärt:

  • Gemein­sa­mer Adress­raum quer über alle ein­ge­setz­ten Pro­zes­so­ren des HSA-SoCs: Der GPU-Com­pu­te-Pro­zes­sor nutzt die glei­chen Adres­sen und Poin­ter wie die CPU.
  • Mög­li­ches Nut­zen einer Spei­cher-Aus­la­ge­rungs­da­tei auf der Festplatte.
  • Spei­cher­ko­hä­renz: Alle Threads kön­nen auf die Ergeb­nis­se ande­rer Threads zugreifen.
  • User Mode Dis­patch: Appli­ka­tio­nen und Biblio­the­ken kön­nen die Hard­ware direkt, ohne Umweg über Trei­ber­rou­ti­nen, nutzen.
  • Archi­tec­ted queu­ing lan­guage: Rechen­pa­ke­te für GPU-Com­pu­te haben ein iden­ti­sches, hard­ware-unab­hän­gi­ges Format.
  • Hoch­spra­chen­un­ter­stüt­zung für GPU-Com­pu­te (Java, C++, etc.)
  • Pre­emp­ti­on und Kon­texts­wit­ching: Auf­grund des höhe­ren Nut­zungs­grads durch vie­le Threads wer­den Zeit­schei­ben­mo­del­le auch für die GPU benötigt.

Wie man also sieht, ist HSA unab­hän­gig von spe­zi­el­lem Maschi­nen­code wie x86 oder ARMv8, statt­des­sen gibt es eine Zwi­schen­schicht namens HSAIL (HSA Inter­me­dia­te Lay­er), d.h. Pro­gramm­code wird mit­tels eines Echt­zeit-Com­pi­lers auf die ent­spre­chen­de Ziel­platt­form über­setzt. Schließ­lich ging es dann in den Pra­xis­teil über. Den Anfang mach­te die Pla­nung zu AMDs Apa­ra­pi. Die­ses Soft­ware­tool gibt es seit 2012 und ermög­licht es, Java-Appli­ka­tio­nen auf GPUs lau­fen zu las­sen. Für die im Jah­re 2015 geplan­te Java-Ver­si­on 9 ist erst­mals eine voll­stän­di­ge Inte­gra­ti­on in die JVM mit dem Code­na­men “Suma­tra” vorgesehen:

19hc25_hsa

Kern­punkt der Unter­stüt­zung ist der bei Java 8 ein­ge­führ­te Lamb­da-Aus­druck. Ver­wen­det man die­sen bereits in sei­nem Java-Code, so wird Java 9 auto­ma­tisch Tei­le davon auf der GPU aus­füh­ren kön­nen. Anschlie­ßend wur­den Leis­tungs­bei­spie­le gebracht. So kann man bei Algo­rith­men zur Gesichts­er­ken­nung, die in meh­re­ren Stu­fen (im Bei­spiel 22) erfol­gen, durch die abwech­seln­den Berech­nun­gen auf CPU und GPU eine Leis­tungs­ver­bes­se­rung bzw. eine Ener­gie­kos­ten­min­de­rung um den Fak­tor 2,5 ermöglichen:

29hc25_hsa

Wie man dem obi­gen Bild ent­neh­men kann, ist das Leis­tungs­ma­xi­mum der APU bei Aus­la­ge­rung der ers­ten drei Berech­nungs­schrit­ten auf die GPU erreicht. Der Rest der Schrit­te wird dann auf der CPU aus­ge­führt, da der Par­al­le­li­sie­rungs­grad stark abnimmt. Wäh­rend die CPU also den Aus­schnitt zu Ende rech­net, beginnt die GPU mit den Berech­nungs­schrit­ten des nächs­ten Bild­aus­schnitts. Exklu­si­ves Rech­nen auf der CPU (blau, links) bzw. GPU (grau, rechts) lie­fert jeweils eine schlech­te­re Leis­tung. Wäh­rend die weni­gen CPU-Ker­ne anfangs mit der Daten­men­ge über­for­dert sind, bricht die GPU in den hin­te­ren Berech­nungs­stu­fen auf­grund der stark gesun­ke­nen Thre­a­d­an­zahl und ihrer gerin­gen Sin­gle-Thread-Leis­tung ein. Ein kom­bi­nier­ter Ansatz ist somit die Ide­al­lö­sung. Neben die­sem bereits frü­her gezeig­ten Bei­spiel gab es auch noch ande­re, eben­falls schon bekann­te Fäl­le. Als neu fiel dage­gen der Anwen­dungs­fall “Game­play Rigid Body Phy­sics” auf, der mit an Sicher­heit gren­zen­den Wahr­schein­lich­keit aus der Zusam­men­ar­beit mit den Spie­le­kon­so­len­her­stel­lern ent­stam­men dürf­te, schließ­lich ist zumin­dest Sony offi­zi­el­les Mit­glied der HSA-Foun­da­ti­on. Zuerst eine Über­sichts­fo­lie als Einsteig:

35hc25_hsa

Wie man sieht, wird die rea­lis­ti­sche (phy­si­ka­li­sche) Starr­kör­per­ani­ma­ti­on bis­her nur in Effek­ten, aber nicht direkt im Spiel als Inter­ak­ti­on genutzt. Auf der nächs­ten Sei­te wird erklärt, wie der Algo­rith­mus funk­tio­niert. Zuerst lau­fen drei Pha­sen der Kol­li­si­ons­er­ken­nung, dann wer­den die Kon­takt­punk­te berech­net, danach die Ein­schrän­kun­gen gelöst:

36hc25_hsa

Die nächs­ten bei­den Foli­en lie­fern dann all­ge­mei­ne Grün­de, wie­so HSA bzw. hUMA Vor­tei­le bei der Ver­wen­dung mit Starr­kör­pern und deren rea­lis­ti­scher Ani­ma­ti­on und Inter­ak­ti­on bringt:

37hc25_hsa
38hc25_hsa

Zusam­men­fas­send kann man sagen, dass HSA v.a. Vor­tei­le bei vie­len, inter­ak­ti­ven Objek­ten bie­tet, da der gesam­te Spei­cher­raum und nicht nur das begrenz­te VRAM zur Ver­fü­gung ste­hen. Außer­dem kann durch eine ver­bes­ser­te Koope­ra­ti­on zwi­schen CPU und GPU eine höhe­re Bild­wie­der­hol­ra­te garan­tiert wer­den. Fazit: Die Mög­lich­kei­ten von HSA sind viel­ver­spre­chend, aber lang­sam soll­ten den Wor­ten auch Taten in Form von funk­ti­ons­tüch­ti­ger und kauf­ba­rer Hard­ware fol­gen. Dass AMD hin­ter dem Zeit­plan liegt, sieht man schon allein an dem Umstand, dass die Prä­sen­ta­ti­on nur wenig Neu­es ent­hielt. Vie­les stamm­te aus einer frü­he­ren Prä­sen­ta­ti­on des letz­ten Jah­res: ARM Tech­con Key­note 2012. Aber immer­hin, die Soft­ware­ent­wick­ler schei­nen sich durch den zöger­li­chen Hard­ware­start nicht aus dem Rhyth­mus brin­gen zu las­sen und die Spielekonsole(n) schei­nen eine trei­ben­de Kraft zu sein. Je spä­ter die Hard­ware am Ende erscheint, des­to grö­ßer wird die Soft­ware­aus­wahl sein. Zum Abschluss alle Foli­en in der Übersicht:

Update 27.08.2013: Der Bil­der­ga­le­rie wur­den noch eini­ge Foli­en von PC Watch hinzugefügt.

Pro­gram­mier­links: