Grafikkarte im 2D nutzlos?

Hallo

Beim beobachten in einer DAW die CPU last, stellte ich folgendes:
Die CPU reagiert mit einer steigerung der last, wenn zb Softsyntnthis auf dem bildschirm zusehen sind, und wenn ich etwas bewege, zb irgendwelche fenster in der DAW.

müßte das nich die graka übernehmen?
 
Nein, nicht automatisch. Die Anwendung muss dafür programmiert worden sein. Das ist wie bei MehrkernCPUs, wenn dein Programm nicht auf Multithread hin programmiert ist, dann nutzen auch die schönen 22 Kerne eines Intel Xeon E5-2699v4(€ 4.899) nichts.
 
Das hängt davon ab, wie das programmiert ist. Grafikprozessoren kommen erst dann zum Einsatz, wenn High-Level-Operationen durchzuführen sind. Also Flächen füllen, 3d-Objekte rendern etc. Das muss aber der Programmierer so vorsehen.
Wenn die Software sowieso Pixel für Pixel malt, dann hat die Grafikkarte nix zu melden.

Bei einer DAW würde ich als Entwickler den Schwerpunkt eher auf Audio- statt auf Grafikoptimierung setzen.
 
Bei Cubase dürfte es, dank dem shit AERO, die Graka
übernehmen. Ich finde die Bedienung mit Aero etwas
schwammiger, als wäre eine minimallatenz zu spüren.

Sei froh, dass deine DAW dir noch kein Aero aufzwingt :heul:
 
Die Grafikkarte muss der Programmierer aber in aller Regel nicht mehr selbst ansprechen. Wenn er GUI-Frameworks wie WPF unter Windows oder bei Java JavaFX nutzt, dann wird die Grafikkarte zum Rendern der GUI-Elemente verwendet(sofern unterstützt). Bitwig dürfte die Grafikkarte für seine GUI nutzen, denn diese wurde in Java geschrieben, der Rest ist bei Bitwig nativ programmiert, also eher C++ oder eine andere native Sprache. Bei den Plugins hingegen kann man es schlecht sagen, viele professionelle Entwickler nutzen Frameworks wie JUCE(ich glaube z.B. u-he).

@F.A.B.: Aero ist doch seit Windows7 tot.
 
Schon ewig wird Hardwarebeschleunigung zum Zeichnen des Windows-Desktops eingesetzt. Das merkt man spätestens dann, wenn die GPU-Treiber fehlen und man nur winzige Auflösungen fahren kann und der Desktop ruckelt. Ich kann mich sogar noch gut an meine Voodoo Banshee von '98 erinnern, die für ihre ausgezeichnete 2D-Leistung und der Hardwareunterstützung von GDI hoch gelobt wurde.

Hier ist ein längerer Artikel, der sich mit der 2D-Beschleunigung unter XP, Vista und Seven auseinander setzt und ein paar Fakten zu Aero und GDI erläutert:
http://www.tomshardware.de/WDM-GDI-WDDM ... 40480.html
 
Die GDI Beschleunigung und Co ist aber bei weitem nicht so schnell, als wenn wirklich die gesamte GUI in einem Rutsch per OpenGL/DirectX gezeichnet wird, so wie bei WPF oder JavaFX. Ansonsten hätte man sich die neuen Technologien auch schenken können.
 
Reverse And Play schrieb:
Die GDI Beschleunigung und Co ist aber bei weitem nicht so schnell, als wenn wirklich die gesamte GUI in einem Rutsch per OpenGL/DirectX gezeichnet wird, so wie bei WPF oder JavaFX. Ansonsten hätte man sich die neuen Technologien auch schenken können.

Das ändert aber einfach nichts daran, das GDI seit 15 Jahren eben auch durch Hardware, die nicht die CPU ist, beschleunigt wird. Die Frage im Threadtitel muss also klar verneint werden.
 
Neben dem eigentlichen Zeichen kann das u.a. auch an Synchronisationsobjekten liegen (z.Bsp. Mutexes, Events o.ä.). Ein hoher Anteil an Kernelzeit im Taskmanager kann ein Hinweis dafür sein.

Zudem "beschleunigt" auch der Idle Redraw Timer bei den meisten DAWs, wenn die Fenster sichtbar und im Vordergrund sind. Was dann u.a. auch vermehrte Anfragen an die Synchronisationsobjekte bedeutet. Das kann die Grafikkarte nicht leisten, weil diese Objekte ureigenster Teil des OS sind (zumindest bei Windows). Leider sind genau die in den meisten Fällen recht "teuer".
 
Oder es liegt einfach nur am Maus-Interrupt, der schon immer bevorzugt behandelt worden ist. Denn wenn man alleine den Mauszeiger bewegt, kostet das die CPU schon Rechenzeit. Wenn man wie ein Bekloppter die Maus rüttelt, dann kann man das auch im Taskmanager in signifikanter Weise sehen, ohne dass auch nur ein einziges Fenster dabei bewegt worden wäre.
 
Wenn ich meinen Mauszeiger wie verrückt über den Bildschirm jage und dabei DAW usw offen habe, dann steigt die CPU-Last von 2% auf 3%. Ich glaube dass es eher die unterschiedlichen Arten sind wie in den Fenstern gezeichnet wird. Wenn der gesamte Fensterinhalt per 3DCanvas(OpenGL, DirectX) gezeichnet würde, anstelle von GDI, GDi+, usw. dann wäre das alles butterweich und man würde sehr viel mehr von einer guten Grafikkarten auch auf dem Desktop profitieren.

Eine Grafikkarte ist daher im 2D nicht nutzlos, bleibt aber weit hinter ihren Möglichkeiten zurück. Diese müssten von dem Programm explizit oder implizit durch die Nutzung des/der richtigen Frameworks/Schnittstellen genutzt werden. Automatisch wird da nur wenig von dem ausgereizt was da ist, jedenfalls wenn ohne WPF etc gearbeitet wird.
 
Reverse And Play schrieb:
Eine Grafikkarte ist daher im 2D nicht nutzlos, bleibt aber weit hinter ihren Möglichkeiten zurück. Diese müssten von dem Programm explizit oder implizit durch die Nutzung des/der richtigen Frameworks/Schnittstellen genutzt werden.

Welchen konkreten Vorteil habe ich denn durch einen 3D-Kontext? Die Probleme fangen mit der Portierbarkeit an und enden auch nicht mit der uneinheitlichen Hardwareausstattung.

Sorry, aber für ne Desktop-Anwendung programmiere ich garantiert keinen Viewport in einer 3D-API. Ich will dabei ja ein Problem lösen und mir nicht stattdessen noch 10 weitere Probleme dazu holen. Es hat seinen Grund, warum z.B. Visual Basic nicht totzukriegen ist.
 
Ein Vorteil ist die Unabhängigkeit von den GUI Elemente des darunterliegendes Betriebssystem, wenn du wirklich von Scratch alles selbst in einen 3DCanvas zeichnest. Oft muss man dies ja gar nicht tun, wenn man z.B. WPF oder JavaFX nutzt oder auf andere Frameworks setzt, die schon den Hauptarbeit erledigt haben. Ein Programm was komplett alles selbst in einen OpenGL Canvas zeichnet ist z.B. Blender.
 
Reverse And Play schrieb:
Ein Vorteil ist die Unabhängigkeit von den GUI Elemente des darunterliegendes Betriebssystem, wenn du wirklich von Scratch alles selbst in einen 3DCanvas zeichnest. Oft muss man dies ja gar nicht tun, wenn man z.B. WPF oder JavaFX nutzt oder auf andere Frameworks setzt, die schon den Hauptarbeit erledigt haben. Ein Programm was komplett alles selbst in einen OpenGL Canvas zeichnet ist z.B. Blender.

:selfhammer:

Blender ist eine mittlere Katastrophe, was Usability und Lernkurve angeht. Ich sag ja: 10 neue Probleme.



Der Witz an einem Betriebssystem ist doch, dass dieses mir eine gewohnte Umgebung zur Verfügung stellt und sich alle Programme darin gleich anfühlen und verhalten sollen. Es soll redundante Aufgabenstellungen vermeiden, wie z.B. dass jeder Programmierer einen Dialog zum Öffnen von Dateien neu implementieren muss. Und genau in diese Kerbe schlagen auch die APIs, die mir Buttons und alle anderen GUI-Elemente zur Verfügung stellen.

Ich frag nach einem Vorteil und du sagst mir: Da kann man das Rad selbst neu erfinden, weil man wieder bei Null anfangen muss. :selfhammer:
 
DerGanner schrieb:
Es soll redundante Aufgabenstellungen vermeiden, wie z.B. dass jeder Programmierer einen Dialog zum Öffnen von Dateien neu implementieren muss. Und genau in diese Kerbe schlagen auch die APIs, die mir Buttons und alle anderen GUI-Elemente zur Verfügung stellen.
Aber da liegt doch schon genau ein Problem: wenn ich eine plattformübergreifende Applikation entwickle, will der Anwender dann einen Öffnendialog haben, der aussieht wie für alle anderen Programme auf dieser Plattform? Oder will er in meiner Applikation einen Dialog haben, der auf allen Plattformen gleich aussieht?

Will ich in meiner Applikation einen Dialog haben, der je nach Linux Distribution anders aussieht?

Bei Java Applikationen ist die Nutzung der betriebssystemeigenen Buttons etc. ja ziemlich schnell verschwunden und durch lightweight Elemente ersetzt worden, die auf allen Plattfomen gleich aussehen.
 
haebbmaster schrieb:
Will ich in meiner Applikation einen Dialog haben, der je nach Linux Distribution anders aussieht?

Im Zweifelsfall ja. Die User haben sich schließlich aus einem bestimmten Grund für eine bestimmte Distribution entschieden. An dieser Stelle den Geschmack des Programmierers höher einzustufen, als das, was die Benutzer erwarten könnten, kann sich ganz schnell als Schuss in den Ofen heraus stellen. Ich sag da nur "Start-Button" und "Windows 8" zu.
 
Durch WPF hast du doch die einheitliche Oberfläche des Betriebssystem und trotzdem eine viel bessere Graka-Unterstützung, als wenn nur GDI Zeugs genutzt wird, wie bei der üblichen 2D-Beschleunigung. Du musst also als Entwickler einfach nur das richtige Framework nutzen, mehr Arbeit ist nicht zu tun.

Ob man Blender mag, ist wieder ein ganz anderes Thema. Ich finde Blender sehr bedienerfreundlich im Vergleich zu Maya und Konsorten, die ich auch alle aus Neugier mal angetestet habe. Blender sollte hier auch nicht als Usability-Beispiel dienen, sondern nur zeigen, dass man durchaus auch komplett ohne Framework Unterstützung die gesamte GUI in einem OpenGL Canvas selbst machen kann und über die Jahre vielleicht sogar Entwicklungszeit einspart, weil die Anwendung exakt unter jedem OS so aussieht wie gewollt und zudem noch voll die GraKa nutzt. Man muss sich nicht jedes mal neu ans OS oder deren Versionen anpassen.

Eine Grafikkarte kann am besten arbeiten, wenn sie alle Calls auf einen Rutsch bekommt und dann stupide runter rendern kann. Dies kann man allein durch die richtige Wahl des Frameworks erreichen. Wer da per WinAPI noch mit GDI rum dockert muss sich nicht wundern, wenn die GUI viel langsamer ist als sie sein könnte. Das Qt Framework, was sehr oft mittlerweile für Applikationen genutzt wird, kann auch auf OpenGL als GraphicsSystem setzen. Da muss man als Programmieren nicht viel, außer vielleicht ein Flag setzen.

Es ist also sehr wohl eine Entscheidung des Programmierers wie gut die Grafikkarte seine GUI beschleunigt oder nicht.
 


News

Zurück
Oben