Ueber Kernel auf Grafikkarte zugreifen

[einki]

Hi

Wenn ein Programm auf X mal laueft hab ich keinen grund zu klagen aber das starten dauert vor allem bei qt aber auch bei gtk applikationen imho viel zu lange.

Wenn ich etwas ueber localhost schicke wird das dann jedes mal in pakete verpackt und dann wieder die pakete glesen vom anderen Programm?
also so wie ne echte netzwerk verbindung nur, dass es eben nie ueber ein wirkliches Kabel geht.

Wäre mal richtig interressant eine X-Lib zu machen, die auf OpenGL als backend aufsetzt :-)

sicher nicht wenig arbeit....

by

[anda_skoa]

Original geschrieben von einki
Wenn ich etwas ueber localhost schicke wird das dann jedes mal in pakete verpackt und dann wieder die pakete glesen vom anderen Programm?
also so wie ne echte netzwerk verbindung nur, dass es eben nie ueber ein wirkliches Kabel geht.

Ja, korrekt.
Das loopback Interface ist für das Programm nicht von einem normalen Netzwerkinterface zu unterscheiden.

Aber es entsteht der Protokolloverhead, denn das Paket muss trotzdem durch den TCP Stack.
Darum wird bei Kommunikation, die nur lokal ist, oft auf schnellere Mechanismen zurückgegriffen, wie zum Beispiel Unix Domain Sockets, oder Shared Memory Kommunikation.
Das wird, wie ich im letzten Posting schon angedeutet habe, auch bei der X11 Kommunikation zwischen Clients und Server benutzt, die am selben Rechner laufen.

Ciao,
_

[Lin728]

Genau dieser Protokolloverhead ist es, der mich stört.
Auch wenn man das Protokoll nicht über TCP schickt (auch wenns ein loopback ist, dann halt wirds im Kreis geschickt), ist noch immer der nach-X-Protokoll und von-X-Protokoll Overhead drinnen, auch wenn dieses Protokoll in shared-memory.bereiche geschrieben wird.

[anda_skoa]

Out-of-process Kommunikation geht immer über ein Protokoll, direkter Funktionsaufruf geht nur im selben Prozess.

Ich glaube aber nicht,dass der Protokolloverheader sehr viel ausmacht, wahrscheinlich entsteht sogar mehr Verzögerung durch den zweimaligen Contextswitch.

Und für Applikation, die maximale Performance brauchen, gibt es ohnehin die Möglichkeit, direkt mit dem Treiber zu kommunizieren (DRI, DGA)

Wenn man sich ansieht, welche Applikationen dann sowas benutzen (OpenGL, Videoplayer), dann scheint es eher unwahrscheinlich, dass normale Applikationen irgend ein Performance Problem bei lokaler X-Kommunikation haben könnten.

Ciao,
_

[axeljaeger]

Das mag sein, das ein Videoplayer eine Ausnahme machen darf und dann direkt mit dem Treiber reden darf. Es ist aber umständlich, für sowas eine Ausnahme machen zu müssen. Es wäre ja nett, wenn man die Funktionalität gleich standardmäßig zur Verfügung hat. Damit wären wir wieder bei der alten Diskusion mit dem Windowmanager, der das dann auch nutzen könnte. OSX lässt grüßen.

[anda_skoa]

Das versteh ich jetzt nicht.
Man hat die Funktionalität ja standardmäßig zu Verfügung (entsprechender Treier vorrausgesetzt), wie würder der Player das sonst machen?
Der Player wird kaum für alle potentiellen Grafikkarten einen gepatchten Treiber oder gar X Server mitliefern.

Ciao,
_

[axeljaeger]

Man braucht spezielle Bibliotheken, um schnell auf die Grafikkarte zuzugreifen. SDL, OpenGL, XV und ähnliche. Das ist ein Umstand, der nicht sein müsste. Da kann man zwar in das gelobte X11 mit Extensions was einbauen, das ist aber allemal umständlicher, als wenn das alles von Haus aus angeboten wird. Wenn man jetzt eine durchschnittliche Grafikanwendung entwickeln möchte, braucht man wenigstens zwei verschiedene APIs: Ein Toolkit wie etwa Qt und eine weitere Bibliothek, die man einbetten kann, um damit im MainWidget die Grafiksachen zu machen. Es wäre nett, wenn die Methoden von z.B. QPainter gleich mit der maximal verfügbaren Geschwindigkeit zeichneten, was aber nicht geht, weil man ja nicht erwarten kann, das entsprechende Extension installiert sind. Wenn der X-Server von Haus aus einigermaßen schnell Grafikroutinen machen könnte, könnten diese auch in entsprechenden Toolkits genutzt werden. Kurz gesagt: Klar, man kann, wenn man will, einigermaßen schnell zeichnen, aber es wird einem schwerer gemacht, als nötig. Die API von X11 ist auch nicht das ware und so Sachen wie Expose auf dem Mac werden wir meiner Meinung nach mit XFree niemals sehen.

[anda_skoa]

Wenn man DGA von Haus aus geboten haben möchte, kann man ja auch ein Toolkit verwenden, das dies inkludiert.
Eben zum Beispiel SDL und für die Widgets ein darauf aufbauendes Toolkit wie zum Beispiel ParaGUI.

Soweit ich weiß kann man zumindest in Qt auch OpenGL verwenden wenn man möchte, ohne dafür eine extra Bibliothek mit anderer API benutzen zu müssen.

Ob die "durchschnittliche Grafikanwendung" DGA oder DRI benötigt, wage ich zu bezeifeln.

Es wäre sicher möglich, ein QPaintDevice zu implementieren, dass Extensions wie DGA benutzen kann, falls das Programm und der XServer am selben System laufen, das wird ja bei anderen Extensions wie XRender auch gemacht.

Nur scheint das bisher nicht nötig gewesen zu sein, sonst hätte es schon jemand gemacht oder als kommerzieller Kunde bei TT darum nachgefragt.

Es wird immer viel über X11 geschimpft, meistens ohne eine andere Implementierung als die des XFree86 Projektes zu kennen.
X11 wurde schon für Anwendungen wie CAD und Simulation eingesetzt, also PCs noch nicht mal annähernd die Rechnerleistung dafür hatten.

Es werden massig Vermutungen geäußert, dass die mögliche Netzwerktransparenz zu Problemen bei lokaler Benutzung führt, ohne das dafür Daten vorliegen.

X11 ist sicher nicht das beste mögliche Grafiksubsystem, aber äußerst flexibel und AFAIK das einzige betriebsystem-, plattform- und architekturunabhängige System, dass sich im produktiven Einsatz befindet.

so Sachen wie Expose auf dem Mac werden wir meiner Meinung nach mit XFree niemals sehen.

Musste da mal nachsehen, was das eigentlich ist.
Du könntest damit recht haben, würde mich wundern, wenn Apple da kein Patent drauf angemeldet hat.
Abgesehen davon hört es sich nicht so bahnbrechend an.
Boah, man kann damit den Desktop mit einem Tastendruck in den Vordergrund holen, irre

Ciao,
_

[axeljaeger]

Expose ist noch ein bißchen mehr: Du kannst damit alle Fenster, die gerade auf dem Schirm sind, also auch die minimierten, nebeneinander anzeigen und dir eins aussuchen. Außerdem kannst du mit einer anderen Tastenkombination alle offenen Dokumente nebeneinander anordnen. Das ist nützlich, da es auf dem Mac nicht üblich ist, alle offenen Dokumente in einen MDI-Workspace zu verpacken. Das man innerhalb von einer Anwendung mit einem kleinen Aufwand schon schnell zeichnen kann, ist mir bekannt, aber wenn der Windowmanager jetzt sowas machen will, sieht das ganz anders aus (Stichwort halbtransparente Fenster)

[Lin728]

1.) Zu der 2d-Performance:
Ich habe zu Hause einen Athon800 mit einer MatroxG400, die damals dafür bekannt war, die besten XFree-4.0-Treiber (2D) zu haben.
WindowsXP läuft (lief) auf diesem Ding ohne murren, KDE ist enorm zäh, was repainting etc. andgeht. Enorm mag übertrieben sein, aber schnell ist es nicht, es ist zäh, so oder so.


2.) Zu DGA:
DGA funktioniert nur im Vollbildmodus (für normale 2d-apps also total ungeeignet), außerdem raten die XFRee-86 Developer von der Verwendung ab, warum konnte mir keiner sagen, manche meinten es sei langsam, andere meinten, man könnte nicht garantieren, DGA auch in Zukunft zu unterstützten.


3.) Zu QT/OpenGL:
Was QT bietet ist einzig die Möglichkeit, ein openGL Canvas in QT zu integrieren.

4.) Zu den Simulationen auf X:
Jo, die Simulationen waren aber Rechenintensiv, nicht grafikintensiv. War das vor 1990??

Ich glaube es zeichnet sich schon ein Wechsel ab. Sun hat nachdem sie lange versucht haben Ihre Java2D-Renderer auch unter X auf Schuss zu bringen (auch für Solaris wichtig), sich nun endlich entschieden unter X alles in ein OpenGL Canvas zu rendern, und ich hab mal im IRC mit einem Java2D-Entwickler gesprochen, der gesagt hat, dass man sich gar nicht vorstellen kann wie gut das klappt.
Viele 2d-Programme gerade im 3d-Modelling bereich setzten auch 100% auf OpenGL, X wird nur mehr für events hergenommen.

Was ich daran schade finde ist. dass OpenGL eigentlich nicht für derartige Dinge erstellt wurde. Font-Handling und auch andere Sachen, die bei X an praktisch einem Punkt konzentriert sind (in X halt) müssen wieder getrennt implementiert werden.
Die XLIb auf openGL zu portieren würde zwar am Anfang klasse sein, weil man alle dynamisch gelinkten X-Programme direkt benutzen könnte, allerdings würde diese API dann auch von neueren Programmen benützt werden, was bedeutet man implementiert eine grauenhafte API nochmal auf einer anderen, nur damit man kompatibilität erhalten kann :-(

Eine Lösung wäre folgendes Design:
OpenGL --> 2D-OpenGL-Lib ---> X-Kompatibilitätsbibliothek.

Aktuelle Toolkits werden direkt auf die 2D-OPenGL-Lib portiert, während die alten noch immer mit der X-Kompatibilitätslib funktionieren würden. Soweit die Theorie :-)

Mfg

[peschmae]

soo toll tönt Expose nicht, von dem was ich gesehen habe.

Soviele Fenster, dass sich das lohnen würde hab ich eh nie auf einem Desktop - dafür hat man ja schliesslich mehrere davon.

Was ich allerdings toll finde ist, dass die apps verkleinert weiterlaufen (z.B. bei video-playern )

MfG Peschmä

[axeljaeger]

Du magst so viele Fenster eh nicht haben, ich aber schon. Ich brauche keine virtuellen Desktops, wenn ich auf einem Ordnung halten kann. Kann jmd. was dazu sagen, wie das bei Java/OpenGL mit Menüs und Tooltips aussieht, die über das Fenster hinausgehen? Ragen die aus dem Fenster raus, oder ist alles wie bei OpenOffice, wo die Menüs immer im Hauptfenster eingesperrt sind.

[Lin728]

Grüssi!

Normalerweise sind menüs immer neue Fenster, es kommt bei openGL dann halt drauf an, wie schnell sich ein neues Fenster und ein dazugehöriger OpenGL-Kontext erzeugen und wieder zerstören lassen.
Bei Menüs die flüssig sein sollen, darf das alles nur wenige ms dauern.

Mfg

[anda_skoa]

Original geschrieben von axeljaeger
Expose ist noch ein bißchen mehr:

Schon klar, ich war auf der Apple Seite dazu.
Ich fands nur witzig, dass das als eines der Features genannt wird, wo es das doch schon ewig gibt.

Das man innerhalb von einer Anwendung mit einem kleinen Aufwand schon schnell zeichnen kann, ist mir bekannt, aber wenn der Windowmanager jetzt sowas machen will, sieht das ganz anders aus (Stichwort halbtransparente Fenster)

Hmm, ok. Stört mich als Applikationsentwickler aber nicht.
Außerdem könnte der X Server jederzeit die Fenster ziwschenpuffern und alphablenden. Das ist IMHO eines der feinen Sachen an X. Man kann sowas implementieren ohne die Applikation oder den Applikationsentwickler mit solchen Sachen zu belasten.

Ein Applikationsentwickler macht seine Software für Leute die damit arbeiten müssen, wenn jetzt ein paar Marketingleute ein cooles Demo Setup brauchen, sollte das nicht die Arbeit des Applikationsentwicklers betreffen.

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Schon klar, ich war auf der Apple Seite dazu.
Ich fands nur witzig, dass das als eines der Features genannt wird, wo es das doch schon ewig gibt.

´

Wos? Wo gabs das denn schon vorher? OK, "Desktop anezigen", aber den Rest noch nicht.

Original geschrieben von anda_skoa

Hmm, ok. Stört mich als Applikationsentwickler aber nicht.
Außerdem könnte der X Server jederzeit die Fenster ziwschenpuffern und alphablenden. Das ist IMHO eines der feinen Sachen an X. Man kann sowas implementieren ohne die Applikation oder den Applikationsentwickler mit solchen Sachen zu belasten.

Ein Applikationsentwickler macht seine Software für Leute die damit arbeiten müssen, wenn jetzt ein paar Marketingleute ein cooles Demo Setup brauchen, sollte das nicht die Arbeit des Applikationsentwicklers betreffen.

Ciao,
_

Das führt dann nur leider dazu, das man bestimmte Typen von Applikation gar nicht machen kann. Mein Lieblingsbeispiel dazu: Sonique. Es hat lang gedauert, bis ich mich davon trennen konnte, und vollständig auf Linux umgestiegen bin. Es ist meiner Meinung nach auch nicht möglich, sowas nachzuprogrammieren. Es stimmt schon, das man in den X-Server so Sachen einbauen könnte, nur Apple und Windows haben das von Haus aus.