Grafik-Bibliothek für schnelles Rendering in Systemspeicher
-
Mein Anliegen bezieht sich auf die Erfahrungen mit Grafik-Bibliotheken, bezogen auf Features und Performance.
Ich möchte innerhalb eines Frameservers (z.B. Avisynth oder DirectShow) auf Bilder im Systemspeicher mit möglichst hoher Geschwindigkeit Text und andere Grafiken in vorrangig 3D, wenn möglich auch 2D, rendern.
2D könnte ich auch selbst mithilfe der 3D Features implementieren, jedoch wäre etwas vergleichbares wie D3D und D2D wünschenswert.
Es sollte demnach möglich sein, auf ein RGBA32 Bild mit Auflösung 1280x720 in weniger als 10ms den Teapot (bekannt von GLUT) zu rendern.Ich habe bereits diverse Erfahrungen gemacht:
- OpenGL mit FBOs scheiterte am AA. Das erforderliche Blitten vom Multisample Renderbuffer zu einer Textur, welche zum Lesen und Schreiben in/aus dem Video-Speicher diente, war ziemlich teuer.
- Unter den 2D Software Renderern hat einzigst Cairo ausreichend Geschwindigkeit bewiesen, jedoch halt nur in 2D.
- Nach einigen Recherchen über OSMesa verunsicherten mich Äußerungen bei Problemen mit AA und das Problem der langsamen Triangulation störte.
Ich wäre daher sehr dankbar für Empfehlungen bzw. Techniken, wie ich mein Vorhaben umsetzen könnte.
-
Youka schrieb:
OpenGL mit FBOs scheiterte am AA. Das erforderliche Blitten vom Multisample Renderbuffer zu einer Textur, welche zum Lesen und Schreiben in/aus dem Video-Speicher diente, war ziemlich teuer.
Das angesprochene Blitten von einem 1280x720 8x Multisample Buffer in eine Textur dauert bei meiner GTX560 0.2ms.
Den Inhalt der Textur zurueck in den Hauptspeicher zu lesen kostet natuerlich Zeit. Mit Hilfe von Pixel Buffer Objects kann man diese Uebertragungszeit sowohl verringern als auch vermeiden, dass man darauf warten muss.
-
Das Blitten der Farben eines 1280x720 FBOs mit 16x Multisample Renderbuffer auf einen FBO mit entsprechender Textur, durchgeführt mit einer GT130M, hatte bei mir allein (also nur der Funktionsaufruf) ~12ms gedauert. Rechnet man dazu noch die Übertragung in den Systemspeicher und geschieht das 2 mal - altes Bild rein, neues Bild raus - war ein starkes Ruckeln bei 25 Frames pro Sekunde/40ms pro Frame unvermeidbar, da das Dekodieren und die Farbraum-Umwandlung der Frames from Frameserver schon ~21ms kostet.
Ich meine damals gelesen zu haben, dass manche Grafikkarten mit dem zusammenlegen der Samples beim Blitten Probleme hätten...PBOs hatte ich überlegt, jedoch gelten diese als bereits lange veraltet und mir wurde erzählt, dass das Lesen/Schreiben aus/in Textur-Speicher weit optimiert wurde und es daher kaum einen Unterschied macht.
-
Youka schrieb:
Das Blitten der Farben eines 1280x720 FBOs mit 16x Multisample Renderbuffer auf einen FBO mit entsprechender Textur, durchgeführt mit einer GT130M, hatte bei mir allein (also nur der Funktionsaufruf) ~12ms gedauert.
Ist zwar eine andere Hardwareklasse aber kommt mir trotzdem ungewoehnlich viel vor.
Hast Du vor der Zeitnahme jeweils ein glFinish gesetzt? Sonst misst Du auch alle Operationen mit, die noch in der Render-Pipeline stecken.Youka schrieb:
PBOs hatte ich überlegt, jedoch gelten diese als bereits lange veraltet und mir wurde erzählt, dass das Lesen/Schreiben aus/in Textur-Speicher weit optimiert wurde und es daher kaum einen Unterschied macht.
Es gibt mittlerweile Funktionen die PBOs in vielerlei Hinsicht ersetzen.
Bei meiner Hardware ist es aber rund 2x schneller per PBO aus einer Textur zu lesen als einfach glReadPixels vom Framebuffer zu machen.
-
hellihjb schrieb:
Youka schrieb:
Das Blitten der Farben eines 1280x720 FBOs mit 16x Multisample Renderbuffer auf einen FBO mit entsprechender Textur, durchgeführt mit einer GT130M, hatte bei mir allein (also nur der Funktionsaufruf) ~12ms gedauert.
Ist zwar eine andere Hardwareklasse aber kommt mir trotzdem ungewoehnlich viel vor.
Hast Du vor der Zeitnahme jeweils ein glFinish gesetzt? Sonst misst Du auch alle Operationen mit, die noch in der Render-Pipeline stecken.glFinish hatte ich gesetzt und auch das ganze minimalisiert, um nur die Blit Funktion zu testen. Schien mir auch sehr ungewöhnlich, war aber leider so.
Um nochmal auf das Thread-Thema zurückzukommen:
Gibt es Bibliotheken, die wie in dem gerade diskutierten Fall arbeiten, also hardwarebeschleunigt mit vielen Features rendern und einen einfachen Transport der Daten zwischen Videospeicher und Systemspeicher anbieten?
-
Youka schrieb:
einfachen Transport der Daten zwischen Videospeicher und Systemspeicher anbieten?
Einfach ist der Transport eigentlich immer. Ob er schnell ist, haengt aber von der Hardware ab. Die ist dafuer nicht gedacht, kann sein, dass dies dein Problem ist.
-
Wofür genau brauchst du das 16x Multisampling?
-
Was ist denn mit dem Renderer den WPF verwendet wenn es keine kompatible Grafikkarte findet?
Wenn ich das richtig verstanden habe ist das ein vollständiger Direct3D Software-Renderer.
Wenn man ohne WPF irgendwie auf das Ding zugreifen könnte...
-
Du meinst WARP? Wollt ich auch schon vorschlagen, die Frage ist allerdings, ob Windows überhaupt eine Option ist. Und zuerst würd mich mal interessieren, wieso überhaupt so arges Multisampling (bei der Auflösung könnte man evtl. auch mit FXAA gute Ergebnisse erzielen) und ob er das Multisample target vor dem Download resolved oder tatsächlich die vollständigen multisampled Daten über den Bus jagt und wo tatsächlich die Zeit liegen bleibt (Stichworte Event und Query)...
-
Danke!
Ich denke das wird es sein.
Hab darüber nur mal im Zusammenhang mit WPF gelesen und mich dann nicht mehr weiter schlau gemacht ...Wobei ... was machen WPF Anwendungen unter Windows XP?
-
WARP ist glaub ich jünger als WPF, meine Erinnerung kann mich allerdings auch täuschen. Da die iirc damals ganz zufällig alle gleichzeitig rausgekommen sind, war meine persönliche Vermutung jedenfalls immer schon, dass Direct2D und DirectWrite sowie wohl auch WARP aus dem ursprünglichen, internen WPF Kram (milcore) hervorgegangen sind und nichts anderes als die nächste Evolution davon darstellen. Deren zeitliches Auftreten und die verblüffende Ähnlichkeit von Direct2D/DirectWrite mit WPF lässt imo praktisch eigentlich gar keinen anderen Schluss zu...
-
dot schrieb:
Und zuerst würd mich mal interessieren, wieso überhaupt so arges Multisampling (bei der Auflösung könnte man evtl. auch mit FXAA gute Ergebnisse erzielen) und ob er das Multisample target vor dem Download resolved oder tatsächlich die vollständigen multisampled Daten über den Bus jagt und wo tatsächlich die Zeit liegen bleibt (Stichworte Event und Query)...
Das 16x Multisampling war nur zu Testzwecken, um auszureizen, wie stark Antialiasing das Blitten beeinflusst, aber letztendlich war selbst das gewünschte 4x Multisampling nicht zufriedenstellend, dennoch deutlich besser.
Was du mit dem 'resolved' meinst verstehe ich nicht. Ich hatte halt eine FBO mit Multisample Renderbuffer als Colorbuffer, eine FBO mit Textur als Colorbuffer und zwischen ihnen geblittet, weil man auf einen Multisample FBO kein glReadPixel ausführen konnte. Vor dem Blitten wurde glFinish ausgeführt. Die Zeit habe ich mit clock gemessen und umfasste lediglich den glBlitFramebuffer Aufruf.
-
Youka schrieb:
Was du mit dem 'resolved' meinst verstehe ich nicht.
Bei Multisampling hast du mehr als ein Sample pro Pixel. Bevor die Bilddaten ausgegeben werden können, müssen die Samples auf die entsprechende Auflösung heruntergerechnet ("resolved") werden.
Youka schrieb:
Ich hatte halt eine FBO mit Multisample Renderbuffer als Colorbuffer, eine FBO mit Textur als Colorbuffer und zwischen ihnen geblittet, weil man auf einen Multisample FBO kein glReadPixel ausführen konnte. Vor dem Blitten wurde glFinish ausgeführt.
Wie genau hast du geblittet und die Daten zurückgelesen?
Youka schrieb:
Die Zeit habe ich mit clock gemessen und umfasste lediglich den glBlitFramebuffer Aufruf.
Auf einem Windows System? Wenn du Pech hast, dann hat clock() dort eine Auflösung im Bereich von 15ms und ist für derartige Dinge völlig unbrauchbar. Besser Queries verwenden, die Gesamtdauer über ein paar hundert Frames messen oder zumindest einen ausreichend genauen Timer nehmen...
-
dot schrieb:
Bei Multisampling hast du mehr als ein Sample pro Pixel. Bevor die Bilddaten ausgegeben werden können, müssen die Samples auf die entsprechende Auflösung heruntergerechnet ("resolved") werden.
Das habe ich durch das Blitting selbst bezwecken wollen. Der Multisample Renderbuffer war der Colorbuffer des Target FBOs. Weil der FBO dadurch mehrere Samples speichert, konnten nicht einfach Pixeldaten rausgelesen werden, sondern mussten vorher aufgelöst werden, was durch das Blitting in den FBO mit Textur (=nur ein Sample) als Colorbuffer gelöst wurde.
dot schrieb:
Auf einem Windows System? Wenn du Pech hast, dann hat clock() dort eine Auflösung im Bereich von 15ms und ist für derartige Dinge völlig unbrauchbar. Besser Queries verwenden, die Gesamtdauer über ein paar hundert Frames messen oder zumindest einen ausreichend genauen Timer nehmen...
Ich habe bei clock Abweichungen von bis zu 5ms festgestellt, aber selbst das Ruckeln des Frameserving, welches durch die Bearbeitungsdauer-Überschreitung von >20ms auftrat und der ruckelfreie Vergleich mit einem Renderbuffer ohne Multisampling haben mir Gewissheit verschafft.
-
Da der Threadtitel noch passt:
Welche Alternativen zu Cairo bieten sich an?Anforderungen (absteigend nach Priorität):
* Software-Renderer
* sehr schnell
* plattformunabhängig
* viele FeaturesAGG habe ich bereits ausgeschlossen.
-
Youka schrieb:
Welche Alternativen zu Cairo bieten sich an?
Du bezahlst jemanden, der für deinen Spezialfall eine solche Lib macht.
