[linux-l] Vortragsfolien Kernel Graphics Interface am 7.2.2007

[olafBuddenhagen at gmx.net]

Hallo,

On Sun, Aug 05, 2007 at 12:14:39PM +1000, Peter Ross wrote:

> Schau mal zu newbus, das is durchaus kreatives Design;-)

Das ist erstens naheliegend; und zweitens eher ein internes Detail, was
niemanden außer den Kernel-Entwickern selbst interessieren sollte...

> Ich verfolge nicht alle Entwicklungen aktiv, sehe nur dies hier und
> da, aber besonders im Hinblick auf Abstraktion und Layering entwickeln
> sich die Kernel noch kraeftig.
> 
> Das mag nicht immer sehr offensichtlich sein (wer kuemmert sich schon
> um Hardware-Abstraktion, um VM-Layout und -Algorithmen,
> Prozessabstraktion, Mechanismen fuer die Zugriffskontrolle etc.),

Ich habe nicht gesagt, das Kernel sich nicht entwickeln. Ich habe
gesagt, dass es kaum wesentliche (und sichtbare) Innovationen auf Seiten
des Kernels gibt -- zumindest bei Mainstream-Systemen...

> KGI und GGI ist wohl auch ein Beispiel fuer Neuland.. Wie sieht es
> nmit der Akzeptanz und Unterstuetzung durch Xorg und die
> Graphikkartenhersteller aus?

Naja, die Situation hat sich in letzter Zeit ziemlich gewandelt; die
Folien beschreiben aber (gegen Ende) schon das aktuelle Bild.

Als GGI vor mehr als zehn Jahren ins Leben gerufen wurde -- damals war
der Kernelteil, der spaeter den Namen KGI bekam, noch essentieller
Bestandteil -- wurde es weder von den XFree- noch von den
Linux-Entwicklern besonders freundlich aufgenommen. Ich habe das nicht
miterlebt, und kann nicht beurteilen, ob das Design an sich abgelehnt
wurde, oder die damaligen Entwickler es nur schlecht kommuniziert haben.
Ich denke von beidem etwas: Immerhin waren es Leute, die weder in der
Linux- noch der XFree-Entwicklergemeinde eingebunden waren; aber alles
ganz anders machen wollten als es bisher gehandhabt wurde. Gleichzeitig
schienen die meisten Linux-Entwickler damals ueberzeugt, dass alles was
mit Grafik zu tun hat, nicht in den Kernel gehoert -- selbst die
eigentliche Hardwareansteuerung, die sonst immer Aufgabe des Kernels
ist... Auszerdem wollte KGI zu viel auf einmal machen; waehrend
Linux-Entwickler generell schrittweise punktuelle Verbesserungen
bevorzugen.

Obwohl mit den Framebuffer-Devices seit langem (einfache) Grafiktreiber
in Linux eingezogen sind; und obwohl X mit DRM laegst auch
Kernelunterstuetzung fuer bestimmte Arten des Grafikhardware-Zugriffs
erhaelt; war der Status bezueglich genereller Grafiktreiber im Kernel,
wie sie KGI vorschlaegt, bis vor kurzem unveraendert. Auf der
letztjaehrigen FOSDEM hatte ich mit einem X-Entwickler ueber GGI
gesprochen, weil er in seinem Vortrag etwas vorgeschlagen hatte, was
sich ziemlich aehnlich angehoert hat. Wir sind dann auch auf den
KGI-Teil gekommen. Irgendwann hat sich Keith Packard in die Diskussion
eingeschaltet, und ganz vehemennt gegen Kernel-Treiber argumentiert --
zu komplex und zu wenig Nutzen.

(Keith war sehr lange bei XFree dabei, und war wohl Hauptinitiator des
"neuen" X.org. Er hat den groeszten Ueberblick ueber die verschiedenen
Teile von X, und die ein erheblicher Teil der Neuerungen der letzten
Jahre geht mehr oder weniger direkt auf ihn zurueck.)

Anfang diesen Jahres gab es nun ein kleines "Gipfeltreffen" zwischen
Keith, Linus, und Dave Airlie. (Dave ist der Maintainer des DRM, und
einer der wenigen Entwickler, die sowohl an Linux als auch an X
arbeiten.) Thema war, wie man Suspend/Resume mit Grafikkarten *richtig*
macht. (Bisher werden dafuer Hacks verwendet, die mal funktionieren und
mal nicht...)

Die Ergebnisse dieses Gespraechs sind wenig ueberraschend: Zum einen
muessen die existierenden fbdev- und DRM-Treiber enger verknuepft
werden. (Immerhin greifen sie auf das gleiche Stueck Hardware zu!) Zum
anderen braucht der Kernel ein neues Modesetting-Interface, was maechtig
genug ist, dass es auch von den X-Treibern benutzt werden kann. (fbdev
ist zu begeschraenkt und unausgegoren dafuer...)

Bei der diesjaehrigen FOSDEM war Keith somit ploetzlich gluehender
Verfechter von Kernel-Modesetting... Die vorgebliche Komplexitaet des
Modesettings ist ploetzlich kein Thema mehr; es heiszt im Gegenteil,
dass es nur wenige hundert Zeilen sind, alles ueberhaupt kein Ding. Auch
soll der Grund, wieso XFree86 sich damals fuer Userspace-Treiber
entschieden hat, nur darin gelegen haben, dass es in der damaligen
(proprietaeren) UNIX-Welt fuer ein unabhaengiges Projekt nicht moeglich
war, Kernel-Treiber zu entwickeln; da dieser Grund aber hinfaellig ist,
spricht nichts mehr gegen Kernel-Modesetting, aber vieles dafuer...

Es ist noch nicht voellig klar wie das alles am Ende aussehen soll; es
gibt etwas unterschiedliche Meinungen ueber den besten Weg. Aber es
scheint darauf hinauszulaufen, dass die bestehenden DRM-Treiber (und die
DRM-Schnittstelle) um Modesetting erweitert werden, und dann als
universelle Grafikhardware-Ansteuerung dienen; waehrend fbdev zu einer
Legacy-Schnittstelle degradiert wird. (Naja, die minimale
Beschleunigung, die noetig ist, um die Framebuffer-Konsole halbwegs
effizient darzustellen, bleibt vielleicht auch im fbdev-Teil...)

Es gibt mehrere Gruende fuer DRM als Ausgangspunkt. Zum einen geht diese
Initiative hauptsaechlich von den X-Entwicklern aus, und die kennen DRM
nun mal besser. Dazu kommt, dass linuxfb generell als ziemlich unsauber
empfunden wird -- es macht teilweise zu viel und teilweise zu wenig.
Nicht zuletzt ist DRM portabel, im Gegensatz zu linuxfb. (Auch
Lizenzrechtlich...)

Diesen Fruehling haben einige Leute recht intensiv am DRM-Modesetting
gearbeitet (mit dem Intel-Treiber als erste Implementierung, wie bei
fast allen Neuerungen in letzter Zeit...); im Wesentlichen als
Portierung des bereits vorhandenen Modesetting-Codes aus dem
traditionellen Userspace-Treiber von xorg.

Spaeter ist es aber ins Stocken geraten; die Gruende dafuer kenne ich
nicht vollstaendig. Es scheint zumindest teilweise daran zu liegen, dass
TTM -- eine andere Neuerung, die vom DRM-Modesetting vorausgesetzt wird
-- noch nicht so weit ist. Aber generell bewegen sich die Dinge in die
richtige Richtung; es scheint nur noch eine Frage der Zeit zu sein...

Insgesamt erinnert der Ansatz mit DRM als universellem Treiber enorm an
KGI. Man kann wohl sagen, dass KGI als solches nicht mehr interessant
ist; aber das Design wurde schlieszlich als richtig erkannt (mit zehn
Jahren Verspätung...), und wird nun erneut implementiert -- diesmal aber
nicht von Auszenseitern und von Null auf, sondern von den X-Entwicklern
selbst und mit Segen der Linux-Entwickler, aufbauend auf allgemein
anerkannten Komponenten...

Bleibt noch die Frage nach dem -- eigentlich interessanteren --
Userspace-Teil von GGI. Der Entwickler, mit dem ich letztes Jahr
gesprochen hatte, scheint das Interesse an solchen Ansaetzen wieder
verloren zu haben. Dafuer ist beim DRM-Modesetting die Frage nach dem
Ansprechen aus dem Userspace aufgekommen; und es scheint klar, dass eine
generische Bibliothek, die sowohl vom X-Server als auch von anderen
Ansaetzen verwendet werden kann, wuenschenswert ist. libggi waere hier
eigentlich naheliegend (wenn man ein Backend fuer das DRM-Modesetting
implementiert) -- schlieszlich wurde sie im Grunde genau dafuer
geschaffen.

Leider wird GGI hier (bisher zumindest) nicht in Betracht gezogen: Kaum
jemand kennt es, oder nimmt es ernst. Das GGI-Projekt ist nach den
anfaenglichen Misserfolgen sehr in sich gekehrt; es wird praktisch
ueberhaupt nicht nach auszen kommuniziert. Wenn Leute GGI kennen, dann
meistens nur von den damaligen Flamewars -- sie denken dann immer an
"das Projekt, was Grafiktreiber in den Kernel packen wollte"... Was
damals schon ein Missverstaendnis war; und der spaeteren Orientierung
noch viel weniger gerecht wird.

Zum anderen haben die heutigen GGI-Entwickler einen voellig anderen
Fokus: Die gesamte Arbeit der letzten Jahre an libggi war darauf
gerichtet, das API noch eleganter und leistungsfaehige zu machen, damit
man besser native GGI-Anwendungen schreiben kann -- was eigentlich nie
das Ziel von GGI war. Immer wenn ich von GGI als Infrastrukturkomponente
fuer einen vereinheitlichen Ansatz zur Grafikunterstuetzung spreche --
also dem eigentlichen Zweck von GGI -- kommt von den Entwicklern
bestenfalls passives Interesse :-(

> Bietet KGIM dem Hersteller eine Moeglichkeit, eine stabile und
> kernelversionsunabhaengige Schnittstelle fuer binary drivers
> bereitzustellen? (das wuerden diese sicher begruessen).

Es gibt einige KGI-Entwickler, die das erreichen wollten; sogar
Portabilitaet auf ABI-Ebene zwischen verschiedenen Kerneln! Das waere
natuerlich absoluter Wahnsinn. Linux-Entwickler hielten noch nie viel
von stabilien Treiber-ABIs; und auch X hat vor einiger Zeit die Dummheit
eines solchen Ansatzes erkannt -- der xorg-Server bricht jetzt munter
mit fast jedem Release das ABI...

Ich persoenlich sehe Binaertreiber als Pest. Sollte KGI (oder DRM)
tatsaechlich solche beguenstigen, wuerde ich es als starkes Argument
*gegen* KGI/DRM sehen.

> Eine Frage zu ACCEL (http://www.kgi-project.org/interfaces.html), der
> Pfeil zwischen /dev/graphic und chipset, ist das eine Hintertuer, um
> Chip-Features zu nutzen, fuer die es unter KGI keine Schnittstelle
> gibt?

Es ist keine Hintertuer. KGI bietet sehr wenig Abstraktion; es definiert
eine feste Schnittstelle nur fuer allgemeine Funktionen wie Modesetting
und das Mappen des Framebuffers. Bei Chipsatz-spezifischen Sachen --
insbesondere allem was mit Beschleunigung zu tun hat -- gibt es freie
Hand für jeden Treiber. Die Abstraktion, also das Bereitstellen von
Hardware-unabhaengigen Schnittstellen, wird von einer
Userspace-Bibliothek uebernommen: Der libggi. (Der Kernel-Teil muss ja
nur fuer einen geregelten Zugriff sorgen; alles andere ist unkritisch
und unproblematisch, und kann getrost im Userspace stattfinden.)

Das ist im uebrigen genau der gleiche Ansatz, der auch von DRI benutzt
wird: Die Mesa-Treiber setzen die abstakte, portable Schnittstelle (in
dem Fall OpenGL) in Hardware-spezifische Kommandos um. DRM als
Kernel-Teil des Treibers ist lediglich dafuer verantwortlich, dass diese
dann auf kontrollierte Weise an die Hardware geschickt werden.

-Olaf-