SC16: AMD stellt Open-Source-Programmierplattform ROCm 1.3 für GPU-Beschleuniger vor

Artikel-Index:

Vor einem Jahr stell­te AMD mit Blick auf Hypers­ca­le Com­pu­ting die Boltz­mann-Initia­ti­ve auf der SC15 vor, die im Wesent­li­chen aus zwei Aspek­ten besteht. Zum einen soll für Ent­wick­ler ein Soft­ware­öko­sys­tem mit den not­wen­di­gen Tools erschaf­fen wer­den, um CPUs effi­zi­ent zusam­men mit GPUs als Beschleu­ni­gern nut­zen zu kön­nen. Zum ande­ren wird mit HIP (Hete­ro­ge­ne­ous-Com­pu­te Inter­face for Por­ta­bi­li­ty) ein mög­lich ein­fa­cher Por­tie­rungs­weg für bestehen­den CUDA-Code gebo­ten, von wo aus GPUs sowohl von AMD (via Hete­ro­ge­ne­ous Com­pu­te Com­pi­ler, kurz HCC) als auch NVIDIA (via NVIDIA CUDA Com­pi­ler, kurz NVCC) genutzt wer­den kön­nen. Dar­aus her­vor­ge­gan­gen ist die Rade­on Open Com­pu­te Plat­form oder kurz ROCm, die spe­zi­ell auf gro­ße Rechen­sys­te­me (Super­com­pu­ter) abzielt. Kon­se­quen­ter­wei­se setzt die Platt­form auf 64-Bit-Linux als Betriebs­sys­tem, was in die­sem Umfeld De-fac­to-Stan­dard ist, und Open Source. Sämt­li­che Tei­le von ROCm wer­den unter MIT-Lizenz auf Git­Hub der brei­ten Öffent­lich­keit zur Ver­fü­gung gestellt. AMD ver­spricht sich hier­von schnel­le­re Fort­schrit­te bei der Ent­wick­lung des Soft­ware-Stacks. Kun­den pro­fi­tie­ren nicht nur von bes­se­ren Kom­mu­ni­ka­ti­ons- und Inter­ak­ti­ons­mög­lich­kei­ten mit den Ent­wick­lern, son­dern kön­nen den Code auch viel ein­fa­cher auf die eige­nen Bedürf­nis­se anpas­sen. ROCm ist qua­si das Gegen­stück zu GPUO­pen, wel­ches in ers­ter Linie auf Ent­wick­ler von Com­pu­ter­spie­len abzielt.

Wie passt nun das zuvor so oft ver­wen­de­te Akro­nym HSA (Hete­ro­ge­ne­ous Sys­tem Archi­tec­tu­re) ins Bild? Die HSA-Spe­zi­fi­ka­ti­on, die von AMD gemein­sam mit ande­ren Fir­men über die HSA Foun­da­ti­on ent­wi­ckelt wur­de, defi­niert Anfor­de­run­gen an die Hard­ware, wel­che die Pro­gram­mie­rung hete­ro­ge­ner Sys­te­me ver­ein­fa­chen sol­len (z. B. Sha­red Vir­tu­al Memo­ry, Signa­le, Paket­for­ma­te, Com­mand-Queue Inter­faces und Con­text Swit­ching). HSA defi­niert also die Hard­ware­ba­sis, wel­che für ROCm not­wen­dig ist. Die ROCr-API ist im Kern die HSA-Run­ti­me, die mit Erwei­te­run­gen für dis­kre­te GPUs und Peer-to-Peer-Kom­mu­ni­ka­ti­on zwi­schen den GPUs (inner­halb eines Kno­tens oder zwi­schen den Kno­ten eines Racks per RDMA oder Infi­ni­Band) ver­se­hen wur­de.

Sämt­li­che Trei­ber wur­den mit Blick auf Latenz­re­du­zie­rung und Durch­satz­op­ti­mie­rung (ohne Rück­sicht auf Lega­cy-Kom­pa­ti­bi­li­tät) von Grund auf neu ent­wi­ckelt und für die Nut­zung meh­re­rer Beschleu­ni­ger pro Kno­ten und ver­teilt über das Rack aus­ge­legt. Wich­tig ist auch, dass die­se head­less, also ohne an die Gra­fik­kar­te ange­schlos­se­nen Moni­tor, betrie­ben wer­den kön­nen. Die Peer-to-Peer-Kom­mu­ni­ka­ti­on mit RDMA inner­halb eines Kno­tens und/oder Racks wur­de von Anfang an ein­ge­plant. Zudem exis­tiert die frü­he­re Limi­tie­rung auf 2 oder 4 GiB Gra­fik­spei­cher pro Allo­ka­ti­on nicht län­ger. Mit dem neu­en Soft­ware-Stack lässt sich nahe­zu der gesam­te vor­han­de­ne Gra­fik­spei­cher für eine ein­zi­ge Allo­ka­ti­on nut­zen. Außer­dem kann man per GCNI­SA-Assem­bler und -Dis­as­sem­bler soge­nann­ten Hot Code (hier wird die meis­te Rechen­zeit ver­bra­ten) opti­mie­ren.
Neben HIP als wich­ti­gen Weg für bestehen­den Code bie­tet AMD aber über ROCm auch die Mög­lich­keit, einen ein­zi­gen gro­ßen ISO-C++-Quelltext zur Pro­gram­mie­rung von CPUs und GPUs zu ver­wen­den. Hier­für fin­det dann der HCC Anwen­dung. Für die Aus­la­ge­rung der Berech­nun­gen kann OpenMP 4.5 ver­wen­det wer­den. Zudem bie­tet der neue Stan­dard C++ 17 über Par­al­lel STL neue Mög­lich­kei­ten, Par­al­le­li­tät auch für Beschleu­ni­ger aus­zu­drü­cken. Python ist wich­tig im Feld Data Sci­ence, spe­zi­ell im Feld maschi­nel­les Ler­nen. Für die Aus­wer­tung von gro­ßen Daten­men­gen kommt zumeist Python zum Zuge. Hier wird der Ein­satz von GPUs als Beschleu­ni­ger mit Hil­fe des Com­pi­lers NUMBA rea­li­siert, was vom Ent­wick­ler Con­ti­nu­um Ana­ly­tics, Inc. aus Aus­tin bei­gesteu­ert wird und fort­an Teil von ROCm ist.

Auf der SC16 in Salt Lake City stellt AMD die Ver­si­on ROCm 1.3 offi­zi­ell vor, mit der die aktu­el­le Pola­ris-Archi­tek­tur und LLVM als Nati­ve Com­pi­ler unter­stützt wer­den. Eine wich­ti­ge Neue­rung mit Blick auf Machi­ne-Lear­ning-Anwen­dun­gen ist die Com­pi­ler-sei­ti­ge Unter­stüt­zung für Float16 und Integer16, was von den neu­es­ten GPUs hard­ware­sei­tig unter­stützt wird und die Beschleu­ni­gung ent­spre­chen­der Anwen­dun­gen nahe­zu um den Fak­tor zwei erlaubt. Außer­dem haben sämt­li­che Bestand­tei­le des ROCm-Soft­ware-Stacks Updates erfah­ren. Genaue­re Infor­ma­tio­nen hier­zu kön­nen den Foli­en ent­nom­men wer­den. Die Ver­öf­fent­li­chung einer Win­dows-Ver­si­on ist im Übri­gen aktu­ell nicht geplant, aber auch nicht für alle Zei­ten aus­ge­schlos­sen.

Wei­te­re Infor­ma­ti­on sowie der Quell­text zu ROCm las­sen sich hier fin­den. Auf den nach­fol­gen­den Foli­en gibt AMD zudem einen klei­nen Aus­blick, wie die wei­te­re Ent­wick­lung von ROCm aus­se­hen soll. Hier liegt der Fokus in zuneh­men­den Maße nicht mehr auf den mathe­ma­ti­schen Basis­bi­blio­the­ken, son­dern auf für bestimm­te Anwen­dun­gen spe­zia­li­sier­ten. Zudem erhält Open­CL eini­ge neue Fea­tures, über ein Plugin bereit­ge­stellt, wel­che von der Hard­ware unter­stützt wer­den, aber eben nicht vom Open­CL-Stan­dard.

Auf Sei­ten der Hard­ware wer­den von AMD offi­zi­ell nicht nur die teu­ren Pro­fi­lö­sun­gen Rade­on Pro WX und Fire­Pro unter­stützt, son­dern auch als Ein­stiegs­lö­sung bei­spiels­wei­se für Stu­den­ten die aktu­el­len Rade­on RX 400.

CPU-sei­tig soll ROCm neben der Unter­stüt­zung für x86-CPUs, zu denen auch bereits die kom­men­den Zen-Pro­zes­so­ren gehö­ren, auch auf ARM- und Power8-Sys­te­men lau­fen. Hin­sicht­lich der Inter­con­nect-Tech­no­lo­gi­en setzt AMD aktu­ell nicht auf ein ein­zel­nes Pferd, son­dern hat sich gleich bei drei Kon­sor­ti­en ein­ge­bracht. Hier­zu gehö­ren GenZ (Spei­cher-Inter­con­nect auf Rack-Ebe­ne), CCIX (Host I/O, P2P-Acce­le­ra­tor-Lösung) und Open­CA­PI (Host I/O, von IBM für Power8 gepusht, jetzt in Hän­den eines Kon­sor­ti­ums, zu des­sen füh­ren­den Mit­glie­dern neben IBM, Goog­le, Micron und Mel­lanox auch AMD gehört). Als Ziel gel­ten 25 GBit/s pro Lane Band­brei­te. Zum Ver­gleich: Das aktu­el­le PCI Express 3.0 schafft der­zeit 8 GBit/s pro Lane und Rich­tung und der Nach­fol­ger PCI Express 4.0 16 GBit/s. Mit die­sen Tech­no­lo­gi­en lie­ßen sich sämt­li­che Inter­con­nect-Topo­lo­gi­en abde­cken, die übli­cher­wei­se Anwen­dung fin­den. Inter­es­sant ist an die­ser Stel­le, dass Intel bei GenZ und Open­CA­PI, NVIDIA bei GenZ und ARM bei Open­CA­PI feh­len, ARM jedoch bei GenZ mit­mischt.

Auf der nächs­ten Sei­te fin­det ihr sämt­li­che Foli­en als Gale­rie.

» Alle Foli­en