AMD hQ: CPU und GPU kommunizieren auf Augenhöhe

Aufbauend auf dem Heterogeneous Unified Memory Access (hUMA) stellt AMD mit Blick auf die hauseigenen APUs auch das Modell des Heterogeneous Queuing (hQ) vor. Mit hUMA wird sozusagen ein gemeinsamer Raum für Arbeit und Kommunikation eingerichtet. Durch hQ wird sichergestellt, dass bei direkter Kommunikation von CPU- und GPU-Teileinheiten die gegenseitigen Instruktionen auch verstanden werden.

Bislang ist der GPU-Teil weisungsgebunden, weil der CPU-Part sozusagen als Prokurist die Arbeitsspeicherverwaltung übernimmt. Soll die GPU also Arbeiten für eine Anwendung erledigen, dann wird für jede Aufgabe ein neuer Verwaltungsakt nötig. Durch hUMA wird die GPU der CPU weitgehend gleichgestellt. Auch sie ist damit berechtigt, Daten im gemeinsamen Speicheradressraum direkt zu manipulieren.

Damit das reibungslos funktioniert, bedarf es einheitlicher Vorgehensweisen der beiden Teileinheiten, die mittels AMDs hQ hergestellt werden. Traditionell übernimmt ein Kernel Mode Driver (und damit letztlich die CPU) die Aufgabe, für die GPU das zu übersetzen und strukturieren, was ihr von einer Anwendung zur Erledigung angewiesen wird. Das sorgt für Overhead und Latenz und ist nicht sonderlich effizient.

Drei Aspekte gewährleistet AMD hQ daher:

• Ein herstellerübergreifendes, für alle HSA-kompatiblen CPUs, GPUs (oder DSPs) einheitliches Packet-Format. Dadurch muss nicht mehr aufwendig von der CPU für die GPU übersetzt werden.
• Durch User Mode Queuing statt Kernel Mode Queuing können Work Items direkt in Task Queues der GPU platziert werden. Die Aufgaben für die GPU müssen nicht mehr durch einen Kernel Mode Driver extra strukturiert und angewiesen werden.
• Die GPU muss also nicht mehr häppchenweise durch die CPU gefüttert werden. Sie kann von sich aus Work Items nicht nur direkt in den eigenen Queues, sondern auch direkt in den Queues der CPU platzieren.

Packet- und Queue-Format sind deshalb durch die HSA-Spezifikation einheitlich definiert. Anwendungen können durch diese Einheitsformate Aufgaben direkt an zu ihrer Erledigung bevorzugten Einheiten verteilen, ohne dass die CPU und/oder das Betriebssystem sich mit dem Management herumschlagen müssen. Die GPU darf dann in "Eigeninitiative" entscheiden, wie mit von ihr bearbeiteten Aufgaben weiter zu verfahren ist. Sie muss dazu nicht erst bei der CPU "um Erlaubnis betteln"; sie kann ganz im Gegenteil die CPU anweisen, Aufgaben zu erledigen.

Davon sollen HSA-kompatible Systeme in diversen Disziplinen profitieren. Selbstverständlich bei der Performance, die durch den Wegfall von Latenz und Overhead steigt. Auch bei der Energieeffizienz stellen sich Verbesserungen ein, denn statt für andere Einheiten den Übersetzer zu geben kann die CPU ein Päuschen machen oder sich anderen Aufgaben zuwenden - im letzteren Fall steigt dann vor allem die Performance-per-Watt.

(Hürden überwinden: HSA Queuing Model)

Anwendugnen werden dadurch über verschiedene Plattformen hinweg portabler. Weil ein breites Konsortium aus Industrie und Wissenschaft die HSA unterstützt, kann zwischen Embedded Devices, Smartphones, Tablets, Notebooks, Desktop-PCs und der mindestens ebenso vielfältigen "Server-Welt" munter portiert werden. Zwar macht die direkte Portierung von kompletten Anwendungen freilich selten Sinn, für Entwickler ist dabei jedoch vielmehr die Wiederverwendbarkeit von einmal geschriebenem Code äußerst attraktiv: Alle HSA-kompatiblen Recheneinheiten verstehen die direkten Instruktionen. Der Aufwand in gegebenenfalls unterschiedlichen, proprietären Sprachen für die native ISA der Zielhardware zu programmieren, entfällt.

Kurz und bildlich dargestellt: Durch hUMA wird die GPU von der Vorzimmerdame zum Vorstandsmitglied, sie erlangt direkt Kenntnis von allem, was im Arbeitsspeicher vor sich geht und kann es auch direkt beeinflussen. Mit hQ wird sichergestellt, dass alle Vorstandsmitglieder und damit die ihnen zugeordneten Abteilungen die gleiche Sprache verstehen und sprechen.