Kernel-Log – Was 3.4 bringt (3): Grafik | heise online
heise PlusAbo
Anzeige

Kernel-Log – Was 3.4 bringt (3): Grafik

Linux 3.4 bringt einen ganzen Strauß von Änderungen an den Treibern für Grafikchips vom AMD, Intel und Nvidia. Der kommende Kernel enthält zudem einen weiteren USB-DisplayLink-Treiber und legt weitere Grundlagen zur besseren Unterstützung von Hybrid-Grafik wie Nvidias Optimus.

vorlesen Druckansicht 41 Kommentare lesen
Lesezeit: 14 Min.
c't Magazin
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Der bislang als Staging-Treiber gekennzeichnete, aber von Anfang an im DRM-Subsystem angesiedelte DRM/KMS-Treiber Nouveau legt mit Linux 3.4 die Staging-Einstufung ab; an den Schnittstellen, über die die Nouveau-Treiber in Libdrm, Mesa 3D und X.org mit dem Kernel kommunizieren, sollte es daher von nun an nur noch abwärtskompatible Änderungen geben.

Das Ablegen der Einstufung als unreif erfolgte überraschend und zusammen mit einem weiteren Highlight von Linux 3.4: Nur wenige Stunden nachdem Nvidia die GeForce GTX 680 vorgestellt hatte, erweiterten die Kernel-Entwickler den Nouveau-DRM/KMS-Treiber um rudimentäre Unterstützung für diese Grafikkarte. Anfangs konnte der dadurch nur typische Bildschirmmodi einstellen ("Modesetting"), darunter auch die zu gängigen Breitbild-Displays passenden Auflösungen, die der VESA-Treiber nicht beherrscht.

Mehr Infos

Entwicklungsstand

Klare Ansagen zum Fertigstellungstermin eines Linux-Kernels gibt es wie üblich nicht – bei der Freigabe der sechsten Vorabversion in der Nacht von Sonntag auf Montag erklärte Torvalds allerdings, die Freigabe von Linux 3.4 rücke in greifbare Nähe. Mittlerweile hat er allerdings noch einen siebten Release Candidate in Aussicht gestellt.

Einige Tage später folgten experimentelle Erweiterungen für den Nouveau-Code in Libdrm und X.org, durch den diese zusammen mit dem DRM/KMS-Treiber von Linux 3.4 2D- und Xv-Beschleunigung bei der GeForce GTX 680 bieten. Noch etwas später flossen dann Anpassungen in den Nouveau-Nvc0-Treiber von Mesa 3D ein – bis dato war der lediglich für die Fermi-Grafikchips zuständig, die auf den GeForce-Modellen der Serien 400 und 500 sitzen. Durch diese Anpassungen arbeitet der Mesa-3D-Treiber nun auch mit dem als NVE4 oder GK104 genannten Kepler-Chip der GTX 680 zusammen, mit der Nvidia den Generationswechsel von der Fermi- auf die Kepler-Architektur eingeläutet hat. Seit dem sind noch weitere Grafikkarten mit Kepler-Chips erschienen, die Linux 3.4 wohl noch nicht unterstützten wird.

Es dürften allerdings noch einige Monate vergehen, bis die größeren Linux-Distributionen alle für die GTX 680 benötigten Komponenten mitbringen. Bis sie alle Beschleunigungsfunktionen der Grafikkarte von Haus aus nutzen, dürfte es auch noch etwas dauern, denn zuerst muss jemand eine Open-Source-Firmware für die Grafikkarte schreiben. Wie bei einigen der neuesten Grafikchips der Fermi-Generation lassen sich die Beschleunigungsfunktionen der ersten Kepler-GPU nämlich bislang nur mit einer Firmware nutzen, die man Nvidias proprietären Grafiktreibern entlocken muss.

Nvidias Treiber unterstützten die GTX 680 seit der Version 295.33, die das Unternehmen parallel zur Vorstellung der Grafikkarte freigegeben hat. Mit diesem Treiber arbeitet auch das Power-Management und die Funktionen zur Lüfterregelung besser als mit dem Nouveau-Treiber – der beherrscht diese Funktionen selbst bei älteren Grafikchips von Nvidia bislang nicht oder nur rudimentär.

Der Radeon-DRM/KMS-Treiber des Kernels 3.4 wird die Grafikkerne der Familien "Southern Islands" (SI) und "Trinity" (TN) unterstützen (u. .a 1, 2, 3, 4). Zur auch als RAxx bekannten SI-Generation zählen die Grafikchips Tahiti, Pitcairn und Verde, die auf den Mittelklasse- und High-End-Karten der Radeon-HD-Serien 7700, 7800 und 7900 sitzen. Ein Gallium3D-Treiber für Mesa 3D, der mit dem Kernel-Treiber zusammenarbeitet, befindet sich in Entwicklung; eine Vorabversion ist Anfang April erschienen. Ein Treiber für den X-Server von X.org (DDX-Treiber) soll für Beschleunigungsfunktionen auf diesen Gallium3D-Treiber zurückgreifen; er ist aber bislang nicht erhältlich.

Trinity ist der Codename für eine mit Grafikkern ausgestatte Reihe von Prozessoren, die AMD vermutlich in den nächsten Wochen vorstellt. Sie sollen die Llano-Prozessoren aus AMDs Serie A beerben, die vornehmlich in PCs und Notebooks der unteren und mittleren Preisklassen eingesetzt werden. Kurz nachdem die Unterstützung für die Trinity-GPU in den Kernel einzog, erschien die Version 6.14.4 des Radeon-Treibers für den X-Server von X.org, der den auch Aruba genannten Grafikkern ansprechen kann; das gelang so schnell, weil die GPU eng mit dem Cayman-Chip verwandt ist, der zur schon länger unterstützten Northern-Islands-Generation (viele Karten der 6000er-Serie) zählt. Parallel hatten AMD-Entwickler auch die Libdrm und den Entwicklerzweig von Mesa 3D um Unterstützung für die Trinity-GPU erweitert.

Mehr Infos

Die "Was Linux 3.4 bringt"-Serie

Das Kernel-Log kann bereits jetzt einen Überblick über die wichtigsten Neuerungen der noch im Mai erwarteten Linux-Version 3.4 geben, da alle größeren Neuerungen bereits in den ersten zwei Wochen nach Fertigstellung des Kernels 3.3 integriert wurden; Linux 3.4 befindet sich daher jetzt in der Stabilisierungsphase, in der die Kernel-Hacker normalerweise keine größeren Änderungen mehr vornehmen.

Über einige der Neuerungen von Linux 3.4 hat das Kernel-Log bereits berichtet:

Dieser Artikel schließt die "Was 3.4 bringt"-Serie ab.

Für die Northern-Islands-Chips sowie die Vorgängergeneration "Evergreen" (viele Karten der 5000er-Serie) bringt Linux 3.4 2D-Tiling-Unterstützung; diese Technik verteilt die Daten auf eine Weise im Grafikspeicher, welche die Performance verbessern kann. Das Tiling lässt sich zusammen mit dem Radeon-DDX-Treiber x86-video-ati 6.14.4 nutzen.

In den Kernel 3.4 ist zudem eine zweizeilige Änderung eingezogen, durch den der Nutmeg genannte "DisplayPort auf VGA"-Adapter bei Serie-A-Prozessoren nun endlich funktionieren soll. Diese Korrektur entstand nach mehreren Wochen Fehlersuche, die der zuständige Entwickler Jerome Glisse im Blog-Eintrag "Weeks in the life of GPU driver developer" in einer Weise beschreibt, die zeigt, welchen Aufwand die Kernel-Entwickler teilweise treiben.

Intel

Die Intel-Entwickler haben einen Patch eingebracht, durch den Linux 3.4 die Grafikkern-Stromspartechnik RC6 bei Intels Sandy-Bridge-Prozessoren mit GPU (Graphics Processing Unit) standardmäßig verwendet. Da die Technik die Leerlauf-Leistungsaufnahme typischerweise um drei bis fünf Watt senkt, kann die Änderung die Akku-Laufzeit von Notebooks spürbar verlängern und die Geräuschentwicklung merklich senken, da die Lüfter weniger Wärme wegschaffen müssen. Über den Kernel-Parameter "i915.i915_enable_rc6=1" kann man die Stromspartechnik auch bei älteren Linux-Versionen aktivieren; bei manchen Systemen soll sie allerdings zu Abstürzen oder Bildfehlern führen.

Diese Probleme will man beseitigen, indem Linux nun den tiefsten Schlafzustand von RC6 meidet. Laut den Intel-Entwicklern soll der tiefste Schlafzustand die Leistungsaufnahme nicht viel weiter reduzieren als der jetzt verwendete, weniger tiefe Modus. Anwender, die trotzdem den tiefsten Schlafzustand der Sandy-Bridge-GPU nutzen wollen, können diesen über Kernel-Parameter freigeben, die ein ebenfalls für Linux 3.4 aufgenommener Patch nachrüstet.

Die Intel-Entwickler haben zudem einen Bug im Intel-DRM/KMS-Treiber i915 behoben, durch den es gelegentlich zu Speicherverfälschungen kam, wenn diese aus dem Ruhezustand (Hibernate/Software Suspend/ACPI S4) aufwachen. Die Korrektur für das wohl schon über ein Jahr alte Problem ist auch in die Stable- und Longterm-Kernel 3.0.27, 3.2.14 und 3.3.1 eingeflossen.

Der Intel-Treiber wird ab Kernel 3.4 Interlacing bei der Ausgabe via HDMI und SDVO beherrschen (1, 2). Der i915-DRM/KMS-Treiber sollte bei neueren Grafikkernen die beiden bislang ungenutzte Techniken Swizzling und Ppgtt nutzen, die die Grafikperformance etwas verbessern können. In der Stabilisierungsphase wurden allerdings Probleme beim Zusammenspiel zwischen DMA-Remapping und Ppgtt bekannt, daher nutzt der Kernel letzteres nur, wenn das unter anderem für VT-d benötigte DMA-Remapping nicht aktiv ist – etwa wenn man VT-d im BIOS-Setup deaktiviert hat.

USB-Displays, Hybrid-Betrieb

USB-Monitortreiber

Zum Kernel stieß ferner der einfache DRM/KMS-Treiber "udl". Er spricht das DisplayLink-Protokoll, das bei der Ansteuerung von Monitoren via USB zum Einsatz kommt. Der maßgeblich von Dave Airlie entwickelte Treiber unterstützt die wichtigsten Funktionen von UDL-Hardware und bietet ein einfaches KMS-Interface, an dem der kürzlich vorgestellte X-Server-Treiber xf86-video-modesetting andocken kann. Dieser DDX-Treiber setzt voll auf KMS und enthält keine Grafikchip-spezifischen Funktionen, wie es bei den mittlerweile vielfach auf KMS angewiesenen X.org-Treibern Intel, Nouveau und Radeon der Fall ist. Der Modesetting-Treiber arbeitet daher auch mit anderen KMS-Treibern zusammen – darunter etwa jenem für den GMA500-Grafikkern in Intels US15W-Chipsatz (Poulsbo)

Der Udl-Code stammt zu großen Teilen vom Framebuffer-USB-DisplayLink-Treiber Udlfb ab, der schon länger im Kernel enthalten ist und einen ähnlichen Funktionsumfang bietet. Durch die Portierung auf die DRM/KMS-Infrastruktur, auf der auch andere Grafiktreiber aufsetzen, profitiert dieser von den dortigen Grundlagen; einige von ihnen sind etwa zum Betrieb des als X-Server-Ersatz konzipierten Grafiksystems Wayland wichtig. Zudem unterstützt Udl auch das An- und Abziehen des Monitors im laufenden Betrieb.

Der Udl-Treiber ist eine von mehreren derzeit in Entwicklung befindlichen Änderungen an Kernel, X-Server und Co., durch die sich verschiedene Grafik-Hardware bei laufendem System aktivieren und deaktivieren lassen soll, ohne dass der Anwender den X-Server neu starten oder anderweitig Hand anlegen muss.

Ein anderer Baustein ist das ebenfalls für 3.4 aufgenommene Grundgerüst des Frameworks Prime/Dma-Buf, über das Grafikkerne ohne viel Overhead Daten austauschen sollen. Langfristig soll das die Unterstützung für im Betrieb zuschaltbare Grafikchips verbessern, damit etwa ein Nvidia-Chip die von ihm berechneten Bilder ohne viel Aufwand an den Grafikkern des Prozessor übergeben kann, damit der diese ausgeben kann. Auf diese Art geben die GeForce-Chips aktueller Optimus-Notebooks das Bild aus; auch AMDs Hybrid-Grafik-Lösung arbeitet auf aktuellen Systemen so.

Bislang nutzt allerdings kein Treiber die neue Infrastruktur; entsprechende Erweiterungen für die DRM/KMS-Treiber Nouveau, i915, Udl, Exynos und Omap sollen bei Linux 3.5 folgen.

Zum Linux-Kernel stieß ein Plattform-Treiber für "Gmux"-Hardware, mit der einige Apple-Systeme zwischen zwei Grafikchips umschalten. Der Treiber bringt allerdings noch keine volle Unterstützung zum An- und Abschalten des zweiten Grafikchip, sondern ermöglicht bei den unterstützten Apple-Systemen lediglich ein Einstellen der Bildschirmhelligkeit.

Über neue Funktionen kann man dem Kernel die zur korrekten Bildschirmansteuerung nötigen Informationen (EDID/Extended Display Identification Data) beim Booten mitgeben oder diese via Sysfs nachladen. Das kann sich als Workaround anbieten, wenn KVM-Switches den Informationsfluss stören oder Bildschirme und Grafiktreiber die EDID-Informationen nicht korrekt liefern; Details liefert ein Artikel des OSADL (Open Source Automation Development Lab).

Für einfache Fälle reicht allerdings zumeist der schon länger im Kernel enthaltene Kernel-Parameter "video", über den man einen einzelnen Modus vorgeben kann; "video=1024x768-24@75" gibt beispielsweise eine Auflösung von 1024 × 768 Bildpunkten mit 24 Bit Farbtiefe und einer Bildwiederholrate von 75 Hertz vor.

Die kleinen Perlen

Einige weitere Informationen zu den Änderungen bei Grafiktreibern liefert der Haupt-Git-Pull-Request von DRM-Subsystem-Betreuer Dave Airlie.

Die folgenden Links führen zu einigen kleineren, aber keineswegs unbedeutende Änderungen:

Ein "C" im Bereich "[  ]" kennzeichnet Commits mit Änderungen an Kconfig-Dateien, welche die Konfigurationsoptionen samt der zugehörigen Hilfetexte enthalten. Mit "D" ausgezeichneten Patches verändern die dem Kernel beiliegende Dokumentation; Commits mit "N" legen neue Dateien an. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: Eine "1" kennzeichnet Patches, die inklusive Kommentar zwischen 10 und 20 KByte groß sind; Patches mit einer "9" sind 90 KByte oder größer. Änderungen ohne Zahl sind kleiner als 10 KByte.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor".

(thl) (thl)

Beliebte Bestenlisten

Alle Angebote
Newsletter heise-Bot heise-Bot Push Nachrichten Push Push-Nachrichten