CPU-seitig ist AMD schon länger nicht mehr erste Wahl, aber die hauseigene GPU-Sparte spielt weiterhin in der 1. Liga. Schon kurz nach AMDs ATi-Kauf vor knapp 7 Jahren wurde bekannt, dass AMD kombinierte Chips aus CPU und GPU herstellen wolle, die den Namen APU (Accelerated Processing Unit) bekamen. Das Konzept wurde "Fusion" genannt, doch leider war dieser Name schon besetzt, sodass sie mittlerweile unter dem Kürzel HSA zusammengefasst wird. Aktuell gibt es zwar mit Richland bereits die dritte Generation der APUs, aber einen HSA-fähigen Vertreter gibt eben noch nicht. Erster Chip mit diesen Eigenschaften soll im zweiten Halbjahr 2013 Kaveri werden. Was unterscheidet Kaveri aber nun von den aktuellen Richland, Trinity und Llano APUs?
hUMA (heterogeneous Uniform Memory Access) kurz und knapp erklärt: Das Konzept sehen wir auf der nächsten Folie:
hUMA: heterogeneous Uniform Memory Access
Salopp gesagt, handelt es sich eigentlich "nur" um das alte UMA-Konzept, jetzt aber erweitert auf GPUs. Für bisherige APUs traf das Kürzel "NUMA" zu, welches auch von den Opteron-Setups mit 2 und mehr Prozessoren bekannt ist. In beiden Fällen ist der Speicherzugriff nicht einheitlich. Zwar gibt es einen gemeinsamen DRAM-Pool, bei den Opterons teilt sich dieser aber auf die verschiedenen CPU-Sockel auf und bei einer APU auf die zwei Adressbereiche der CPU und GPU. Ganz genau waren die Opterons aber per ccNUMA verbunden, wobei das "cc" für (Cache-)Speicherkohärenz steht. Das heißt Datenänderungen werden mit allen anderen Caches abgeglichen und die Datenkonformität somit sichergestellt. Ändert z. B. der erste CPU-Kern den Dateneintrag A, der auch schon im L2-Cache der GPU liegt, so wird dieser – nun veraltete Eintrag – automatisch für ungültig erklärt. Gleiches gilt im umgekehrten Fall, falls die GPU Datenänderungen vornimmt. Diese Speicherkohärenz wird jetzt auch bei den APUs nachgeliefert. Ab Kaveri teilen sich CPU- und GPU-Einheit deshalb nicht nur wie bisher den DRAM-Controller, sondern benutzen auch einen einzigen, gemeinsamen Speichercontroller. Bisher gab es noch zwei eigenständige Speichercontroller in jeder APU, jeweils einen für CPU und GPU. Der DRAM-Controller ist nur dafür zuständig, die Speichermodule anzusprechen. Das ermöglichte schon bisher, normale DDR3-Speichermodule einzusetzen und den verfügbaren Speicher für die APU zu erhöhen. Standardmäßig stand dieser Speicher dann aber nur der CPU zur Verfügung, der GPU musste man Grafikspeicher noch extra über BIOS-Einstellungen zuweisen, da eben beide Speicherbereiche getrennt von zwei Controllern verwaltet wurden.
Das kann man sich jetzt in Zukunft sparen, denn die GPU wird ab Kaveri ein vollwertiges Mitglied im Rechenkernverbund und teilt sich wie alle anderen Kerne auch die Speicheradressräume und verfügt über eine einheitliche Speicherkohärenz. Bisher musste sich der Programmierer um solche Sachen kümmern bzw. sicherstellen, das die Daten zwischen CPU und GPU hin- und hergeschoben und abgeglichen wurden. Eine durchgehende Speicherkohärenz zwischen den CPU- und GPU-Teilen einer APU vereinfacht deshalb die Programmierung. Bereits Llano führte mittels des gemeinsamen DRAM-Controllers die Zero-Copy-Funktionalität ein, mit der zumindest schon das Kopieren erleichtert wird.
Als weiterer Vorteil gibt AMD an, dass die GPU durch den gemeinsamen Speichercontroller jetzt auch Zugriff auf die Auslagerungsdateien auf der Festplatten hat. Alle Vorzüge sind im folgenden Bild ersichtlich:
hUMAs Schlüsselmerkmale
Wie sich AMD die Zukunft von HSA vorstellt, kann man schön im folgenden futuristisch anmutenden Werbefilmchen sehen:
Der Benutzer wird automatisch per Gesichtserkennung erkannt, Pulsmesser liefern Körperdaten an den Computer, und Spracheingabe funktioniert natürlich sowieso. AMD spricht deshalb auch optimistisch von einer "Intelligenten System-Architektur" und unterstreicht diesen Ansatz durch die Gleichsetzung von HSA mit dem menschlichen Gehirn:
HSA-Grundkonzept
Ob man diesen vollmundigen Versprechungen Glauben schenken darf, wird die fernere Zukunft zeigen. In naher Zukunft dagegen darf man sich auf das nächste Fusion-Entwicklertreffen freuen, das im November stattfindet und nach dem bereits erwähnten Namensstreit nun offiziell "APU-Summit" heißt:
AMD APU13 - Developer Summit
Zeitgleich dürfte auch Kaveri offiziell präsentiert werden, so dies nicht schon früher geschehen sollte.
AMD hat uns noch einige Detailfragen zu hUMA nachträglich beantwortet. Diskrete Grafikkarten werden demnach nicht von allen Features des neuen Speichermodells hUMA profitieren können. Zur unterstützten Funktionalität soll demnach folgendes gehören: Die diskreten GPUs können nicht nur auf den Systemspeicher zugreifen, in dem sie CPU-Pointer verwenden, sondern haben auch Zugriff auf die komplexeren Datenstrukturen der höheren Programmiersprachen. Außerdem haben die dGPUs vollständigen Zugriff auf den pageable Systemspeicher und damit auf den gesamten Systemspeicher, der vom Betriebssystem verwaltet wird. Allerdings wird hUMA keine bidirektionale Kohärenz zwischen den diskreten Grafikkarten und dem Systemspeicher sicherstellen, was laut AMD daran liegen soll, dass dies vom PCIe-Bus nicht unterstützt wird.
Von diesen Vorteilen sollen auch heute geschriebene OpenCL-Kernel profitieren, da die Laufzeitumgebung künftig erkennen können soll, ob das Programm auf einem HSA-kompatiblen System ausgeführt wird. Entsprechend kann die Laufzeitumgebung dann unnötiges Kopieren der Daten selbstständig eliminieren und kostspielige Cache Flushs vermeiden. Implementierungen, die C++ AMP nutzen, können ebenfalls von der Eliminierung unnötiger Kopien und der Vermeidung von Cache Flushs profitieren. Zudem soll der Compiler hier in der Lage sein, effizienteren Code zu erzeugen.
Auf Rückfragen bezüglich der Sony PlayStation 4 ließ uns AMD lediglich wissen, dass Details zur Implementierung von Sonys Architektur nicht kommentiert werden. Somit gibt es vorerst keine Bestätigung für die HSA-Kompatibilität oder die Nutzung von hUMA bei der PS4.
Diesen Artikel bookmarken oder senden an ...
