Seminar - Hochleistungsrechner: Aktuelle Trends und

Entwicklungen

Wintersemester 2016/2017

CPU/GPU-Kombination (APU)

Marcus RogowskyTechnische Universitat Munchen

1.2.2017

Zusammenfassung

Diese Seminararbeit untersucht den moglichen Ein-satz von APUs in HPC-Systemen. Dazu wird dergrobe Aufbau des Gesamtsystems einer aktuellenAPU beschrieben, sowie deren fur den Einsatz imHPC-Bereich wichtigen Komponenten analysiert.Darunter fallen der Aufbau der GPU Kerne unddes Speichersystems mit der Umsetzung von Sha-red Virtual Memory, Cache-Koharenz und On-DieSpeicher mit hoher Bandbreite. Außerdem wird deraktuelle Stand bei der Programmierung von APUsdargestellt und schließlich dargelegt, warum APUsin der jetzigen Form noch nicht bereit sind um inHPC-Systemen eingesetzt zu werden.

1 Einleitung

In vielen wissenschaftlichen Bereichen hat dieEinfuhrung von Supercomputern komplett neueArbeitsweisen und damit einhergehende Ergebnis-se geliefert. Die Nachfrage nach immer noch Lei-stungsstarkeren Supercomputern ist aber weiter-hin ungebrochen, und nach dem Erreichen vonPetascale-Systemen im Jahr 2008, werden nunExascale-Systeme anvisiert. Die Leistungssteige-rung von HPC-Systemen wird damit weitergefuhrtund gleichzeitig nach immer neuen Konzepten ge-

sucht, um das Ziel moglichst effizient umzusetzen.

In den letzten Jahren haben auch GPU basierteSysteme Einzug in die Gruppe der Supercomputergenommen. Dank ihrer auf parallele Berechnungenoptimierten Bauweise und hohen Speicherbandbrei-te sind sie CPU basierten Systemen in den Berei-chen Rechenleistung pro Node und Effizienz uber-legen. Der schnellste Supercomputer mit aktuellerGPU Generation auf Platz 8 der Top 500 Liste,fuhrt gleichzeitig die Green 500 Liste an, die Super-computer nach Energieeffizienz sortiert auffuhrt.

Systeme mit diskreten GPUs haben aber auchNachteile, die einem allgemeinen Einsatz im Wegstehen. So ist der auf den GPUs verbaute Speichergetrennt vom Speicher fur die CPU Kerne und Da-ten mussen vor der Verarbeitung in den Speicherauf der GPU uber die PCI-Express Verbindung ko-piert werden. Diese Verbindung hat mit etwa 10bis 50 Mikrosekunden eine hohe Latenz, kann abernicht vollstandig umgangen werden, da der auf derGPU verbaute Speicher fur die meisten Anwendun-gen nicht groß genug ist um alle Daten vorzuhal-ten. Dies macht Anpassungen in der Software furden Einsatz auf GPU Systemen Notwendig um dieRechenleistung auch ausnutzen zu konnen.

Schulte et al. [9] untersuchten zur Losung dieserProbleme ein Konzept fur den Einsatz von AMD

1

APUs in HPC-Systemen, im Folgenden HPC APUgenannt. Nach diesem Konzept sind die CPU undGPU Kerne sowie ein Speicher mit hoher Band-breite auf einem Interposer verbaut. Die Entwick-lung solcher Systeme begann schon vor uber 10 Jah-ren. Nach der Ubernahme von ATI durch AMD imJahr 2006, wurde an einer Zusammenfuhrung vonCPU und GPU Kernen auf einem Chip gearbei-tet. Zunachst unter dem Codenamen AMD Fusion,spater aber aus rechtlichen Grunden umbenannt inAccelerated Processing Unit (APU). Im Jahr 2011wurde dann die erste APU Serie Llano veroffent-licht.

Gleichzeitig beteiligte sich AMD an der Grundungder HSA Foundation, die das Ziel hat die Entwick-lung von Software fur heterogene System zu ver-einheitlichen und zu vereinfachen. Nach Schulte etal. [9] ist die Umsetzung der Vorgaben der HSAFoundation an die Hardware ein wichtiger Schrittum APUs in HPC-Systemen einsetzen zu konnen.Im Jahr 2015 wurde mit Carizzo dann auch die er-ste APU veroffentlicht, die die Vorgaben der HSAFoundation erfullt.

In den folgenden Kapiteln, wird untersucht, wieheutige APUs aufgebaut sind und in wie weit die-se Umsetzung geeignet ist um in HPC-Systemeneingesetzt zu werden. Dazu wird zuerst der gro-be Aufbau einer APU betrachtet, um anschließendeinzelne wichtige Aspekte zu vertiefen. Das Kapitel“Graphics Core Next Architektur” beschreibt denAufbau und die Funktionsweise der GPU Kerne.Das darauf folgende Kapitel zum Speichersystembetrachtet die Umsetzung verschiedener Aspekte.Zunachst die des Shared Virtual Memory Systems,anschließend der Cachekoharenz und abschließenddas Konzept von auf dem Die verbauten Speichermit hoher Bandbreite. Abschließend wird noch aufdie Vorgaben der HSA Foundation eingegangen undzu welchen Veranderungen deren Umsetzung fur dieProgrammierung von Software fur APUs fuhren.

Abbildung 1: [6] Aufbau einer Carrizo APU

2 Hardware Aufbau

Das Ziel, das mit einer “Accelerated ProcessingUnit” (APU) verfolgt wird, ist, so viele Kompo-nenten eines Systems wie moglich auf einem Dieunterzubringen. Dabei geht es hauptsachlich umdie Vereinigung der CPU mit der GPU aber auchmit weiteren Komponenten, wie Video-encoder unddecoder. Ein solches System nennt man “System-on-a-Chip” (SOC), da die meisten Komponentendes Systems auf einem Chip vereinigt sind.

Die Vorteile dieser Bauweise sind eine schnellereKommunikation zwischen den einzelnen Kom-ponenten, da die Signale direkt auf dem Chipubertragen werden, die gemeinsame Nutzung vonResourcen, was zu Einsparungen bei der Da-tenubertragung beitragen kann und ein niedrigererEnergieverbrauch.

CPU Kerne arbeiten Aufgaben unabhangig vonanderen CPU Kernen in einzelnen Threads ab.Sie sind deshalb besonders gut geeignet Program-me mit vielen Ausfuhrungszweigen auszufuhren.Fur das Ausfuhren von gleichen Rechenaufgabenauf mehreren Eingaben verfugen CPU Kerne uberVektoreinheiten wie AVX-512, die bis zu acht 64-

2

Bit Floatwerte gleichzeitig verarbeiten konnen. Diemaximale Rechenleistung von Multikernprozesso-ren ist im Vergleich zu vektorbasierten Prozessorentrotzdem deutlich geringer. Selbst mit 24 Kernender aktuellen Skylake Architektur von Intel erreichtman eine maximale Rechenleistung von etwa 1,5TFLOPS mit 64-Bit Floatwerten bei einem Preisvon etwa 7000$ und einem Stromverbrauch von 165Watt.Deshalb ubernimmt die CPU auf einer HPC APUAufgaben, die nicht effizient auf vektorbasiertenProzessoren ausgefuhrt werden konnen, wie dieKommunikation zwischen APUs und das Schedu-ling von Aufgaben.

GPU Kerne sind vektorbasierte Recheneinheiten,die die einzelnen Rechenschritte von Program-men mit mehreren Eingaben gleichzeitig verarbei-ten konnen. AMDs GPU-Architektur hat eine Vek-torbreite von 64 und Nvidias GPU-Architekturvon 32 auf den GPU Kernen. Auf dem zur Zeitgroßten HPC GPU Chip von Nvidia sind 56 GPUKerne aktiv, womit 1792 Rechenschritte gleichzei-tig ausgefuhrt werden konnen. Damit erreicht eineGPU eine maximale Rechenleistung von etwa 5,3TFLOPS mit 64-Bit Floatwerten bei einem Preisvon etwa 9000$ und einem Stromverbrauch von 300Watt.Aufgrund der hoheren Effizienz von GPU Kernenwerden auf einer HPC APU die eigentlichen Be-rechnungen wenn es moglich ist darauf ausgefuhrt.

Der auf der APU integrierte Speichercontroller,auch Northbridge genannt, ist fur die Abarbeitungder Speicherzugriffe zustandig. Bei dem HPC APUKonzept von Schulte et al. [9] kann der Speicheraus einem auf dem selben Chip verbauten Teil undeinem externen angeschlossenen Teil bestehen. Derauf der HPC APU verbaute Speicher, zum BeispielHBM2, wurde zwar eine deutlich hohere Bandbrei-te von bis zu 1 TB/s ermoglichen, hatte aber einekleinere maximale Große gegenuber herkommlichenArbeitsspeicher.

Der IO Controller, auch Southbridge genannt, aufder APU ist fur die externe Kommunikation desChips zustandig. Bei einer HPC APU besteht die-

se hauptsachlich aus dem Datenaustausch mit deruber PCI-Express angeschlossenen Netzwerkkarte.Aber auch das Lesen und Schreiben von Daten aufFestplatten wird von dieser Einheit ausgefuhrt.

Auf aktuellen APUs sind weitere Recheneinheitenverbaut, die spezielle Aufgaben besonders effizientausfuhren konnen. Deren ubliche Aufgaben sind dasEncodieren oder Decodieren von Video und AudioFormaten. Diese Aufgaben werden auf einer HPCAPU nicht benotigt, es ist allerdings denkbar, dassfur andere Aufgaben spezielle Recheneinheiten ver-baut werden konnten.

Aktuelle APU-Systeme richten sich vor allem anEndverbraucher, die ein Komplettsystem benoti-gen aber keine diskrete GPU verbauen wollen oderkonnen, wie etwa in Notebooks oder Desktop-Systemen mit wenig Leistung. Dementsprechend istdie Anzahl an CPU und GPU Kernen niedrig gehal-ten, mit 2 bis 4 CPU Kernen, 3 bis 11 GPU Kernenund extern angeschlossenem DDR4 Speicher.APU-Systeme die in Hochleistungsrechnern ver-baut werden sollen, mussten dagegen deutlich lei-stungsfahiger sein. Der von Schulte et al. [9]veroffentlichte Entwurf einer HPC APU fur Exas-cale Computing wurde uber 32 CPU Kerne, einerRechenleistung von insgesamt 10 TFLOPS fur dieGPU Kerne sowie auf dem Chip verbauten gesta-pelten Speicher verfugen.

3 Graphics Core Next Archi-tektur

Die Graphics Core Next (GCN) Architektur wur-de 2011 von AMD veroffentlicht und wird seitdemfur GPUs und APUs verwendet. Das Ziel bei derEntwicklung der neuen Architektur war, die Re-chenleistung der GPU Kerne besser fur allgemei-ne Berechnungen nutzbar zu machen. Dazu wurdedie Programmierung vereinfacht und das Schedu-ling verbessert.Seit der Einfuhrung der GCN Architektur gab esdrei nachfolgende Generationen mit denen weite-re Verbesserungen eingefuhrt wurden. Im folgendenwird von der dritten GCN Generation ausgegangen,

3

Abbildung 2: [1] Aufbau der Graphics Core NextArchitektur

da diese die neuste ausfuhrlich dokumentierte dar-stellt, und dabei der Schwerpunkt auf Aspekte ge-legt, die fur HPC Anwendungen von Relevanz sind.

3.1 Aufbau der GCN Architektur

Die GCN Architektur verfugt uber acht Asynchro-nous Compute Engines (ACEs), die fur das Schedu-ling von Rechenaufgaben zustandig sind. Dazu wer-den die Rechenaufgaben zunachst in Workgroupsaufgeteilt die wiederum aus Wavefronts bestehen,die jeweils 64 Threads groß sind. Jede der ACEskann dann pro Takt eine Wavefront an eine Com-pute Unit (CU) verteilen und dabei acht Queuesgleichzeitig verwalten. Wavefronts werden auf denCUs grundsatzlich ungeordnet abgearbeitet und dieACEs stellen vor dem Verteilen der Aufgaben si-cher, dass alle Abhangigkeiten zu anderen Rechen-aufgaben eingehalten werden.Zusatzlich zu den ACEs verfugt die GCN Architek-tur uber zwei Direct Memory Access (DMA) En-gines, mit denen Daten parallel zur Abarbeitungder Rechenaufgaben von Außen in den Speicher ge-schrieben oder aus dem Speicher gelesen werdenkonnen. Diese Engines sind nur auf diskreten GPUsverbaut, da bei APUs die Strategie verfolgt wirdden Speicher von CPU und GPU Kernen gemein-sam zu benutzen und damit Datenaustausch zwi-schen den beiden Einheiten zu vermeiden.

Alle Speicherzugriffe finden uber den Memory Con-troller statt. Auf APUs kann fur die GPU und

Abbildung 3: [2] Aufbau der GCN Compute Unitmit den fur HPC Anwendungen relevanten Kom-ponenten

CPU Kerne der selbe Memory Controller verwen-det werden. Um Konflikte bei der parallelen Abar-beitung von Aufgaben auf den CUs zu vermeiden,verfugt jede Aufgabe uber ihren eigenen virtuellenSpeicherbereich.Zwischen CUs und Memory Controller ist ein L2Cache geschaltet, der fur alle CUs koharent ist. ZurGewahrleistung der Cache-Koharenz mit CPU Ker-nen ist das L2 Cache-Interface so konzipiert, dassder Inhalt direkt mit dem Cachesystem von x86CPUs ausgetauscht werden kann. Die Cache-Linessind 64 Byte groß und das virtuelle Speichersystemunterstutzt 4 KiB große Pages. Der Cache ist auf-geteilt in Partitionen die jeweils 64 KiB oder 128KiB groß sind und die Gesamtgroße des Caches istdurch die Anzahl der verwendeten Partitionen fest-gelegt.

Neben dem L2 Cache gibt es noch einen weiterenglobalen Speicher, der von allen CUs gelesen undgeschrieben werden kann. Dieser als Global DataShare (GDS) bezeichnete Speicher ist 64 KiB großund wird neben der Verwendung fur architekturin-ternen Datenaustausch zwischen den CUs auch zurBearbeitung von atomaren Operationen verwendet.

3.2 Aufbau der GCN Compute Unit

Die Compute Units der GCN Architektur bear-beiten die ihnen zugewiesenen Wavefronts. Dazuverfugt jede CU uber eigene Ressourcen, die nichtmit anderen CUs geteilt werden.

4

Jede CU verfugt uber vier SIMD Einheiten diejeweils 16 Operationen gleichzeitig bearbeitenkonnen. Mit der funften GCN Generation wird eszudem moglich sein Operationen auf kleineren Da-tentypen wie 16-Bit Float- und Integerwerten oder8-Bit Integerwerten zusammenzufassen und damitdie Anzahl der Operationen pro Takt zu verdoppelnoder zu vervierfachen.Den SIMD Einheiten werden immer ganze Wave-fronts zugeteilt, was bedeutet, dass fur die Bearbei-tung einer Operation fur alle Elemente in der Wave-front vier Takte oder ein Vielfaches von vier Taktennotwendig sind. Um Latenzen bei Speicherzugriffenauszugleichen, kann jede SIMD Einheit bis zu 10Wavefronts gleichzeitig bearbeiten. Wird in einerWavefront ein Speicherzugriff ausgefuhrt, kann dieSIMD Einheit in der Zwischenzeit eine Operationvon einer der restlichen Wavefronts ausfuhren.

Jede SIMD Einheit verfugt uber 64 KiB an Regi-stern. Bei der Verwendung von 32-Bit Registern ste-hen jeder SIMD Einheit damit 16 tausend Registerzur Verfugung. Um die Wavefronts optimal auf denSIMD Einheiten abarbeiten zu konnen sollten im-mer mindestens sechs Wavefronts gleichzeitig bear-beitet werden. Das bedeutet, dass pro Thread nichtmehr als 42 Register verwendet werden sollten.

Zusatzlich zu den SIMD Einheiten hat jede CU eineScalar Unit. Diese Einheit kann pro Takt eine In-struktion ausfuhren und berechnet eine 64-Bit brei-te Maske, mit der festgelegt wird, welche der 64Threads in einer Wavefront fur die nachste Opera-tion aktiv sind. Dadurch werden Verzweigungen imCode realisiert, indem immer nur die Threads ak-tiviert sind, die den aktuellen Codepfad ausfuhren.Da so aber immer nur ein Codepfad pro Wavefrontausgefuhrt werden kann, fuhren Verzweigungen zueiner geringeren Rechenleistung und sollten deshalbsoweit es moglich ist vermieden werden.

Jede CU verfugt außerdem uber einen eigenen L1Cache, der als Local Data Share (LDS) bezeichnetwird und 64 KiB groß ist. Dieser Speicher kannentweder komplett als L1 Cache verwendet oderein Teil davon von der Anwendung selbst verwaltetwerden. Der LDS ist fur alle Threads in einer Work-

Abbildung 4: [10] Aufbau eines Shared Virtual Me-mory Systems fur CPU und GPU Kerne

group koharent, womit er das effiziente austauschenvon Daten zwischen Threads innerhalb einer Work-group moglich macht.

4 Speichersystem

Der Hauptnachteil an Systemen mit diskretenGPUs ist der geteilte Speicher und die damit einher-gehenden Probleme bei der Programmierung undAusfuhrung von Programmen. Das Ziel des Spei-chersystems von APUs ist daher den selben Spei-cher fur CPU und GPU Kerne zu verwenden abergleichzeitig die hohe Rechenleistung der GPU Ker-ne beizubehalten.

4.1 Shared Virtual Memory

Auf einer APU verwenden CPU und GPU Kernedenselben Speicher. Allerdings reicht dies alleinenoch nicht aus, damit die selben Daten im Spei-cher von beiden Kernen verwendet werden konnen.Speicher von der CPU ist in Pages mit virtuellenAdressen organisiert, denen physikalische Adressenzugewiesen werden konnen. Sollen CPU und GPUKerne auf dieselben Daten zugreifen konnen, muss

5

das Pagingsystem auf die GPU Kerne erweitert wer-den.

Dazu wird auf APUs eine IO Memory ManagementUnit (IOMMU) verbaut, die die Adressubersetzungfur die GPU Kerne ubernimmt. Die IOMMU ist inder Northbridge der APU integriert und kann wiedie MMUs der CPU Kerne die Pagetablestrukturfur x86-64 Prozessoren verwenden. Zum Verwaltender IOMMU ist außerdem ein OS-Treiber notwen-dig, der Aufgaben auf den CPU Kernen ausfuhrenkann.

Zusatzlich wird die GPU um einen Translation Loo-kaside Buffer (TLB) erweitert, der die physikali-schen Adressen der zuletzt verwendeten Pages spei-chert, und der direkt von den CUs verwendet wer-den kann.

Greift eine CU auf eine Page zu, die nicht im TLBgespeichert ist, wird ein TLB-Miss ausgelost. DieGPU sendet dann eine Address Translation Proto-koll (ATS) Anfrage an die IOMMU, die uber eineneigenen TLB verfugt. Ist die Adresse fur die Pageauch nicht im TLB der IOMMU gespeichert mussdiese die Hardware-Pagetables auslesen. Wird dieAdresse darin gefunden, sendet die IOMMU dieAdresse mit einer ATS Antwort an die GPU zuruck.Das ATS Protokoll erlaubt es bis zu acht aufeinan-derfolgende virtuelle Pages mit einer Anfrage an-zufordern, was in aktuellen APUs standardmaßigaktiviert ist.

Findet die IOMMU die gesuchte Adresse jedochnicht im Hardware-Pagetable, sendet sie eine ATSPage-fault Antwort an die GPU zuruck. Diese un-terbricht daraufhin die Ausfuhrung der Wavefrontdie diese Page benotigt und sendet eine PeripheralPage Request (PPR) Anfrage an die IOMMU, diediese Anfragen in einer Queue sammelt und dannfur mehrere Anfragen gebundelt einen CPU Inter-rupt auslost. Der IOMMU Treiber behandelt dannauf der CPU die PPR Anfragen, indem er die Pageswieder in den Speicher ladt. Anschließend benach-richtigt der Treiber dann die IOMMU daruber, dassdie PPR Anfrage abgeschlossen wurde, die wieder-um die GPU benachrichtigt. Die Wavefront wirddann wieder von einer ACE gescheduled was wie-

der zu einer ATS Anfrage fur die Adresse der Pa-ge an die IOMMU fuhrt, die jetzt die Adresse imHardware-Pagetable finden kann.

Andert sich das Speichermapping von Pages,mussen auch die Eintrage in den TLBs aktuali-siert werden. Dazu uberwacht der IOMMU TreiberAnderungen in den Pagetables und schickt wenn ei-ne Anderung stattgefunden hat eine Nachricht andie IOMMU, dass die alte Adresse ungultig ist. Die-se entfernt dann die Adresse aus dem eigenen TLBund schickt eine Nachricht an die GPU, die danndie Adresse aus ihrem TLB entfernt. Beim nachstenSpeicherzugriff der GPU wird dann die neue Adres-se ermittelt.

Vesely et al. [10] haben die Performance des Pa-gingsystems aktueller APUs untersucht und kom-men zu dem Ergebnis, dass schon mit diesen inbestimmten Testszenarien die Performance durchdas Pagingsystem beschrankt wird. Vor allem beiAnwendungen mit ungeordneten Speicherzugriffenfuhrte der Overhead des Pagingsystems zu einerVerringerung der Gesamtleistung auf ein Viertel dermoglichen Rechenleistung. Außerdem ergaben ih-re Messungen, dass es 25 mal langer dauert einenTLB-miss der GPU zu bearbeiten als auf der CPU,auf Grund der vielen Nachrichten, die ausgetauschtwerden mussen. Die Behandlung von Page-faultsauf der GPU kann sogar bis zu 82 mal langsamersein als auf der CPU.Auf HPC APUs die uber deutlich mehr GPU Kerneund eine hohere Speicherbandbreite verfugen, wirddieses System dann vollends zum Flaschenhals. Be-vor eine solche APU umgesetzt werden kann mussdas Pagingsystem fur APUs uberarbeitet und da-mit deutlich verbessert werden.

4.2 Cache-Koharenz

Die GPU Kerne und CPU Kerne auf einer APUhaben weiterhin eigene L2 Caches. Verandert zumBeispiel die CPU Daten die in ihrem Cache bleibenund ladt die GPU danach dieselben Daten, sinddie Anderungen nur sichtbar, wenn beide Cacheskoharent gehalten werden. Um diese Koharenz aufaktuellen APUs umzusetzen kommt ein Directory-

6

Abbildung 5: [8] Aufbau eines koharenten CacheSystems fur CPU und GPU Kerne

Based Cache Coherence System zum Einsatz.

Die GPU Kerne und die CPU Kerne haben weiter-hin eigene L2 Caches die fur die jeweiligen Kernekoharent gehalten werden. Zusatzlich wird ein glo-bales Speicherblockverzeichnis verbaut, dass fur je-den Block mit zwei Bits speichert, ob er in einemder beiden L2 Caches gespeichert ist. Alle Speicher-zugriffe der CPU werden uber dieses Verzeichnisdurchgefuhrt, bei der GPU dagegen mussen nur dieSpeicherzugriffe uber das Verzeichnis durchgefuhrtwerden, die Koharent mit der CPU sein sollen.Die GPU kann uber zwei Busse Daten ubertra-gen. Der so genannte “Garlic” Bus ist direkt mitdem Speicher verbunden und kann fur GPU inter-ne Speicherzugriffe genutzt werden. Der “Onion”Bus dagegen ist mit dem Speicherblockverzeichnisverbunden.

Tritt auf der GPU oder der CPU ein L2 Cache-Missauf, wird eine Anfrage an das Verzeichnis geschickt,das fur alle ankommenden Anfragen zunachst ein“Miss Status Handle Register” (MSHR) erstellt undin einer Tabelle speichert. Fur die Register wirddann nacheinander uberpruft, ob der Tag fur denSpeicherblock im Speicherblockverzeichnis gespei-chert ist.

Ist der Tag in dem Verzeichnis gespeichert, bedeutetdas, dass er bereits in dem anderen Cache vorhan-

den ist. Fur Schreibzugriffe muss die andere Kopieungultig gemacht werden, und fur Lesezugriffe mussdie aktuelle Kopie des Speicherblocks aus dem an-deren Cache gelesen werden. Dazu werden Anfra-gen fur den jeweiligen Cache erstellt und bis zurBearbeitung im “Probe-Request RAM” (PPR) ge-speichert. Wurde der Speicherblock von dem Cachegeschickt oder die Bestatigung, dass der Speicher-block geloscht wurde, wird die Anfrage aus demPPR entfernt.Fur Lesezugriffe wird der Speicherblock an den an-deren Cache geschickt und das Bit fur den Cacheim Verzeichnis fur den Speicherblock gesetzt. FurSchreibzugriffe wird der Speicherblock aus dem Ver-zeichnis entfernt.

Ist der Tag nicht in dem Verzeichnis gespeichert,wird der Speicherblock aus dem Speicher geladenund das Bit im Verzeichnis fur den Cache gesetzt,der jetzt eine Kopie des Speicherblocks enthalt.

Power et al. [8] stellten bei ihrer Untersuchung die-ses Systems auf aktuellen APUs allerdings fest, dasses nicht fur die bei GPUs ublichen hohen Cache-Miss-Raten ausgelegt ist. Eine deutliche Vergroße-rung der MSHR-Tabelle wurde in ihren Testan-wendungen zu einer Leistungssteigerung von biszu 300% fuhren. Außerdem musste das Verzeichnisbis zu vier Anfragen pro Takt unterstutzen konnenanstatt nur einer wie bisher. Sie schlagen deshalbvor fur die GPU und die CPU jeweils ein eigenesSpeicherblockverzeichnis zu verbauen, das Speiche-roperationen, die nicht koharent gehalten werdenmussen automatisch uber den schnelleren Bus mitdirekter Verbindung zum Speicher leitet und damitfur diese das gemeinsame Speicherblockverzeichnisumgeht.

4.3 On-Die Stacked Memory

Der bisher betrachtete Speicher wird, wie es furCPU Speicher ublich ist, an die APU angeschlos-sen und verfugt uber eine Bandbreite von bis zu ca.20 GB/s. Wahrend mit diesem Speicher eine aus-reichende Große fur eine HPC APU erreicht werdenkann, ist die Bandbreite fur die Datenubertragungviel zu gering. Auch auf diskreten GPUs verbau-

7

Abbildung 6: [7] Konzept einer APU mit gestapel-tem Speicher auf einem Interposer und zusatzlichangebundenem externen Speicher

ter GDDR5 Speicher ist mit bis zu ca. 400 GB/snoch zu langsam, und mit der heutigen maximalenGroße von 32 GB zu klein. Gestapelter Speicherder auf dem selben Die wie die APU verbaut wird,kann dagegen in der aktuellen Version die geforder-te Bandbreite von 2 TB/s liefern, ist aber auch aufeine Große von 32 GB beschrankt.

Da nicht abzusehen ist, dass in naher Zukunft ei-ne neue Speichertechnologie die geforderte Großeund Bandbreite gleichzeitig unterstutzt, musstenfur eine HPC APU zwei verschiedene Methodenkombiniert werden um deren Vorteile zu nutzen.Um die geforderte Bandbreite zu erreichen wirdauf dem Die der APU gestapelter Speicher verbautund uber einen Interposer mit der APU verbunden,wahrend gleichzeitig gewohnlicher DDRx Speicherangeschlossen wird.

Fur ein solches hybrides Speichersystem gibt es zweigrundsatzlich unterschiedliche Wege bei der Umset-zung. Eine Moglichkeit ist es Anwendungen expli-ziten Zugriff auf beide Speicher zu geben, was be-deutet, dass die Anwendung selbst entscheidet, wel-che Daten im schnellen Speicher gehalten werden.Der Vorteil ist, dass die Anwendung den Ablauf beider Verarbeitung der Daten kennt und so eine in-telligente Entscheidung fallen kann. Der Nachteilist aber, dass die Anwendung den Speicher selbstverwalten muss, womit ihr Entwicklungsaufwandsteigt, da sie explizit an ein solches Speichersystemangepasst werden muss.

Die andere Moglichkeit ist es den schnellen Spei-cher als Cache zu verwenden, der von der Hard-

ware verwaltet wird. Damit konnen Programme,ohne dass Anpassungen notwendig sind, direkt aufder APU ausgefuhrt werden und von dem schnel-len Speicher profitieren. Ein solches Cache-Systemmusste jedoch Aufgrund der Große des Caches undder damit auftretenden Schwierigkeiten fur Tag ba-sierte Caches anders aufgebaut sein als bisherigeSysteme.

Ein moglicher Ansatz fur ein neues Speichersystemwurde von Meswani et al. [7] untersucht. Dieses Sy-stem basiert auf Pages und beide Speicher bildenzusammen einen gemeinsamen Speicherbereich, beidem die Pages zwischen den beiden Speichern wech-seln konnen. Dazu werden die Zugriffe auf die Pa-ges aufgezeichnet und das Betriebssystem transfe-riert alle 100 Millisekunden alle Pages mit Zugriffen(First-touch policy) oder nur die Pages mit den mei-sten Zugriffen (Hot-page policy) in den schnellenSpeicher. Messungen mit Testanwendungen, die beiausschließlicher Verwendung von gestapelten Spei-cher um durchschnittlich 20% schneller liefen, zeig-ten bei Verwendung dieses Systems einen Speedupvon durchschnittlich 15%. Damit konnte der Vorteilden der schnellere Speicher bringt zu 75% ausge-nutzt werden, ohne dass Anpassungen in den An-wendungen notwendig waren.

Die effektive Ausnutzung der hohen Bandbreite vongestapeltem Speicher fur HPC Anwendungen stelltein aktuelles Forschungsfeld dar, das fur die Um-setzung von Exascale-Systemen eine entscheidendeRolle spielt.

5 Programmierung

Um die Vorteile der Bauweise von APUs inAnwendungen ausnutzen zu konnen, muss dieProgrammierung der Software dafur angepasstsein. AMD grundete dazu mit weiteren Firmen,unter anderem ARM und Samsung, im Juni 2012die Heterogeneous System Architecture (HSA)Foundation, die das Ziel verfolgt einen herstel-lerubergreifenden und offenen Standard fur dieProgrammierung von heterogenen Systemen zuentwickeln. Im Marz 2015 wurde die erste Ver-

8

sion der HSA Spezifikation veroffentlicht, gefolgtvon der ersten HSA kompatiblen Hardware imOktober 2015 mit der Carizzo APU. Mittlerweileunterstutzen uber 40 Firmen die Initiative, an 17Universitaten wurden HSA Academic Centers ofExcellence gebildet und im Sommer 2016 eine HSAKonferenz in Peking abgehalten.

Um die Softwareentwicklung fur verschiedenheterogene Systeme zu vereinheitlichen und zuvereinfachen, macht die HSA Spezifikation be-stimmte Vorgaben daruber, was von der Hardwareunterstutzt werden soll, uberlasst den Herstellernaber die Umsetzung. Sie besteht aus mehrerenTeilen, die jeweils verschiedene Bereiche, dienotig sind um Software auf heterogenen Systemauszufuhren, abdecken. Die HSA Platform SystemArchitecture Specification legt die Vorgaben andie Hardware fest, die erfullt werden mussen.Darunter sind unter anderem die Unterstutzungvon Shared Virtual Memory, Cache-Koharenz,Signal- und Synchronisationsoperationen, atomareOperationen und User Mode Queueing. Das HSAProgrammer’s Reference Manuel spezifiziert dieeinheitliche Zwischensprache HSAIL, in die C++,OpenCL, OpenMP und Java Quellcode ubersetztwerden, um anschließend in die hardwarespezifischeInstruktionssprache ubersetzt zu werden. Das HSARuntime Programmer’s Reference Manual definiertdie HSA Runtime API, die eine Schnittstelle zumAusfuhren von Code und zur Verwaltung vonRessourcen auf HSA Systemen bereitstellt.

Der Unterschied zwischen der bisherigen Program-mierung fur diskrete GPUs und der Vereinfachungmit HSA fur APUs wird deutlich, wenn man dieSchritte vergleicht, die Notwendig sind um Co-de auf der GPU auszufuhren. In Abb. 7 sind dieeinzelnen Schritte Aufgefuhrt und farblich mar-kiert. Zunachst muss die Anwendung die Daten, dieverarbeitet werden sollen auf die GPU kopieren.Das Betriebssystem und der GPU-Treiber uber-nehmen dann den eigentlichen Kopiervorgang. Sinddie Daten auf die GPU kopiert, kann die Anwen-dung eine Aufgabe an die Warteschlange im Trei-

Abbildung 7: Herkommliche Programmierung furdie GPU. Schritte die mit HSA noch notwendigsind, sind grun markiert.

ber anhangen. Der Treiber arbeitet dann die Warte-schlange ab und schließlich wird die Aufgabe auf derGPU ausgefuhrt. Die Anwendung wartet dann, bissie vom Betriebssystem mitgeteilt bekommt, dassdie Aufgabe ausgefuhrt wurde und muss sich dieErgebnisse aus dem Speicher auf der GPU holen.Das Betriebssystem und der GPU-Treiber kopie-ren dazu die Daten wieder in den CPU-Speicherund die Anwendung kann weiter mit den Ergebnis-sen arbeiten. Der Aufwand um Aufgaben auf derGPU auszufuhren und die Ergebnisse anschließendauf der CPU weiter zu verarbeiten ist also relativhoch, im Vergleich zum Beispiel zur Verwendungvon OpenMP um Code parallel auf CPU Kernenauszufuhren.

Mit der Umsetzung der HSA Spezifikation ver-bessert sich die Situation jedoch deutlich. DurchVerwendung von Shared Virtual Memory entfal-len die beiden Kopiervorgange im Betriebssystemund GPU-Treiber (Orange markiert). Mit einemcache-koharenten Speichersystem entfallen außer-dem die beiden Cache-Flushes, die Notwendig wa-ren, damit die aktuellen Daten auf der GPU oderder CPU verwendet werden (Gelb markiert). Wirdvon der APU Signaling unterstutzt, kann die GPUder Anwendung auf der CPU direkt mitteilen, dassdie Aufgabe auf der GPU abgearbeitet wurde. Da-durch entfallt die Indirektion uber das Betriebs-system und den GPU-Treiber (Dunkelblau mar-

9

kiert). Schließlich definiert die HSA Spezifikationnoch User Mode Queueing, womit eine AnwendungAufgaben auf der GPU direkt zum Ausfuhren indie Warteschlange auf der GPU einordnen kann.Damit entfallt auch hier die Indirektion uber denGPU-Treiber (Hellblau markiert).

Ubrig bleiben die beiden Schritte, die Aufgabe aufder GPU in die Warteschlange einzuordnen und die-se auf der GPU auszufuhren (Grun markiert). Da-mit lasst sich Code auf der GPU nun vergleichbareinfach ausfuhren, wie mit OpenMP auf der CPU.

Im April 2016 veroffentlichte AMD die ROCm Plat-form auf GitHub, die die Moglichkeit bietet mit of-fener Software Programme fur APUs zu entwickeln.Darin enthalten sind eine Runtime fur Linux, Com-piler fur C und C++ sowie ein Compiler fur dievon Nvidia entwickelte Programmiersprache CU-DA. Die Entwicklung von Softwareentwicklungs-werkzeugen fur APUs steht damit noch am Anfangund es muss erst noch abgewartet werden, ob sichdiese in den nachsten Jahren durchsetzen.

6 Schluss

Obwohl die Entwicklung von APUs schon vor uber10 Jahren begonnen hat, steht deren Einsatz undvor allem die Anpassung von Softwareentwicklungs-werkzeugen noch ganz am Anfang. Um das Einsatz-gebiet von sparsamen Desktop- und Notebooksyste-men auf den HPC-Bereich zu erweitern, sind nocheinige Verbesserungen an der Hardware notwendig.Das Speichersystem ist zudem bisher nur fur nied-rige Rechenleistungen ausgelegt, und wurde in derjetzigen Form HPC-Anwendungen sehr stark aus-bremsen.

Eine direkte Umsetzung einer fur den HPC-Marktzugeschnittenen APU erscheint damit derzeit alseher unwahrscheinlich. Die Entwicklungskosten unddas Risiko fur die Entwicklung vollig neuer Hard-warekomponenten und einer nicht abzuschatzendenAkzeptanz im Markt sind außerdem zu hoch. Einmoglicher Weg bietet sich allerdings bei der Ent-wicklung von APUs fur Spielkonsolen an, da dieseahnliche Anforderungen haben wie Desktopsysteme

mit eingebauten Grafikkarten und die Anpassungder Software an das Hardwaresystem dort die ubli-che Praxis darstellt.

Bis APU Systeme also letztendlich in Supercompu-tern eingesetzt werden, werden noch einige Jahrevergehen, in denen leistungsfahige APUs zunachstin Spielkonsolen und Desktopsystemen Verbreitungfinden werden. Auf lange Sicht bleibt das Konzeptaber attraktiv, wenn bei der Umsetzung darauf ge-achtet wird, dass die Softwareentwicklung einfachist und das Hardwaresystem auf hohe Rechenlei-stungen angepasst ist.

Literatur

[1] GCN command processing. https://upload.wikimedia.org/wikipedia/commons/9/99/

GCN_command_processing.svg. Accessed:2017-01-10.

[2] GCN Compute Unit. http://

amd-dev.wpengine.netdna-cdn.com/

wordpress/media/2014/05/gcn_compute_

unit-1140x511.png. Accessed: 2017-01-10.

[3] Top500 Supercomuter Sites. https://www.

top500.org. Accessed: 2017-01-29.

[4] J. Glossner. Multicore digital signal processorfor heterogeneous systems era. IEEE SigPort,2015.

[5] Advanced Micro Devices Inc. White Paper| AMD GRAPHICS CORES NEXT (GCN)ARCHITECTURE. 2012.

[6] Guhan Krishnan, Dan Bouvier, and SamuelNaffziger. Energy-efficient graphics and multi-media in 28-nm carrizo accelerated processingunit. IEEE Micro, 36(2):22–33, 2016.

[7] Mitesh R. Meswani, Sergey Blagodurov, Da-vid Roberts, John Slice, Mike Ignatowski, andGabriel H. Loh. Heterogeneous memory ar-chitectures: A hw/sw approach for mixing die-stacked and off-package memories. In HPCA,pages 126–136. IEEE Computer Society, 2015.

10

[8] Jason Power, Arkaprava Basu, Junli Gu,Sooraj Puthoor, Bradford M. Beckmann,Mark D. Hill, Steven K. Reinhardt, and Da-vid A. Wood. Heterogeneous system coherencefor integrated cpu-gpu systems. In Proceedingsof the 46th Annual IEEE/ACM InternationalSymposium on Microarchitecture, MICRO-46,pages 457–467, New York, NY, USA, 2013.ACM.

[9] Michael J. Schulte, Mike Ignatowski, Gabri-el H. Loh, Bradford M. Beckmann, William C.Brantley, Sudhanva Gurumurthi, Nuwan Jaya-sena, Indrani Paul, Steven K. Reinhardt, andGregory Rodgers. Achieving exascale capabi-lities through heterogeneous computing. IEEEMicro, 35(4):26–36, 2015.

[10] Jan Vesely, Arkaprava Basu, Mark Oskin, Ga-briel H. Loh, and Abhishek Bhattacharjee. Ob-servations and opportunities in architectingshared virtual memory for heterogeneous sy-stems. In 2016 IEEE International Symposiumon Performance Analysis of Systems andSoftware, ISPASS 2016, Uppsala, Sweden,April 17-19, 2016, pages 161–171, 2016.

11