Historischer Hintergrund der Grafiktreiber

Die Grafik-Möglichkeiten auf eingebetteten Systemen haben sich über die letzten Jahre stark verändert. Wir werfen zuerst einen Blick auf die Historie der Grafikhardware und der zugehörigen Software.

Anfangs hatten eingebettete Systeme, wenn überhaupt, nur sehr eingeschränkte Möglichkeiten der Grafikausgabe. Meist konnten sie nur simple LC-Displays ansteuern und die gesamte Arbeit des Bildaufbaus musste von der CPU geleistet werden, da es keinerlei Hardwarebeschleunigung gab. Einerseits war dies sehr praktisch, da die CPU sehr flexibel ist und die Treiber für die simplen Hardwareeinheiten zu schreiben keinen großen Aufwand bedeutete: Treiber mussten nichts anderes tun als ein mit Bilddaten gefülltes Stückchen Speicher mit dem richtigen Timing auf den Datenbus des Displays zu legen. Andererseits setzte die begrenzte Rechenpower der CPU der Grafik sehr klare Grenzen. Der eigentliche Zweck des Geräts darf nicht beeinträchtigt werden, und der ist selten nur die Anzeige schöner Grafik.

Vor etwa 15 Jahren, als Moore's Gesetz noch in voller Geschwindigkeit in Kraft war, wurde es schließlich möglich komplette Grafikbeschleuniger (GPUs) in die passenden Größen-, Stromaufnahme- und Kostengrenzen der Welt der eingebetteten Systeme zu schrumpfen. Da die GPUs nun die Hauptlast der Generierung der Bilddaten für die Anzeige übernahmen, wurde es möglich viel ansprechendere grafische Oberflächen zu bauen, während gleichzeitig auf der CPU wieder Zeit für andere Aufgaben frei wurde.

Dies hatte allerdings auch seinen Preis: die Komplexität der Treibersoftware für diese GPUs übersteigt die der bisherigen simplen CPU-Algorithmen bei weitem. Außerdem herrscht im GPU-Geschäft ein starker Konkurrenzdruck, mehrere Firmen versuchen hier GPUs für den Einsatz in eingebetteten Systemen zu verkaufen. Dies führte dazu, dass die meisten Firmen in diesem Geschäft sich entschlossen ihre Treibersoftware closed-source anzubieten. Das soll vermeiden, dass versehentlich wesentliche Details ihrer Hardware, welche sie von der Konkurrenz abheben sollen, nach außen dringen.

Probleme mit closed-source Treibern

Eingebettete Systeme haben einige besondere Anforderungen, da sie meist für einen sehr speziellen Anwendungsfall gebaut werden, den sie mit maximaler Kosteneffizienz erfüllen müssen. Dadurch bleibt meist wenig Spielraum, um Ineffizienz in der Verarbeitungspipeline der Geräte mit roher Rechenpower zu kompensieren, d.h. die Software muss stark auf den Anwendungsfall hin optimiert werden. Außerdem sind viele dieser Geräte für eine lange Anwendungszeit im Feld ausgelegt. Da immer mehr dieser Geräte auch mit dem Internet verbunden sind, ist ein einfaches Update der Software zur Behebung von funktionalen oder sicherheitsrelevanten Problemen von entscheidender Bedeutung.

Diese Anforderungen sind sehr schwer zu erfüllen, wenn sich closed-source Komponenten im System befinden, über welche man keine Kontrolle hat. Auch wenn der Hersteller der GPU in der Lage und willens ist notwendige Änderungen an der Treibersoftware auszuführen, so kann dies doch eine sehr lange Zeit in Anspruch nehmen. Dies kann dazu führen, dass das Gerät nicht zum angepeilten Zeitpunkt im Markt platziert werden kann und dadurch die Verkaufsaussichten reduziert werden. Auch kann diese Abhängigkeit zur Folge haben, dass notwendige Updates an anderen Systemkomponenten (z.B. Linux-Kernel, Basissystembibliotheken) deutlich erschwert werden, da diese sich auf die closed-source Komponenten auswirken.

Welche Alternativen gibt es?

Das Pengutronix Grafikteam hat langjährige Erfahrung bei der Erstellung von Open-source-Treibern für diese Hardwareeinheiten.

Für uns begann diese Geschichte, als einige unserer Kunden das Risiko einer Closed-source-Komponente im Herzen ihres Produkts nicht dulden wollten. So begannen wir gemeinsam eine Open-Source-Alternative zu den bestehenden Lösungen der GPU-Hersteller zu schaffen. Die i.MX-Produktlinie von NXP ist in der Medizintechnik und in der Industrie sehr beliebt, da sie sehr viele der dort geforderten Features abdecken kann. Beginnend mit dem i.MX6 integrieren diese SoCs GPUs vom Hersteller VeriSilicon (ehemals Vivante). Einige Freiwillige in der Free-Software-Bewegung hatten bereits begonnen diese GPUs per Reverse-Engineering zu dokumentieren. Diese Bewegung ist unter dem Namen Etnaviv bekannt. Pengutronix hat sich diesen Aktivitäten angeschlossen und dabei geholfen eine hochqualitative Alternative zum Herstellertreiber zu entwickeln.

Inzwischen ist der Etnaviv-Treiber in einer ganzen Reihe von eingebetteten Systemen zu finden. Von Medizingeräten, über In-flight-Entertainment-Systeme, bis hin zu Bedieneinheiten in Industriemaschinen und Fahrzeugen. Alle Teile des Etnaviv-Treibers sind als Open Source verfügbar, was jedem ermöglicht diesen zu verbessern oder anzupassen. Das eliminiert das Risiko einer Abhängigkeit von einem einzelnen Hersteller. Natürlich ist Pengutronix als starker Partner mit sehr viel Erfahrung in diesem Bereich immer daran interessiert Anwendern bei Anpassung und Fehlerbehebung behilflich zu sein.

Der Etnaviv-Treiber ist in die vorhandenen Frameworks, wie DRM im Linux-Kernel und Mesa auf der Userspace-Seite, eingebunden. Damit ist der Treiber sehr nah am generischen Linux-Desktop-Grafikstack, wodurch die damit ausgestatteten eingebettete Systeme weniger speziell werden und sich meist sehr ähnlich zu einem Desktop-Linux-System verhalten.

i.MX8MP GPU Inbetriebnahme mit upstream Treibern

Vor kurzem erhielt das Pengutronix Grafikteam den Auftrag die GPU auf dem NXP i.MX8M Plus , welcher sich aktuell im Vorserien-Stadium befindet, in Betrieb zu nehmen. Dieses SoC ist sehr interessant für viele Industriegerätehersteller, da die i.MX8M-Linie den technischen Nachfolger der sehr beliebten i.MX6 Linie darstellt. Ein sehr großer Teil der Software für diese ältere Linie, welche über die letzten 10 Jahre geschrieben und verbessert wurde, kann für den i.MX8M wiederverwendet werden. Dadurch reduziert sich der Aufwand für die Basisinbetriebnahme des Systems signifikant. Zudem bietet der i.MX8MP einige sehr interessante Features wie CAN FD und TSN Ethernet.

Die GPU auf diesem SoC ist eine leicht abgewandelte Variante des GC7000L, welche auf dem bereits schon unterstützten i.MX8MQ SoC zu finden ist. Während einige kleine Anpassungen nötig waren um den Open-Source-Treiberstack auf dieser speziellen GPU in Betrieb zu nehmen, belief sich der Aufwand unseres Grafikteams für diese Anpassungen auf weniger als eine Woche. An dieser Stelle zahlt sich die große Erfahrung des Teams in diesem Bereich aus.

Zögern Sie nicht uns anzusprechen, wenn Sie Unterstützung bei einem neuen oder bestehenden Projekt mit Grafik Ein- oder Ausgabe benötigen!