Vergleichen Sie die verschiedenen NXP i.MX8 Grafikbeschleuniger und erkennen Sie die Unterschiede

1. iMX8 Übersicht

Die i.MX8-Familie von Modulsystemen (Englisch: System on Modules, kuz SoMs) von Variscite bietet eine Pin-zu-Pin Skalierbarkeit zwischen den Familien i.MX 8, iMX 8X und i.MX 8M der NXP-SoCs (SoC steht für System on Chip, ein System auf einem Chip). Jedes SoM verfügt über einen Grafikprozessor, der die Hardware-Beschleunigung von grafischen und rechenintensiven Anwendungen ermöglicht. Dieser Artikel zielt darauf ab, die Kunden von Variscite mit dem Grafikprozessor (Englische Abkürzung: GPU) vertraut zu machen und eine praktische Anleitung zur Auswahl des richtigen SoMs zu geben:

• Ein Vergleich der GPUs der einzelnen SoMs der i.MX8-Familie von Variscite
• Eine Einführung in die verfügbaren Software-APIs zur Beschleunigung von grafischen und rechenintensiven Aufgaben
• Ergebnisse des OpenGL ES-Benchmarks mit GPU-Beschleunigung
• Benchmark-Ergebnisse verschiedener Berechnungen mit CPU und GPU
• Hilfreiche Tipps und Richtlinien, um die besten Ergebnisse zu erzielen
• Die nächsten Schritte zur Auswahl des richtigen SoM für Ihre Anwendung

1.1 Hauptprozessor (CPU) und Grafikprozessor (GPU)

Bevor wir beginnen, ist es wichtig, den Unterschied zwischen dem Hauptprozessor (CPU) und dem Grafikprozessor (GPU) zu erläutern und zu erklären, warum die GPU für die Entwicklung grafischer Anwendungen so wichtig ist.
Die CPU ist darauf ausgelegt, vielfältige Aufgaben schnell zu erledigen – aber es gibt nur eine begrenzte Anzahl an Prozessen, die von ihr zeitgleich ausgeführt werden können. Der Grafikprozessor hingegen ist auf die zeitgleiche Ausführung vieler verschiedener Prozesse (Multitasking) ausgelegt und unterstützt allgemein sämtliche Aufgaben, die mit der Grafikverarbeitung zusammenhängen, z. B. das Rendern von hochauflösenden Bildern und Videos.
CPUs und GPUs unterscheiden sich in ihrer grundlegenden Architektur: Während die CPU ’schmal und tief‘ strukturiert ist, sind die GPUs ‚flach und breit‘ angelegt. Im Allgemeinen verfügt die CPU über einen großen Cache-Speicher, nimmt selbstständig Verzweigungsvorhersagen vor und hat eine viel höhere Taktfrequenz als die GPU. Der Grafikprozessor enthält mehrere baugleiche Recheneinheiten, die viel einfacher strukturiert sind als eine normale CPU, aber so einen einzigen Befehl parallel auf mehreren Datensätze anwenden können. Die GPU nimmt dabei keine Verzweigungsvorhersagen vor.

So wird beispielsweise ein Code mit vielen Verzweigungen und Bedingungen wie ‚Wenn, dann‘-Anweisungen (Englisch: if-else) aufgrund der Verzweigungsvorhersagefähigkeiten einer CPU auf dieser effizienter ausgeführt, während ein Code mit vielen SIMD-Operationen (Englisch für ‚Single Instruction Multiple Data‘ – ein einziger Befehl für die gleichzeitige Anwendung auf mehrere Datensätze) aufgrund der Parallelverarbeitungsfähigkeiten einer GPU auf dieser effizienter ausgeführt wird.

i.MX8 System on Module mit 3D GPU – GC7000 XSVX (x2)

2. Die GPU auf i.MX 8 Anwendungsprozessoren

Die i.MX 8-Anwendungsprozessorfamilie von NXP enthält GPUs von Vivante (VeriSilicon).  Diese GPUs beschleunigen verschiedene Anwendungsprogrammierungsschnittstellen (Englisch: ‚Application Programming Interfaces‘, kurz: API) auf der Benutzerebene. In der folgenden Tabelle finden Sie einen allgemeinen Überblick über die Prozessoren und ihren aktuellen Support-Status:

• Vergleichstabelle für die i.MX 8-Familie

Die aufgeführten APIs werden von der Khronos Group definiert, einem offenen, gemeinnützigen und mitgliedergestützten Konsortium von über 160 branchenführenden Unternehmen, das fortschrittliche, lizenzfreie Interoperabilitätsstandards für  3D-Grafik,  Erweiterte und Virtuelle Realität, Parallelprogrammierung , Bildverarbeitungsbeschleunigung und Maschinelles Lernen bereitstellt:

• OpenCL: Dieser Standard wird für die plattformübergreifende, parallele Programmierung moderner Prozessoren verwendet.
  • https://www.khronos.org/opencl/
• OpenGL ES (OpenGL für Eingebettete Systeme): Dieser Standard wird für das Rendering fortschrittlicher 2D- und 3D-Grafiken auf eingebetteten Systemen verwendet.
  • https://www.khronos.org/opengles/
• OpenVG: Dieser Standard wird für moderne Benutzeroberflächen und Vektorgrafik-Bibliotheken wie SVG verwendet.
  • https://www.khronos.org/openvg/
• OpenVX: Dieser Standard ermöglicht eine leistungs- und energieoptimierte computergestützte Bild- und Videoerkennung, die für eingebettete Systeme und Echtzeit-Anwendungsfälle wie Gesichts, Körper- und Gestenerkennung, intelligente Videoüberwachung usw. wichtig ist.
  • https://www.khronos.org/openvx/
• Vulkan: Dieser Standard ermöglicht es Entwicklern, eine breite Palette von Geräten mit derselben Grafik-API anzusprechen.
  • https://www.vulkan.org/

Weitere Informationen zu den Taktfrequenzen, zur Anzahl der Shader, zu den GFLOPS etc. finden Sie unter:

• Benutzerhandbuch für NXP i.MX-Grafik

iMX8-basiertes Evaluierungskit mit 2D/3D-Grafikbeschleunigung

3. 2D/3D Graphics Acceleration

Das ‚Board-Support-Paket‘ (BSP) enthält mehrere Beispiele für die gängigsten APIs, wie OpenCL, OpenVG , OpenGL und mehr. Diese Beispiele finden Sie im Ordner / opt der aktuellen Yocto-Veröffentlichungen. Um zum Beispiel die ‚OpenGL ES‘-Demo von Bloom auszuführen, führen Sie folgenden Code aus:

# cd /opt/imx-gpu-sdk/GLES3/Bloom

# ./GLES3.Bloom_Wayland

Es ist wichtig zu erwähnen, dass wenn die Anwendung eine grafische Benutzeroberfläche (GUI)  benötigt, der Benutzer OpenGL ES (auch bekannt als GLES), eine Untermenge der OpenGL-API für 2D- und 3D-Rendering von Computergrafiken, verwenden sollte. GLES übernimmt die Grafikbeschleunigung entweder direkt oder über ein abstrahiertes High-Level-Framework. Um eine Anwendung mit hardwarebeschleunigten Grafiken zu erstellen, gibt es grundsätzlich zwei Möglichkeiten:

• OpenGL ES: Hier erfolgt das Schreiben der Anwendung unter Verwendung des nativen Frameworks, das dem Benutzer mehr Kontrolle bietet. Allerdings ist dies der schwierigste Weg, um die erwarteten Ergebnisse zu erzielen.
• Bibliothek/Framework: Hierbei arbeitet man unter Verwendung eines Frameworks, das die OpenGL ES-Grafikbeschleunigung bereits unterstützt, z. B. Qt.

3.1 Tests mit dem glmark2-Benchmark

Um eine Schätzung der Leistung einer GPU zu erhalten, wurden die folgenden Tests mit dem glmark2-Benchmark-Tool durchgeführt, wobei der CPU-Skalierungsregulator auf Leistung eingestellt wurde. Der Test erfolgte mit einem Kühlkörper auf dem SOC.

Die Durchführung der Tests mit glmark2

Die Tests wurden mit dem folgenden Befehl ausgeführt:

# glmark2-es2-wayland -s 640x480

Der Befehl taskset kann verwendet werden, um den Benchmark auf bestimmten CPU-Kernen auszuführen. Zum Beispiel auf den SoMs, die Teil der i.MX 8-Familie sind, welche über 4 x A53  und 2 x A72  Kerne verfügen, können Sie mit den folgenden Befehlen einen Satz von Kernen desselben Typs (A53 oder A72) auswählen, indem Sie die Kernnummern angeben:

# taskset -c 0-3 glmark2-es2-wayland -s 640x480

# taskset -c 4,5 glmark2-es2-wayland -s 640x480

HINWEIS: Auch wenn in den obigen Beispielen Sätze mit denselben Kerntypen (A53 oder A72) verwendet werden, können Sie tatsächlich  jede beliebige Kombination von Kernen verwenden.

Die Testergebnisse

Die Ergebnisse bei einzelnen und mehreren Kernen

Eine interessante Beobachtung, die sich aus der obigen Tabelle ergibt, ist es, dass die Kerne SPEAR-MX8 und VAR-SOM-MX8 sowie die zweifachen A72-Kerne besser abschneiden als die Kombination aus sechs Kernen (2 x A72 + 4 x A53). Die folgende Tabelle zeigt die Ergebnisse unter Verwendung des SPEAR-MX8 und bei der Ausführung von glmark2-es2-wayland auf einem oder mehreren bestimmten CPU-Kernen:

Obwohl der Test eigentlich die GPU-Leistung testet, hängt sein Ergebnis auch von der CPU ab. Für diese spezielle Anwendung liefert die Verwendung von zwei A72-Kernen die besten Ergebnisse. Das liegt daran, dass die A72-Kerne schneller sind als die A53-Kerne. Da bei dieser Aufgabe nicht die Vorteile mehrerer CPUs zum Tragen kommen, führt die Zuweisung der Aufgabe an die jeweils schnellsten Kerne zu den besten Ergebnissen.

3.2 OpenCL Beschleunigung

OpenCL (Englische Abkürzung für ‚Open Computing Language‘) ist ein offener, lizenzgebührenfreier Standard für die plattformübergreifende und parallele Programmierung verschiedener Beschleuniger, die in Supercomputern, Cloud-Servern, PCs, mobilen Geräten und eingebetteten Plattformen zu finden sind.

Im Folgenden finden Sie einige Benchmark-Ergebnisse und Links zum Quellcode von zwei Beispielen, die sowohl für die CPU- als auch für die GPU-Kerne unter Verwendung von OpenCL geschrieben wurden:

Matrixmultiplikation (512×512)

• Das Quellcode-Beispiel für diesen Test finden Sie unter Matrixmultiplikationsbeispiel.

Binäre Suche

• Das Quellcodebeispiel für diesen Test finden Sie unter Binärsuchenbeispiel.

Das Beispiel für die Matrixmultiplikation läuft auf der GPU schneller, während das Beispiel für die binäre Suche auf der CPU schneller abläuft.
Das macht Sinn, denn es gilt:

a. Das Beispiel für die binäre Suche verwendet viele Verzweigungen (wenn-dann-Anweisungen), während das Beispiel für die Matrixmultiplikation dies nicht tut, sodass es eher für die Ausführung auf der CPU geeignet ist.
b. Das Beispiel für die Matrixmultiplikation verwendet viele identische Anweisungen für mehrere Datensätze und ist daher besser für die Ausführung auf der GPU geeignet.

4. Abschließende Überlegungen

Inzwischen haben Sie wahrscheinlich erkannt, dass es viele Variablen gibt, welche sich auf die Leistung auswirken können, die Sie dementsprechend bei verschiedenen GPU-beschleunigten Grafik- und Berechnungsaufgaben erwarten können. Jeder SoC verfügt über eine einzigartige CPU-, GPU- und Speicherkonfiguration mit unterschiedlicher Leistungsfähigkeit und Ausstattungsoptionen. Die Auslagerung der CPU-Arbeit auf einen Koprozessor ist nicht nur im Sinne einer schnelleren Berechnung von Vorteil, sondern dient auch der Entlastung der CPU, die dadurch für andere Aufgaben frei wird.
Bei einer Aufgabe, die nur über einen Thread verfügt, können Sie bessere Ergebnisse erzielen, wenn Sie sie einem leistungsstärkeren CPU-Kern wie dem A72 zuweisen.

Jede Anwendung hat ihre ganz eigenen Anforderungen. Die technischen Daten und numerische Benchmarks können Ihnen zwar dabei helfen, die richtige Richtung einzuschlagen, aber am besten ist es, Ihre Anwendung auf der gewünschten Hardware selbst zu testen. Variscite empfiehlt die Verwendung eines EVK und Pin-zu-Pin-kompatibler SoMs, um Ihre Anwendung zu evaluieren und die Ergebnisse aus der Praxis zu nutzen, um das richtige SoM für Ihre Anwendung zu finden.

Weitere Informationen und Beispiele finden Sie im Verzeichnis OpenCL-Beispiele in unserem Archiv var-demos bei GitHub.