Alter Hut?

[Antoon]

Also wenn ich mir das so durchlese kommt mir das alles wie ein alter Hut vor. zB Firefox rendert doch schon lange alles mit 3D. Compiz und KWin (Linux Desktop) koennen doch schon lange alles mit 3D rendern. OSX auch. OpenGL ES Shader fuehren sogar ganze Programme auf der GPU aus. Also Zeichnen von geometrischen Figuren, Texturen draufpacken, animieren, Matrixmanupilation, diverse frei programmierbare und auf der GPU ausgefuehrte Objektmanipulationen und -animationen, usw. usf. ( http://opengles-book.com/ ).

Die Stromsparfunktionen sind jetzt auch nicht so der Bringer wenn ich mir Android angucke auf dem aggresives Powersaving moeglich ist. Also Anwendungen sich registrieren muessen um im Hintergrund weiterlaufen zu koennen ( http://developer.android.com/reference/android/os/PowerManager.WakeLock.html ) ansonsten werden sie schlafen gelegt. Mal ganz davon abgesehen, dass man das alles fein granulieren kann. So, kann eine Anwendung solange sie was downloaded im Hintergerund laufen und wenn der Download fertig ist, wird sie schlafen gelegt. Wobei das eigentlich nur fuer Geraete mit Batterie interessant ist solange die Killowattstunden noch unter einem Euro liegt. Auf einem modernen Desktop-Powervieh ist das alles eigentlich egal.

Koennte mir das mal jemand Vergleichend erlaeutern was da neu, anders, besser ist im Vergleich zu anderen Loesungen? Oder geht es nur um den Vergleich mit Windows7 und DirectX laesst sich nicht wirklich vergleichen mit anderen nicht-DirectX Loesungen wie OpenGL ES? Vielleicht hat ja auch jemand eine Quelle (Link oder sowas) welche etwas mehr technische Details liefert als der Artikel. Dickes Danke schonmal.



8 mal bearbeitet, zuletzt am 24.07.12 13:20 durch Antoon.

[Knarzi]

Firefox rendert erst seit Version 4, also nach erscheinen von IE9 und Windows 7 mit Direct2D und DirectWrite. Davor war es GDI+.

[birdy]

Nur weil man OpenGL/DirectX verwendet um zu zeichnen, heisst es noch lange nicht dass es schnell sein muss.
Das liegt daran, dass die HW voll auf Spiele ausgelegt ist. Was aber völlig andere Anfroderungen hat als bisherige Grafik-Frameworks.
Nun werden diese Grafik-Engines der Frameworks aber so umgebaut, dass sie intern eher wie Spiele-Engines arbeiten (Stichwort scene graph).

Dass aber nicht schon längst SIMD für JPEGs verwendet wurde, finde ich einfach nur traurig.

[derats]

Ähem Sorry, aber Aero/Compiz/Quartz rendern zwar auf der GPU, aber nur die Fenster und eben *nicht* deren Inhalt. Der wird weiterhin auf der CPU berechnet.
Wenn du Compiz hast und z.B. nen GTK-Desktop, wird der Fensterinhalt auf der CPU in einen Backbuffer gerendert und dann als Textur von Compiz im 3D-Modus irgendwo hingeklatscht.
Genau so funktioniert das auch bei Aero und Quartz, der Fenstermanager holt sich die Fensterinhalte aus einem Backbuffer, packt seine Fensterdekoration dran und klatscht es auf den Desktop.

Die Buttons, Schrift usw. in den Fenstern werden auf der CPU gerendert. Oder auch nicht, vgl. Chrome/Firefox-Hardwarerendering. Ist halt Anwendungsabhängig.

[Thaodan]

derats schrieb:
--------------------------------------------------------------------------------
> Ähem Sorry, aber Aero/Compiz/Quartz rendern zwar auf der GPU, aber nur die
> Fenster und eben *nicht* deren Inhalt. Der wird weiterhin auf der CPU
> berechnet.
> Wenn du Compiz hast und z.B. nen GTK-Desktop, wird der Fensterinhalt auf
> der CPU in einen Backbuffer gerendert und dann als Textur von Compiz im
> 3D-Modus irgendwo hingeklatscht.
> Genau so funktioniert das auch bei Aero und Quartz, der Fenstermanager holt
> sich die Fensterinhalte aus einem Backbuffer, packt seine Fensterdekoration
> dran und klatscht es auf den Desktop.
>
> Die Buttons, Schrift usw. in den Fenstern werden auf der CPU gerendert.
> Oder auch nicht, vgl. Chrome/Firefox-Hardwarerendering. Ist halt
> Anwendungsabhängig.
Qt beherrscht mittlerweile volles OpenGL rendering, bei GTK keine Ahnung.
Bei Qt ist Standardmäßig das Grafiksystem auf native Gesetzt was bei X11: Xrender ist.
Xrender hat mit dem Nvidia Treiber Hardware-Beschleunigung wie es bei ATI/AMD aussieht weiß ich nicht.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[Antoon]

Thaodan schrieb:
--------------------------------------------------------------------------------
> derats schrieb:
> ---------------------------------------------------------------------------
> -----
> > Ähem Sorry, aber Aero/Compiz/Quartz rendern zwar auf der GPU, aber nur
> die
> > Fenster und eben *nicht* deren Inhalt. Der wird weiterhin auf der CPU
> > berechnet.
> > Wenn du Compiz hast und z.B. nen GTK-Desktop, wird der Fensterinhalt auf
> > der CPU in einen Backbuffer gerendert und dann als Textur von Compiz im
> > 3D-Modus irgendwo hingeklatscht.
> > Genau so funktioniert das auch bei Aero und Quartz, der Fenstermanager
> holt
> > sich die Fensterinhalte aus einem Backbuffer, packt seine
> Fensterdekoration
> > dran und klatscht es auf den Desktop.
> >
> > Die Buttons, Schrift usw. in den Fenstern werden auf der CPU gerendert.
> > Oder auch nicht, vgl. Chrome/Firefox-Hardwarerendering. Ist halt
> > Anwendungsabhängig.
> Qt beherrscht mittlerweile volles OpenGL rendering,

Sogar recht gut. Man kann das auch per Anwedung ein- oder ausschalten.

> bei GTK keine Ahnung.

GTK, Motif, TK und Wx wahrscheinich weniger ist fuer mich aber nicht relevant.

[Antoon]

Knarzi schrieb:
--------------------------------------------------------------------------------
> Firefox rendert erst seit Version 4, also nach erscheinen von IE9 und
> Windows 7 mit Direct2D und DirectWrite. Davor war es GDI+.

Also schon viele Jahre. Das untermalt meine Vermutung, dass das alles schon Quasi-Standard ist. Nichts neues. Danke fuer die Bestaetigung.

[Thaodan]

Antoon schrieb:
--------------------------------------------------------------------------------
> Sogar recht gut. Man kann das auch per Anwedung ein- oder ausschalten.
>
> > bei GTK keine Ahnung.
>
> GTK, Motif, TK und Wx wahrscheinich weniger ist fuer mich aber nicht
> relevant.

Ok, das habe ich in letzter Zeit nicht getestet aber das hört sich gut an da hoffe ich das dass cairo-qt Toolkit (ac_add_options --enable-default-toolkit=cairo-qt) in Firefox bald benutzbar ist.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[Antoon]

birdy schrieb:
--------------------------------------------------------------------------------
> Nur weil man OpenGL/DirectX verwendet um zu zeichnen, heisst es noch lange
> nicht dass es schnell sein muss.
> Das liegt daran, dass die HW voll auf Spiele ausgelegt ist. Was aber völlig
> andere Anfroderungen hat als bisherige Grafik-Frameworks.

Deswegen wurden die Grafiktreiber ja auch alle vor vielen Jahren schon auf die neuen Anforderungen optimiert. Das ist jetzt ech nichts neues sondern Steinalt.

> Nun werden diese Grafik-Engines der Frameworks aber so umgebaut, dass sie
> intern eher wie Spiele-Engines arbeiten (Stichwort scene graph).

Ein Scene Graph dient dazu die Zusammenhaenge zu kennen um Optimierungen vornehmen zu koennen die ohne diese Zusammenhaenge nicht moeglich sind.

Laut dem Artikel hat Microsoft eben nicht genau an sowas gearbeitet sondern hat einzelne Zeichenoperationen wie Dreiecke optimiert. Ich kenne mich nicht so gut aus mit DirectX wundere mich aber schon, dass man in DirectX noch selber die Dreiecke zeichen muss. Stimmt das oder ist der Artikel da irrefuehrend? Hast du eine bessere Quelle? Im Vergleich, unter OpenGL ES arbeitet man viel weiter oben und laesst die GPU das alles machen. Das macht nicht nur das entwickeln einfacher sondern erlaubt auch Parallelisierung was in Zeiten von Mehrprozessorkernen ziemlich wichtig ist. Oder verwendet DirectX da einen anderen Ansatz?

> Dass aber nicht schon längst SIMD für JPEGs verwendet wurde, finde ich
> einfach nur traurig.

Die Geister die ich rief. Altlasten.

[bstea]

Seit Jahren?
Die Window-Manager benutzen Hardware-Beschleunigung für Fenstereffekte nicht zur Beschleunigung der GUI-Elemente. Dafür sind auch nicht die Fenstermanager zuständig.
Und darum gehts, alle Elemente profitieren von Hardware-Beschleunigung.

--
http://www.heise.de/open/meldung/Linux-auf-dem-Desktop-Europa-fuehrt-1243708.html
http://www.heise.de/newsticker/meldung/Immer-mehr-Linux-auf-dem-Desktop-1404775.html

[Thaodan]

Wie schon beschrieben Qt kann dies schon länger bei GTK keine Ahnung, also nichts neues.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[mw_blond]

FYI: http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/c8cc2c4873cf902b

[Thaodan]

Sieht nicht so gut aus...
Ich hoffe das es noch was wird, schade was meine C++ Kenntnisse so schlecht sind sonst würd' ich glatt versuchen zu helfen.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[bstea]

Das ist ein durcheinander bei den Toolkits, wie immer. Darauf verlassen kann man sich nicht, weil alles zu Compilezeit deaktivierbar ist.

--
http://www.heise.de/open/meldung/Linux-auf-dem-Desktop-Europa-fuehrt-1243708.html
http://www.heise.de/newsticker/meldung/Immer-mehr-Linux-auf-dem-Desktop-1404775.html

[Thaodan]

bstea schrieb:
--------------------------------------------------------------------------------
> Das ist ein durcheinander bei den Toolkits, wie immer. Darauf verlassen
> kann man sich nicht, weil alles zu Compilezeit deaktivierbar ist.
Standardmäßig ist es an das heißt native ist an und wenn Native also zb bei X11, Xrender Hardwarebeschleunigung kann auch Qt es, der OpenGL Render kann es da ist kla und der ist bei der Generic Build an und nur Sonderfälle verwenden keine Build bei der es nicht an ist. Also kannst du davon ausgehen das es in 90% der Fälle geht.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[/mecki78]

Antoon schrieb:
--------------------------------------------------------------------------------
> OSX auch.

Seit 10.2, also seit 2002, wird das Window Copositing im System praktisch komplett von der GPU gemacht. D.h. die CPU zeichnete zwar noch den Inhalt der Fenster, aber das Zeichnen der Fenster auf dem Desktop, das überlagern von Fenstern, sowie des Zeichnen des Desktops selber, geschieht komplett auf der Grafikkarte. Apple taufte dies damals Quartz Extreme.

Seit 10.4, also seit 2005, unterstützt das System auch fast alle anderen Zeichenoperation auf der GPU laufen zu lassen. Apple taufte dies damals Quartz 2D Extreme, heute heißt es QuartzGL, ist aber das gleiche. Wie gesagt, seit 10.4 ist es verfügbar, aber bis heute ist es standardmäßig ausgeschaltet. Es wird nur verwendet, wenn der Nutzer es explizit für das ganze System einschaltet (Apple bietet ein Tool dafür zum herunter laden) oder aber wenn eine App über ein entsprechendes Flag sagt, dass sie es gerne verwenden würde. Im letzteren Fall wird es nur für diese App eingeschaltet, d.h. die Zeichenoperationen dieser App laufen auf der GPU, während alle anderen Apps, ohne diese Flag, nach wie vor auf der CPU zeichnen.

Warum ist es nicht immer und für alle Apps eingeschaltet? Tests haben ergeben, dass bestimmte Zeichenoperation deutlich schneller auf der GPU laufen (5-20x schneller), andere hingegen laufen jedoch langsamer auf der GPU, nicht drastisch, aber doch spürbar (teilweise bis zu 5x langsamer). D.h. ob eine App davon profitiert oder nicht hängt davon ab wie die UI der App beschaffen ist: Was zeichnet die App, wie zeichnet sie es und wie oft zeichnet sie es? Da Apple das nicht im Vorfeld wissen kann, überlassen sie die Entscheidung den App Entwicklern. Jeder kann seine App selber testen, einmal mit und einmal ohne und wenn sie mit deutlich schneller läuft, dann kann er ja das Flag für seine App setzen.

Einige APIs von Apple sind immer GPU beschleunigt, z.B. CoreImage und CoreAnimation, da Apple genau weiß, hier kommen nur die Zeichenoperationen zum tragen, die auch garantiert schneller auf der GPU laufen. Das QuartzGL Flag beeinflusst also nur "normale" Zeichenoperationen, die direkt oder indirekt über die Quartz API zeichnen (die Standard Zeichen API unter OS X seit 10.0).

Mischformen sind mittlerweile auch möglich. So werden z.B. Buttons mit Quartz gezeichnet und somit normalerweise auf der CPU. Man kann aber einen Button (der nur ein spezieller Typ von View ist) "layer-backen", in diesem Fall hat der View eine CA Layer (CA = Core Animation). Eine CA Layer ist in Wahrheit nur eine OpenGL Textur auf der CPU. Wenn ich einen Button layer-backed mache, dann wird der Button immer noch auf der CPU gezeichnet, das Ergebnis landet dann aber in einer Textur und das Zeichnen des Buttons in das Fenster, bzw. das überlagern mit UI Elementen darüber und/oder darunter geschieht dann wieder auf CPU in OpenGL.

Man kann sagen was man will, aber ich fand schon immer, dass der Window Manager von OS X einer der performantesten auf dem Markt ist. Fenster bewegen sich absolut flüssig, die Animationen beim Minimieren/Maximieren von Fenstern oder beim Überblenden in Exposé sind butterweich. Und das selbst dann, wenn das System lasttechnisch am Anschlag ist. Dagegen sahen zumindest 2011 alle anderen Systeme größtenteils eher ruckelig und hackelig aus. Gut, hängt auch vom jeweiligen Hardware ab, aber gerade hier erreicht Mac OS X eine für den Betrachter sehr angenehme "Performance" sogar auf den schwächsten Systemen, während auf diesen Systemen andere OSes teilweise Augenkrebs verursachen und erst auf doppelt so schneller Hardware die gleichen weichen Ergebnisse erzielen.

/Mecki

[Antoon]

Das ist mal der detailtiefste und aufschlussreichste Beitrag den ich auf Golem seit langer Zeit gelesen habe. Wesentlich mehr als ich erhofft hatte zu erfahren. Wenn jetzt noch jemand Informationen zu DirectX liefert haben wir hier einen richtigen Fachbeitrag erschaffen den Golem so als ergaenzende Erlaeterung verlinken koennte. Danke dir mecki78!

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Seit 10.2, also seit 2002

10 Jahre. Haette ich jetzt nicht gedacht, dass das schon so alt ist. Hatte mehr mit 3-4 gerechnet. Aber zehn Jahre sind schon eine verdammt lange Zeitspanne.

> Warum ist es nicht immer und für alle Apps eingeschaltet? Tests haben
> ergeben, dass bestimmte Zeichenoperation deutlich schneller auf der GPU
> laufen (5-20x schneller), andere hingegen laufen jedoch langsamer auf der
> GPU, nicht drastisch, aber doch spürbar (teilweise bis zu 5x langsamer).

Dann stellt sich doch direkt die Frage wie Microsoft das Problem angehen will? Werden Metro Anwendungen diese Moeglichkeit haben?

Wir weiter oben schon angemerkt, ist dass unter Linux mit Qt auch moeglich. Man kann pro Anwendung waehlen ob OpenGL, Native, Raster und was es da sonst noch so gibt verwendet werden soll. Damit ist auch klar warum.



1 mal bearbeitet, zuletzt am 24.07.12 22:10 durch Antoon.

[Thaodan]

Übrings das geht einfach via:
>export QT_GRAPHICSSYSTEM=${YOUR_GRAPHIC_SYSTEM_HERE:-native}
bzw via.:
>QT_GRAPHICSSYSTEM=${YOUR_GRAPHIC_SYSTEM_HERE:-native} application_x

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[birdy]

Bezüglich der Qt render Performance hat Gunnar Sletta einige interessante Beiträge. Vor allem diesen hier:
http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/
Die Grafik am Ende ist einfach eindrucksvoll.

Interessant auch, dass z.B. die State-Changes die Performance bei OpenGL versauen, diese aber sehr häufig vorkommen. Durch den neuen Scenegraph werden einige davon aber vermieden.

MS hat schon bei Windows7 am Scenegraph gearbeitet. Ich nehme stark an, sie haben für Windows8 weiter daran optimiert.

[Antoon]

birdy schrieb:
--------------------------------------------------------------------------------
> MS hat schon bei Windows7 am Scenegraph gearbeitet. Ich nehme stark an, sie
> haben für Windows8 weiter daran optimiert.

Leider habe ich dazu keine einzige Quelle gefunden. Mit http://www.google.com/patents/US20070061733 gibt es ein Patent von Microsoft aus dem Jahre 2007 das einen Ansatz beschreibt. Es scheint aber (noch nicht?) in Windows integriert worden zu sein.