[OpenGL/Linux] Rendern direkt auf den Framebuffer

[Schrompf]

Moin Leute,

ich habe gerade ein mehr oder minder kritisches Problem auf einer Intel-Embedded-Plattform, auf der Ubuntu Hardy läuft. Der Grafikchip auf dem Ding kann angeblich OpenGL in gewissen Dosen, aber wieviel, weiß ich selbst noch nicht so genau. Das Problem ist jetzt, dass der grafische Output verschiedener Programme aus verschiedenen Prozessen so schnell wie möglich kombiniert werden muss. Normalerweise wäre das der Job eines Window Managers, soweit ich das verstanden habe, aber dieser Weg ist zu langsam. Wir brauchen Hardware-Beschleunigung.

Als Alternative kam der Gedanke, dass man die (bereits als Hardware-Surface vorliegende) Grafik auch einfach mit OpenGL rendern könnte. Der Chip kann grundlegende Operationen mit Alphablending, der Teil wäre also kein Thema. Dummerweise reichen meine Linux-Kenntnisse nicht aus, um dem dämlichen XServer zu sagen, dass er die Schnauze halten soll. Ich würde gern direkt auf den Framebuffer rendern, ohne irgendwelche Fenster oder sowas dazwischen zu schalten. Unter Windows gibt es da GetDesktopWindow(), was einem das Handle des Desktop-Fensters gibt, um darin einen Direct3D-Kontext zu erstellen. Gibt es sowas auch unter Linux und OpenGL?

Jede beliebige Information wäre sehr nützlich! Vielen Dank schonmal vorab.

Bye, Thomas

[kimmi]

Einen einfachen Zugriff könntest du so implementieren: http://de.wikipedia.org/wiki/Framebuffer . Allerdings handelt es sich hier eher um den rohen Zugriff auf den Framebuffer.
Hast du einme Dokumentation, ob der Treiber eigene .sos anbietet, um OpenGL-spezifische Calls abzusetzen? In der Regel bieter der Hardware-Hersteller dir ein SDK an, das dann OpenGL / OpenGL-ES unterstützt. So machen es zumindest unsere Devices hier. Allerdings sind die Docs dann gern ziemlich krude. Aber Dokumentation in dieser Richtung zu suchen wäre sicherlich der erste Schritt. Ohne genau zu wissen, wie die OpenGL sprechen, ist Hilfe schwierig.

Gruß Kimmi

[Schrompf]

OpenGL/ES liegt auf der Zielplattform an, die entsprechenden SOs sind da. OpenGL-SOs ebenso, ich vermute, die leiten dann nur auf ES-Calls um. Theoretisch müsste das GLlen also gehen. Praktisch hängt es aktuell an QT, aber der Teil ist eh ein Irrweg. Mein Problem ist jetzt eher, dass ich einen GL-Kontext ohne Fenster erstellen will, der einfach hinnimmt, was auch immer aktuell auf dem Bildschirm steht. Hat da jemand eine Idee?

[Sindwiller]

Hab selber nie damit zu tun gehabt, aber wahrscheinlich kannst du dir mithilfe dieser Bibliothek etwas zusammenfrickeln: http://directfb.org/
Kannst dir ja mal anschauen.

[BeRsErKeR]

Mein Problem ist jetzt eher, dass ich einen GL-Kontext ohne Fenster erstellen will, der einfach hinnimmt, was auch immer aktuell auf dem Bildschirm steht. Hat da jemand eine Idee?

Bin mir nicht 100%ig sicher, aber mit RootWindow(Display, ScreenNum) kommst du doch an das "root window" des jeweiligen Screens ran. DefaultRootWindow(Display) liefert das "root window" des Default Screens. Ob das nun gleichbedeutend mit GetDesktopWindow() von Windows ist weiß ich leider nicht. Dazu habe ich zu wenig mit XWindow gemacht.

[Florian Keßeler]

Also der Windowmanager ist eigentlich für nichts weiter zuständig, als Rahmen um Fenster zu malen und das Verschieben und Vergrößern der Fenster zu erlauben. Wenn der nervt, kannst du ihn einfach gar nicht erst starten. Der kann übrigens normalerweise nichtmal Transparenz oder sowas.

Was hält dich davon ab, einfach ein großes Fenster zu öffnen und da mit OpenGL reinzuzeichnen? Direkt in einen Framebuffer zeichnen, geht mit HW-OpenGL afaik nicht. Und SW-OpenGL mit mesa dürfte um einiges langsamer sein als alle anderen Möglichkeiten.

[Alexander Kornrumpf]

Wow, lange nicht gesehen.

[Jörg]

Von wem stammt die libEGL auf deiner Platform?
Gerade im embedded-Bereich gibt es die Moeglichkeit, dass man ohne einen Fenstermanager o.ae. via passender EGL-Bibliothek direkt auf dem fbdev ausgeben kann.

Ich wuerde versuchen, nur mit fbdev zu starten und schauen, ob Deine libEGL da noch mitspielt. Im schlimmsten Fall kostet dich das einen CPU-blit (versteckt in EGL), im besten Fall schreibt die GPU direkt in den richtigen Speicherbereich.

Joerg

[Schrompf]

Danke für die vielen Hinweise! Ich melde mich morgen, wenn ich es ausprobieren konnte.

[Sternmull]

Klingt so als wäre Wayland genau das was du brauchst. Dort ist auch von einem QT-Port die Rede. Außerdem dürfte dich interessieren das Ubuntu sowieso daran arbeitet auf Wayland umzusteingen.
Allerdings ist das alles noch im Entwicklungsstadium, kann also gut sein das es noch nicht brauhbar ist. Einen Versuch ist es aber wert.

Selbst wenn Wayland "out of the box" nicht hilft, könntest du dir dort abgucken wie verschiedene Prozesse auf gemeinsame OpenGL-Puffer zugreifen können. Bin mir relativ sicher das das dort gemacht wird.

[Schrompf]

Ein Update:

XDefaultRootWindow() ist tatsächlich die gesuchte Funktion, mit der man auf den Desktop rendern kann. Leider war das ein Holzweg, da ich OpenGL bisher nicht überreden konnte, direkt in den FrontBuffer zu rendern. Stattdessen rendert es immer in einen BackBuffer, der dann ohne jedes AlphaBlending in den FrontBuffer kopiert wird. Hm. Nix gewonnen.

Einen WindowManager gibt es auf der Zielplatform aktuell gar nicht. Eigentlich sollte das aus Performance-Überlegungen heraus auch so bleiben. Bislang sieht es aber so aus, als ob wir zumindest das Mischen mehrerer Fenster nicht ohne WindowManager schaffen. Die beiden Fenster stammen aus verschiedenen Prozessen, ich kann die beiden also nicht einfach mit OpenGL als Texturen verwenden und mit Hardware mischen. Vielleicht kriegen wir noch irgendwas mit SharedMemory und einmal engagiert umkopieren hin, aber vorher brauche ich erstmal noch die Antwort von Intel.

Der Tipp mit EGL direkt auf FB ist ein guter Gedanke. Leider sehe ich im Gesamtsystem noch nicht so durch, wie ich gerne möchte - ich bin hier nur als Feuerwehr hinzugezogen worden, weil ich mal irgendwas mit 3D Hardware und QT gemacht habe... und meine Linux-Kenntnisse sind ehrlich gesagt erbärmlich. Mal schauen, was die anderen davon halten.

Den Tipp mit Wayland verstehe ich nicht. Was ist Wayland? Wo in der Hierarchie steht das Ding und was tut es? Mir fehlen noch zuviele Architekturkenntnisse, um damit irgendwas anfangen zu können. Aber so, wie ich die Webseite verstanden habe, ist es eh alles noch Zukunftsmusik. Vor allem in Anbetracht des Zielsystems - Ubuntu 8.

Vielen Dank an Alle für die vielen Denkanstöße! Aktuell ist hier leider alles noch zu sehr im Fluss, als dass ich genau sagen könnte, in welche Richtung die Lösung läuft. Es werden aber hoffentlich heute abend ein paar weitere Informationen reingerollt kommen, wenn die Intel-Jungs in Amerika aufgestanden sind und ihre Mails lesen. Danach sehen wir weiter.

[kimmi]

Wayland soll den etwas in die Jahre gekommenen X11-Kram ablösen. Allerdings wird dir das nicht helfen, solange du nicht mal einen X-Server hast.

Gruß Kimmi

[Florian Keßeler]

Also ich weiß nicht, was du immer mit "mischen mit WindowManager" willst. Kein Window-Manager kann sowas. Windowmanager haben keinen Einfluss auf das, was im Fenster passiert, sie können höchstens noch ein bißchen drumherum zeichnen. Das einzige, was geht sind Compositing Window Manager, die dann aber wieder OpenGL-Extensions im X-Server brauchen und bei denen dann sowieso jedes Fenster eine Textur wäre. Müssen die Informationen denn wirklich zusammen in einem Fenster landen (sprich, reicht nicht einfach ein rechteckiger Bereich pro Datenquelle)? Weil dann könntest du einfach mehrere Fenster nebeneinander packen (ohne Windowmanager haben die dann auch keinen Rahmen) und könntest in jedem fröhlich OpenGL zum Zeichnen benutzen, ohne dir weitere Gedanken machen zu müssen...

[Schrompf]

Richtig, der WindowManager wird zur Composition zweier Fenster gebraucht. Wir haben einen Browser. Der Browser hat Plugins. Die Plugins müssen aus Gründen, die ich hier nicht ausführen kann, in einem separaten Fenster laufen. Der Bereich des Plugins im Webseitenfenster wird transparent gezeichnet, damit das Plugin-Fenster darunter zu sehen ist und gleichzeitig irgendwelche Javascript-Geschichten der Webseite das Plugin korrekt verdecken. Das geschieht entweder mit Color Keying oder halt mit Alpha-Transparenz. Und dazu brauch ich entweder die Video Planes des Grafikchips, einen Compositing Window Manager oder ich blende halt von Hand. Nur leider laufen Plugins üblicherweise im eigenen Prozess. Das macht die dritte Option zumindest anstrengend. Die Plane-Lösung wär mir die Liebste, aber da habe ich anscheinend nicht die Feinkontrolle, die ich brauche. Falls irgendwelche Videos auf der Webseite laufen, müssen die natürlich auch in Hardware dekodiert werden und beanspruchen eine Plane für sich. Dann zeichnet auch das Plugin nur Teile halbtransparent, so dass das dekodierte Video darunter auch noch durchscheint. Nicht ganz einfach, das alles.

[Jörg]

Bietet der Hersteller fuer diese Platform vielleicht etwas wie einen Unified Memory Provider ? Damit kannst Du genau das machen, was Du willst, Speicherbloecke von Prozessen gemeinsam nutzen lassen, GPU, Video-Dekoder, was weiss ich...ansonsten wirst Du um ein paar Kopieraktionen nicht herumkommen, die Du entweder selber erledigst oder halt eine "fertige" Kompositing-Loesung. CPU-Speicher kannst du ja noch recht einfach prozessuebergreifend nutzen (mmap), dann muessen aber alle relevanten Prozesse ihre Bilder via glReadPixels z.B. dorthin kopieren, und dein eigener Layer daraus wieder Texturen erzeugen, um sie zu verblenden.
Mit etwas Glueck findest Du eine OpenGL-Erweiterung vom Hersteller, die Texture-Daten ueber Prozessgrenzen hinweg gemeinsam nutzbar macht.
Aber so wie Du das aufgefuehrt hast, klingt das sehr nach "nur das verfuegbar, was unbedingt notwendig ist" ... :/

[Schrompf]

Tut mir leid, dass ich mich nicht mehr zurückgemeldet habe. Danke nochmal für die umfangreichen Hinweise, ich habe sehr viel dabei gelernt. Ich bin allerdings inzwischen von dem Problem wieder abgezogen worden. Soweit ich weiß, arbeitet die aktuelle Lösung jetzt wieder mit einem schlichten ARGB-XWindow, das über Qt erzeugt wird. Das Mischen mit Alphablending soll angeblich jetzt klappen, nachdem Intel endlich mal die Doku für ihre Grafik-Basislib rausgerückt hat. Die verschiedenen Fenster löschen u.U. noch einander aus, je nachdem wie sie zueinander liegen. Das ist aber eine Culling-Optimierung in deren Treiber, die davon ausging, dass sowas wie Alphablending nie passieren wird. Man hat uns wohl einen Fix für ihren Treiber versprochen, der aber noch aussteht. Mit dem sollte dann alles hardwarebeschleunigt funktionieren.

Aktuell ist hier allerdings auch auf globaler Ebene "Land unter" - kann sein, dass das Projekt im Ganzen geknickt wird. Schade um die ganzen Wochenenden, die wir hier reingesteckt haben. Braucht jemand einen kompetenten C++-Programmierer? Einzige Bedingung: ich mag nicht umziehen.

[kimmi]

Mein Arbeitgeber sucht, wenn auch in Lübeck...

Gruß Kimmi