Aktuelle Entwicklungen der Prozessoren Akzelerierte Grafik – Hemmschuh für Echtzeitsysteme?

Anbieter zum Thema

Linutronix GmbH

Parasoft® Deutschland GmbH

Moderne Prozessorarchitektur strebt naturgemäß nach ständiger Verbesserung. Wesentlicher Antrieb für die Entwicklung immer schnellerer, kompakterer und sparsamerer Prozessoren ist die hohe und weiter wachsende Nachfrage in der Unterhaltungs- und Spieleindustrie sowie bei mobilen Geräten aller Art.

Ein wichtiger Aspekt ist dabei die Grafikleistung, die einerseits für flüssige Videowiedergabe als auch für hochauflösende Mediendarstellung notwendig ist. Für deren Bereitstellung ist heute meist die GPU (Graphics Processing Unit = Grafikprozessor) verantwortlich. Diese ist bei vielen aktuellen Prozessoren direkt mit dem Prozessorkern als eine Einheit im SoC (System on Chip) integriert.

Die speziellen Anforderungen von Echtzeitsystemen werden bei der Prozessorentwicklung nicht sonderlich beachtet, aber von modernen Prozessoren in weiten Bereichen abgedeckt. Und weil Embedded-Systeme mit den Prozessoren gebaut werden, die auf dem Markt zur Verfügung stehen, ist auch auf diesen Systemen oftmals eine GPU vorhanden, die in der Regel gemeinsam mit der CPU direkt verbaut ist und eine enorme Rechenleistung allein für die grafische Ausgabe bereitstellt. Beispielsweise ist auf dem Layout eines Intel Core Prozessors der 11. Generation mit vier CPU-Kernen ist bereits an der Flächengröße zu erkennen, dass der Grafikprozessor mehr Raum einnimmt als die vier eigentlichen Prozessorkerne.

Dadurch ist auf diesen Systemen, insgesamt betrachtet, eine hohe Rechenleistung vorhanden und es bietet sich an, diese auch für die grafische Ausgabe zu benutzen. Jedoch gibt es auch Beschränkungen, denn je nach Prozessorarchitektur teilen sich die CPU und die GPU verschiedene Komponenten des Prozessors, wie z.B. Caches, Datenbusse und I/Os.

Diese Interferenzen können dazu führen, dass ein System beim Verwenden der GPU plötzlich Latenzen zeigt und sich eigentlich gute Messwerte beim Echtzeitbetrieb verschlechtert sind. Um diesen Einfluss darzustellen werden in diesem Beitrag verschiedene Szenarien beschrieben und die gesammelten Messergebnisse dargestellt. Ebenso wird gezeigt, wie man die Grafikausgabe unter Linux-RT realisieren kann, ohne Einflus auf die Echtzeitfähigkeit eines Systems zu nehmen.

Verschiedene Möglichkeiten der Grafikausgabe und deren Klassifikation

Zur Ausgabe von Grafik bei Linux-RT können verschiedene Möglichkeiten in Betracht gezogen werden, die jeweils zum einen von der Aufgabe des Systems und zum anderen von der vorhandene Grafikleistung abhängen. So kann bei einfachen Steuerungen mitunter eine Darstellung von Messwerten oder Zuständen als Text vollkommen ausreichend sein, während bei einer komplexen Maschinensteuerung beispielsweise die Einrichtung eines Werkzeugs mit dreidimensionaler Grafik dargestellt werden soll.

Es empfiehlt sich, sich bereits zu Beginn einer Projektphase über Art und Umfang der Ausgabe im Klaren zu sein. Für die weitere Betrachtung werden hier drei Grafikklassen benannt, deren grundlegende Eigenschaften im Folgenden beschrieben werden:

• Die Ausgabe als Text ist die einfachste Möglichkeit, um Ausgaben aus einem System darzustellen. Dabei erfolgt die Ausgabe über das VT (Virtual Terminal)-Subsystem des Linuxkernels, daher ist keine zusätzliche Software für Treiber notwendig. Die Einschränkung dieser Ausgabe ist, dass nur alphanumerische Zeichen möglich sind und diese auch nur in der vorgesehenen Maske aus Zeilen und Spalten; Beliebige Positionierung ist nicht möglich.

• Die zweite Art der Ausgabe auf einem System mit GPU ist die Nutzung der akzelerierten Grafik. Dabei verwaltet der DRM (Direct Rendering Manager) als wichtiger Teil der DRI (Direct Rendering Infrastructure) die Zugriffe auf die Hardware mittels eines Kernelmoduls. Dies ermöglicht alle Variationen der Visualisierung und grafischen Darstellung und kann neben Video und 3D-Grafiken auch für komplexe grafische Effekte genutzt werden.

• Die dritte Option der grafischen Ausgabe unter Linux-RT ist die Nutzung des Framebuffers. Der Zugriff auf die Grafik wird durch eine Abstraktionsschicht ermöglicht, die der Linuxkernel bei entsprechender Konfiguration als Framebuffer-Device zur Verfügung stellen kann. Dadurch ist je nach verwendetem System die Darstellung auch ansprechender Grafiken möglich.

Zusammengefasst hier die wesentlichen Eigenschaften der drei Grafikklassen:

Versuchsaufbau zum Vergleich von akzelerierter Grafik zu Framebuffer-Grafik

Um den Einfluss der Grafikausgabe von akzelerierter Grafik und Framebuffer zu vergleichen, wurden im folgenden Beispiel das industriell nutzbare Echtzeitsystem vom Typ AAEON/UP-WHL01(Up Xtreme) ausgewählt. Kenndaten:

• CPU x86 Intel Core i3-8145UE @2200 MHz

• Integrated GPU UHD 620 @300 MHz

• Architecture: Whiskey Lake

• Kernel: 5.10.27-rt36 #4 SMP PREEMPT_RT

Zwei dieser Systeme waren in der OSADL QA-Farm unter den gleichen Bedingungen in Betrieb, alle Messdaten der Versuche wurden mit dem vorhandenen Munin-Monitoring-System erfasst und gespeichert. Um Beeinflussung auf das Echtzeitverhalten zu erkennen, wurde auf den Boards das Verhalten unter Last simuliert. Zur Erzeugung von CPU-Last wurde das Standard-Tool Unixbench verwendet, mit gltestperf und UnixBench-2D wurde die Grafik-Last erzeugt.

Gleichzeitig wurde mit dem Programm cyclictest aus der RT-Tests-Suite zur jeweiligen Testphase ein Latenzplot erzeugt. Dadurch wird der Einfluss auf das Echtzeitverhalten sichtbar. Das System in Rack e Slot 5 (res5) wurde im normalen Grafikmodus gestartet, als Treiber war das Kernelmodul i915 geladen. Das Vergleichssystem in Rack e Slot 6 (res6) lief im Framebuffer-Modus. Die Tests erfolgten nach dem dargestellten Ablaufplan in Abbildung 2, der sich alle zwölf Stunden wiederholt:

Ergebnisse der Latenzmessungen mit simuliertem Standardbetrieb:

Bei dieser Untersuchung wird auf den Systemen eine standardisierte Last (standard-io) erzeugt, die den Normalbetrieb eines Systems darstellen soll. Dabei werden zwischen 09:10 Uhr und 12:35 Uhr wechselnde Schreib- und Lesevorgänge über Netzwerk und auf den Speichermedien erzeugt. Von 07:10 Uhr bis 12:43 findet die Latenzmessung über cyclictest statt. Die gemessenen Latenzen werden als Zahlenreihen abgelegt und anschließend in einem sogenannten Latenzhistogramm dargestellt.

Beide Systeme zeigen sehr ähnliche Latenzen und liegen im Bereich von 37 us (res5) und 36 us (res6). Da weder auf der CPU noch auf der GPU besondere Lasten erzeugt wurden, war dieses Verhalten zu erwarten.

Ergebnisse der Latenzmessungen mit simulierter CPU-Last (UnixBench):

Hierbei startet die Latenzmessung um 05:05 Uhr und endet um 06:45 Uhr. In diesem Zeitraum wird von 05:15 bis 06:11 Uhr die CPU-Last mittels UnixBench generiert. Die dabei gemessenen Latenzhistogramme sind im Folgenden dargestellt:

Die Latenz des Systems mit Framebuffer-Grafik (res6) ist mit 47 us geringfügig höher als das System mit akzelerierter Grafik (41 µs). Dies ist bedingt durch die grafische Ausgabe, die bei Framebuffer-Grafik ausschließlich von der CPU geleistet wird.

Ergebnisse der Latenzmessungen mit simulierter Grafik-Last:

Zunächst wurden die grafischen Ausgabesysteme mit dem UnixBench-2D Tool untersucht. Um Latenzdaten aufzuzeichnen, wurde von 02:30 bis 03:36 cyclictest gestartet. Zur Erzeugung von Grafik-Last wird als Test für dreidimensionale Ausgabe von 02:50 Uhr bis 02:51 Uhr gltestperf gestartet, für zweidimensionale Tests UnixBench-2D von 03:05 Uhr bis 03:20 Uhr. Die Benchmark-Ergebnisse von UnixBench-2D zeigten, dass die akzelerierte Grafik besonders bei der Textausgabe und dem Rectangles-Test der Framebufferausgabe überlegen ist, bei den anderen Tests sind die Messergebnisse sehr ähnlich. Allerdings zeigt die Framebuffer Grafik etwa 4-fach höhere Geschwindigkeit beim 2D-Benchmark windows. Dies liegt vermutlich darin begründet, dass die Zugriffsfunkionen im Framebuffer hochgradig optimiert sind und diese Operationen deutlich schneller ablaufen.

Als weitere Untersuchung wurden die 3D Performance der Systeme und der Einfluss auf das Echtzeitverhalten betrachtet. Hierbei zeigt sich die eindeutige Überlegenheit der akzelerierten Grafik, die in fast allen Bereichen des gltestperf wesentlich bessere Ergebnisse liefert. Ausnahme ist der Test zu Color/Depth Buffer Clears, hier ist der Framebuffer deutlich schneller. Auch hier ist vermutlich, wie auch bei dem Unixbench-2D, die optimierte Zugriffsgeschwindigkeit des Framebuffers verantwortlich.

Bei den Latenzaufzeichnungen während der grafischen Lasterzeugung durch UnixBench-2D und gltestperf zeigt sich, dass das System mit akzelerierter Grafik im Vergleich zur Framebuffer-Grafik auf dem System res6 deutlich höhere Werte zeigt, hier also 433 µs zu 66 µs:

Dieser Versuch mit grafischer Last zeigt deutlich, dass die Entlastung der CPU durch die GPU dazu führt, das die eigentlich guten Echtzeiteigenschaften eines Systems stark beeinträchtigt werden. Daher ist gut abzuwägen, ob ein Projekt, das zwingend auf komplexe Grafikausgabe angewiesen ist, auch für die Steuerung eines Echtzeit- systems verwendet werden kann. Alternativ kann die Entscheidung sein, die Grafikausgabe mit einem Framebuffer-System zu realisieren, um nicht durch starke Interferenz von GPU und CPU beim Betrieb mit akzelerierter Grafik die Echtzeiteigenschaften zu verlieren. Im Folgenden wird die Konfiguration eines Linux-RT-Systems mit Framebuffer-Grafik aufgezeigt.

Linux-System mit Framebuffer konfigurieren

Um ein Linux-System mit dem Framebuffer-Device zu betreiben, muss zunächst der Kernel so konfiguriert werden, damit die Ausgabe auf dem Framebuffer-Device unterstützt wird. Hier beispielsweise für die Kernelversion 5.10.27-rt36. Im Menüpunkt Device Drivers

kann das zur Hardware passende Device ausgewählt werden, für generische VESA-Unterstützung z.B. das Modul vesafb. Nach dem Kompilieren und Booten ist das Modul im neu erstellen System vorhanden. Um es verwenden zu können, muss das grafische System Xorg ebenfalls konfiguriert werden. Dazu erstellt man eine neue Konfigurationsdatei mit

#: Xorg -configure

Die so erstellte Konfiguration muss nun bearbeitet werden, da automatisch der Treiber für die akzelerierte Grafik eingetragen wird. Diesen ersetzt man durch das Framebuffer-Device, das im Kernel konfiguriert wurde, im aktuellen Beispiel ist der Eintrag

Driver "intel"

zu ersetzen durch

Driver "fbdev"

Die fertige Konfigurationsdatei wird unter /etc/X11/xorg.conf abgelegt. Um beim Booten des Systems den Framebuffer zu betreiben, muss als Kommandozeilenoption nomodeset verwendet werden, damit das ansonsten erfolgende Kernel-Mode-Setting (KMS) unterbunden wird. Meist gibt es für spezifischer Hardware noch weitere Optionen, die einen gezielten Betrieb des Framebuffers mit z.B. einer ausgewählten Auflösung oder Farbtiefe ermöglichen. Hier sei auf die Dokumentation des jeweiligen Kernelmoduls verwiesen.

Zusammenfassung und Fazit

Aktuelle Prozessoren verfügen schon in einfachen Ausführungen über eine oftmals ausgezeichnete Grafik-Performance. Dies wird erreicht, indem bereits auf dem Prozessorchip eine Grafikeinheit eingebunden ist. Diese ist dafür optimiert, sehr schnell und energieeffizient Berechnungen für die grafische Ausgabe durchzuführen und damit die CPU zu entlasten. Dies klingt im ersten Moment auch für die Entwicklung von RT-Systemen verlockend, da die Kombination von CPU und GPU ausreichend Rechenleistung verspricht, um selbst komplexe Anwendungen auf einem Linux-RT Rechner zu betreiben.

Jedoch kann es, wie in den Versuchen und Messungen in der QA-Farm gezeigt, auch zu unerwünschten Nebeneffekten kommen. So müssen sich die GPU und die CPU oft Ressourcen des Systems teilen, wodurch es zu gegenseitiger Beeinflussung kommt. Dies ist dann zu erkennen, wenn ein ansonsten leistungsfähiges System mit akzelerierter Grafik bei der Latenz-messung deutlich schlechtere Ergebnisse liefert als ein System, das keine Grafikbeschleunigung nutzt. Als Alternative bietet sich an, für die Grafikausgabe den Framebuffer zu verwenden.

Dieser kann als Device im Linux-System eingebunden werden und bildet eine Abstraktionsschicht zwischen dem Kernel und der Grafikausgabe. Auf diese kann die CPU sehr schnell und ohne zusätzlichen Overhead zugreifen und grafische Ausgaben tätigen. Die Leistungsfähigkeit dieser Ausgaben ist natürlich von der Gesamt-Performance des Systems abhängig. Mit aktuellen Systemen ist im Framebuffer-Betrieb durchaus auch die Ausgabe von umfangreichen bewegten Grafiken und Videos möglich.

Dieser Beitrag stammt mit freundlicher Genehmigung des Autors aus dem Tagungsband des ESE Kongress 2021.

Making-of-Video

ESE Kongress digital 2021 – ein Blick hinter die Kulissen

(ID:48459138)