Hi,

im zuge meiner umstellung auf OpenGL 3.0 bzw ES habe ich mich gestern dran gesetzt und alle glBegins die ich so hatte durch VBOs ersetzt.
Das hat auch alles super geklappt und performance mäßig hat es auch nicht geschadet - bis zu dem moment wo ich zu meiner Font-Class kam.

Ich hab in meinem Beispiel einen Text der mehrere tausend buchstaben lang ist.. bisher hab ich halt jeden Buchstaben mit einem glBegin(GL_QUADS) gezeichnet.. jetzt halt identisch auf VBOs umgestellt.

Meine arbeitsweise dabei ist, ich habe EINEN VBO der 4 Vertices groß ist (+ TexCoord + Color + Normal) und passe da für jedes Quad einfach die VertexPositionen und TexCoords an.

Dadurch muß ich dann für jedes Quad ständig diese zeilen zum updaten des VBOs aufrufen:



Natürlich für jeden der 4 buffer einzeln (Normal, UV, etc).

Und schwupp wurde es extreeeem langsam.
Als ich den mode dann auf GL_DYNAMIC_DRAW umgestellt habe wurde es zwar ein ganzes stück schneller, aber immernoch extrem langsam im vergleich zu glBegin.

Alles was ich tue ist für jedes quad die buffer zu updaten (siehe oben) und dannach ein simples:



Den VBO neu binden in dem sinne tue ich garnicht.

Jetzt ist die frage, wie kann ich hier noch geschwindigkeit rausholen?
Bzw.. wie macht es der Treiber intern bei glBegin..? ich dachte der wandelt das auch in einen VBO um..?! Wie kann der soviel schneller sein dann?

Mir würde ansonsten nur eine möglichkeit der optimierung einfallen:
Speziell bei der Font-Class bekommt jedes Font Objekt einen eigenen VBO in den alle Quads des textes reinkommen.. das kann halt bei einem "Hello world" recht kurz werden oder bei nem langen text auch sehr groß.

Es wäre ein ziemlicher verwaltungs aufwand weil bei mir nicht zwingend alle buchstaben auf der gleichen textur sein müßen...


Hat noch jemand ne andere idee?

Aya~

soweit ich weiß ist es am besten bei solchen glTexten alle Buchstaben in ein VBO zu sammeln. Einen Texturwechsel kannst du zwischen durch nur sehr schlecht machen, allerdings frage ich mich aus welchem Grund du innerhalb eines Textabschnittes zeichen aus verschiedenen Texturen verwendest. Ich habe bei mir in einer Textur immer den kompletten ASCII-code einer Schriftart untergebracht. In den meisten Fällen reicht das um Texte darzustellen und Schriftartwechsel innerhalb eines Textes sind Grafischer Natur das schlimmste was man einem Text an tun kann. Ich würde also dazu raten alle Buchstaben bei der Textübergabe (oder wenn du den Textänderst) in ein VBO zu zeichnen und auf eine Textur pro Text umzusteigen.

P.S.: Ich kenne mich mit 3d Texturen nicht aus, kann man da nicht was drauß machen, wenn man alle Schriftsätze in eine 3d-Textur legt und man die 3te Koordinate verwendet um die einzelnen Schriftsätze durchzublättern?

_________________
Klar Soweit?

guck dir mal glBufferSubData an ... ich bin mir nicht sicher aber schneller wie glBufferData sollte es schon sein.

Hi,

das nicht alle Buchstaben in der gleichen textur liegen liegt bei mir an meinem Font-System.
Buchstaben werden erst erzeugt und in die Textur gepackt wenn sie benötigt werden, wobei eine Textur maximal 512x512 groß werden darf.

Der vorteil daran ist einfach das ich JEDES zeichen das es gibt so immer in die Textur packen kann wenn es benötigt wird (via FreeType)... (Also ich kann jegliches Unicode-zeichen problemlos darstellen ohne irgendwas speziell dafür tun zu müßen) und wenn die Font-Größe sehr groß ist, passen auch mal nur weniger zeichen in eine textur etc.

Aber klar, in der regel sind alle ASCII zeichen in einer Textur - aber halt nicht garantiert.



Das schau ich mir heute abend mal an, wusste ich garnicht das es das gibt

Aya~

Sellmann: Das Funktioniert aber nur mit dem Ansi Zeichensatz. Wenn du aber wirklich alle Buchstaben eines Fonts haben willst, dann wird man nicht umher kommen sich die Texturen dynamisch zusammen zu bauen. Und je nach Anzahl der Zeichen, Fonts und Reihenfolge kanns schnell mal passieren, dass 'a' und 'b' eines Fonts in unterschiedlichen Texturen landen.

Aya: Ich würde auch Zeichen sammeln und dann diese Zeichen am Stück darstellen. Du kannst eventuell auch Texturabhängig zeichen Sammeln. Also wenn du abwechselnd Textur 1, 2, 1, 2, 1, 2 hättest, dann machst du 2 Puffer. Einen für Textur 1 und einen für Textur 2. Wenn du fertig bist oder die Puffer voll sind, dann kippst du die einfach aus. Die Reihenfolge der Buchstaben wären dann zwar durcheinander aber wenn sich die Zeichen nicht überlagern ist das grafisch ja egal.

Zu glBufferSubData. Da muss man mal schauen schneller ist. Entweder das glBufferSubData oder das vbo kurz writeonly mappen und daten reinschreiben.

Ich weiß nicht, ob Lossy EX das sogar meinte, aber du könntest ja auch "thematisch" sammeln. D.h., du sagst, dass unsere arabischen Zeichen in eine Textur kommen, chinesische in eine, usw.. Kaum einer wird ja da sehr viel wechseln. Wobei ich mich frage, warum du unbedingt maximal 512x512 Pixel möchtest für eine Textur? Wenn du dich so auf OpenGL 3 vorbereitet und nurnoch mit VBO's hantierst, dürfte ein PC, wo 512x512 viel ist, für deine Projekte eh nicht mehr schnell genug sein?

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Hi,

wenn ich es nach texturen aufsplitten muß, würde ich vermutlich mit einem Index-Array für den VBO arbeiten, also ein VBO wo ALLE Quads drin sind und dann via Index-Array immer die für jede textur zeichnen..

Was mich an der lösung allerdings stört ist: Dann ist zwar die Font-Klasse optimiert... aber die ganzen Quads die man sonst mal hier und da immer zeichnet (wo es wirklich einzelne quads sind) hinken dann trotzdem dem normalen glBegin hinterher... auch wenn es da natürlich kaum ins gewicht fällt..


Wie schaut denn das mit glMapBuffer aus? Das hab ich nie verwendet weil ich nie verstanden habe was daran besser ist als an der anderen herkömmlichen methode mit glBufferData.. aber so wie ich es jetzt verstehe liegt dabei das VBO im normalen RAM und wird immer von dort aus gezeichnet.. stimmt das?
Das würde bedeuten wenn ich dann die daten im RAM da wo das VBO hingemappt wurde verändere und zeichne, bräuchte ich keinen update mehr machen wie bisher... richtig?

Aya~

Ziz: Nein ich meinte nicht die Zeichen in unterschiedliche Texturen packen. Sondern mit Sammeln meinte ich die Buchstaben die gezeichnet werden sollen. Diese sollten irgendwo zwischengepuffert werden. Und dann kann es passieren, dass beim Text von "Hallo Spencer" das 'e' in einer anderen Textur liegt als der Rest. Wenn man dann je nach Textur zeichnen würde, dann würde man folgende Stückchen zeichen. "Hallo Sp", "e", "nc", "e" und "r". Also wenn man nur einen QuadPuffer hätte. Weil für jedes 'e' die Textur gewechselt werden müsste. Wenn man aber für jede FontTextur einen Puffer hat, dann würde ein Puffer nur die beiden 'e's enthalten und der Andere die restlichen Buchstaben. Am Ende würde man so 2 Mal zeichnen und texturen wechseln müssen und nicht 5 Mal. PS: Wenn du nur benötigte Zeichen erstellt, dann kommt man mit einer 512x512 großen Textur schon ziemlich weit. Sofern die Zeichen nicht zu groß werden.

Aya: Die GPU arbeitet asynchron. So etwas wie glBufferData und glSubBufferData sorgen aber dafür, dass die Arbeit synchronisiert werden muss. Der Grund ist einfach. Beide Methoden bekommen einen Speicherbereich übergeben der nur wärend des Funktionsaufrufes garantiert gültig ist. Es kann sein, dass der Speicherbereich direkt im Anschluss gelöscht wird. Außerdem kann es sein, dass das VBO von der GPU gerade benutzt wird. Wärend dieses Zeitraumes darf der Treiber keine neuen Daten in das VBO schreiben. Würde sonst wohl zu sehr Lustigen Effekten kommen. Deswegen MUSS glBufferData und auch glSubBufferData so lange warten bis das VBO nicht mehr benutzt wird (auch zukünftige Befehle in der Befehlsqueue eingeschlossen). Und auch so lange bis alle Daten ins VBO übertragen wurden.

Aus diesem Grund gibt es das Mappen. Richtig eingesetzt ist das optimal für die asynchrone Arbeitsweise. Du gehst jetzt her und mappst ein VBO (ab 3.0 auch nur einen Teilbereich) als WRITEONLY. Also nur zum Schreiben. Der Treiber erstellt dann einen Speicherbereich im Ram und liefert dessen Pointer zurück. In diesen Speicherbereich schreibst du jetzt alle deine Daten. Wenn du fertig bist entfernst du das Mapping wieder. Damit signalisierst du dem Treiber die Daten mögen in das VBO übertragen werden. Da der gemappte Buffer aber vom Treiber erstellt wurden wird auch nur dieser den Speicher wieder freigeben. Entsprechend ist der Speicher so lange gültig wie der Treiber es für angebracht hält. Sollte das VBO gerade auf der GPU in Verwendung sein so wird der Befehl in die Befehlsqueue gepackt und später ausgeführt. Der Speicher ist dann ja immer noch gültig. Das glUnMap wird also kaum Zeit beanspruchen. Zeichenbefehle im Anschluss landen auch in der Befehlsqueue und zwar nach dem Übertragen. Eventuell bestehende Zeichenbefehle bleiben unangetastet in der Queue. Die richtige Ausführreihenfolge der Befehle und die Konsistenz der Daten wäre dadurch immer gegeben und die CPU müsste nicht warten bis die GPU das VBO nicht mehr benötigt.

Das Ganze kann man auch in der Spezifikation von GL_ARB_vertex_buffer_object nachlesen. Auch mit Beispiel. (wenn ich mich nicht vertue.) ABER. So weit die Theorie. Tests bei mir haben aber gezeigt, dass glMapBuffer teilweise ziemlich lange benötigt. Teilweise sogar länger als ich benötigen würden, wenn ich die Daten mit glBufferData oder glSubBufferData hochladen würde. Kann aber gut sein, dass es ab einer gewissen Datengröße schon wieder anders aussieht. Habs aber auch nur auf ATI/AMD getestet.

Wo das VBO abgelegt wird ist Ermessenssache des Treibers. Ich meine aber mal gelesen zu haben, dass dynamische VBOs (DYNAMIC bzw STREAM) eher im Ram abgelegt werden. Wärend VBOs die selten bis gar nicht verändert werden im GRAM abgelegt werden.

Noch ne Anmerkung zu glBufferData vs. glSubBufferData: glSubBufferData sollte da bevorzugt werden, weil glBufferData den Speicherplatz für das VBO reserviert und initialisiert. Also lieber ein Mal am Anfang glBufferData mit passender Größe aufrufen und dann nur noch Bröckchen mit glSubBufferData ins VBO kopieren. Ist vergleichbar wie glTexImage und glTexSubImage. glSubBufferData unterliegt auch den selben Synchronitätsbeschränkungen wie glBufferData.

PS: Das Idealste wäre aber, wenn man VBOs von solch großen Texten gar nicht erst immer und immer wieder neu erstellen müsste.

Mir fällt da nur eine recht umfangreiche Möglichkeit ein, um das ganze Problem effektive zu lösen.

Zuerst erstellt man ein VBO mit z.B. 256 Quads(512 Triangles), dann werden mindestens 2 Texturen, sowie ein Shader gebunden.
Das VBO enthält 255 Quads, die nebeneinander, auf einer Linie, angeordnet werden, man verwendet den gleichen Abstand und Blockgröße(blockfonts), sowie ein VBO mit Texturkoordinaten, welche von 0.0 bis 1.0/Anzahl der Zeichen(je Vertikal und Horizontal) und ein Buffer mit dem Lookup UV offset(Symbolnummer als 2 Floats konvertieren).
Dier erste Textur ist eine Lookupmap, welcher in Rot den TexturIndex, in Grün und Blau den UV Offset in der entsprechenden Textur kodieren.
Sobald eine Textur nicht mehr ausreicht, wird halt eine weitere gebunden, in dem die nächsten Zeichen liegen und in der Lookupmap der TexturIndex und Offset angepasst.
Der Shader ist sehr simpel, als erstes schaut er in die erste Textur(Lookupmap) an der Position, die durch das 3. vbo(UV offset) zur verfügung gestellt wurde.
Nun wird der UV offset, aus der Lookupmap, mit den Texturkoordinaten addiert und wir haben schon mal die fertigen Texturkoordinaten(für den Texturatlas).
Jetzt wird noch der entsprechende Textur Atlas, dank des TexturIndex, die errechneten Texturkoordinaten geladen und als Farbe dargestellt.
Das System ist auf Blockfonts beschränkt aber benötigt wenig Rechenleistung, da nur ein VBO call und 2-N Texturen gebunden werden, je nach Auflösung der Buchstaben.
Bei einer 32x32Pixel großen Schriftart benötigst du z.B. nur 2 Texturbindings(32*16=512, 16*16 Zeichen auf einer 512x512 Textur, also eine Lookupmap und ein Texturatlas).
Die Kosten verlagern sich natürlich ein bischen auf die CPU, da ja die Lookupmap aktuell gehalten werden muss und die Texturatlanten mit den Font gefüllt werden müssen.

Das ist allerdings sehr gering, ich habe für meine Bachelorarbeit z.B. den ganzen Frontbuffer runter geladen, Pixelweise analysiert, ein entsprechende Lookupmap konfiguriert, einzelne TexturBlöcke wieder Hochgeladen und alles mit >800FPS bei 512*512 Pixel. Siehe Link. Das ganze schimpft sich Virtual Texture, bzw. in etwas schwächerer Form findet man es als MegaTexture wieder und soll das sehr teure Texturbinding auf eine Konstante geringe Anzahl bringen und somit größere komplexere Szenen mit einen Aufruf zu zeichnen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hi,

hat denn dann das mit glMapBuffer etc irgendeinen Nachteil gegenüber glBufferData??
Weil prinzipiell klingt das erstmal so als sei es in jedemfall schneller (weil asynchron).. oder?

Werd das heute abend mal auch ausprobieren.

@TAK:
Das ist mir im grunde schonwieder viel zu kompliziert.. bzw geht es ja nur bedingt um mein Font-System - das ist nur der teil wo es grad stark auffällt von der geschwindigkeit.

Prinzipiell geht es ja um JEDES Quad das mal irgendwo einzeln gezeichnet wird (z.B. für die UI oder irgendwelche Interface-geschichten).


Aya~

Also, allgemein, bei der GUI habe ich mir überlegt (aber noch nicht implementiert) eine Art Speicherverwaltung für Grafikspeicher zu bauen. Ich habe also einen Grafikspeicherserver wo die GUI-Komponenten (bzw deren Style-Klasse) speicher alloziert in Form von Puffer-Objekten. Gleichzeitig wird in einem globalen VBO der Platz für dieses Objekt reserviert. Dort gibts dann ein Array, wo die nach belieben ihre Vertices inkl. Texturdaten & Co reinschreiben. Dieses Puffer-Objekt behalten die dauernd. Wenn sich etwas ändert, invalidieren sie es und vorm rendern werden alle invalidierten Objekte neu übertragen in den ihnen zustehenden Bereich im Puffer. Optimieren kann man hier, indem man bspw versucht, zusammenhängende Bereiche auch zusammenhängend zu füllen. Wobei ich, nachdem ich Lossys Ausführungen über glMapBuffer gelesen habe, in einigen Fällen vermutlich ein komplettes WriteOnly-Bind + Reinkopieren besser finde. In GL3 wäre das dann natürlich optimal, wenn man auch teile binden und füllen kann, ohne auf die synchroniserenden Methoden angewiesen zu sein.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Tja, man zeichnet den VBO mit dem Aufruf glDrawArrays und setzt damit offenbar ein ungeheures Ding in Gang. Wenn dann nur ein einzelnes Quad (oder nein, geht ja auch nicht mehr, also zwei Dreiecke) drin sind, ist das wahrscheinlich so, als würde man eine Maus in einen Jumbo Jet setzen und sie auf diese Weise transportieren. Man KANN es schon machen, aber empfehlenswert ist es vermutlich nicht.

Irgendwie kommt mir das krank vor, z.B. wenn ich an Dein Flipbook denke, denn so etwas Ähnliches steht mir ja auch noch bevor. Beim Flipbook müsste man mehrere Texturen (= allgemeine Textur-Puffer) in der Grafikkarte haben, z.B. so viele, wie für 10 Sekunden Film benötigt werden (rund 250) und daher einen VBO mit 500 Dreiecken. Aber ich habe keine Ahnung, wie man nach zwei Dreiecken jetzt von einem Texturpuffer auf den nächsten umschalten kann.

Übrigens: was die Schrift betrifft, bin ich auf ein Beispiel im Orange Book aufmerksam geworden. Ich wollte mich vor einiger Zeit schlau machen, wie man wohl in OpenGL3 Text ausgeben wird. Da gibt es wie gesagt im Orange Book ein Kapitel namens "Glyph Bombing", hab ich zwar noch nicht durchgeackert, aber vorgemerkt.



EDIT: Hey, ist mir nur grad so eingefallen: Wäre die Sache mit dem Umschalten von einem Texturpuffer auf den anderen nicht ein sinnvoller Anwendungsfall für eine 3D-Textur?

Ja, dass klingt gut. Anstatt n 2DTexturen einfach eine AxBxN 3D Textur.

Mal ne prinzipielle Frage. Angenommen man hat eine feststehende Anzahl Texturen. Und weiterhin angenommen die haben alle die selbe Größe. Ist es nicht vielleicht allgemein schneller anstatt diese Texturen einzeln zur GraKa zu schicken, diese einmal komplett als 3D Textur zu schicken, und das "umschalten" zwischen den Texturen mit der "w" Textur-Koordinate zu machen?

Das wäre wieder eine Sache für den DGL Benchmark, oder? So langsam sollte man den wirklich mal bauen....

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das ist doch gerade das schöne an Virtual Texture, es ist eine allgemeine Lösung, du musst dann halt den frontbuffer durchlaufen, statt die informationen übervbo zu verpacken.
Virtual Texture ist erst mit OpenGL2 sinnvoll und mit OpenGL3 wirklich zu empfehlen, vorallem, wenn man deferred shading verwendet.

Eine weitere Möglichkeit wäre den Text mehr statisch zu machen und für jeden Text eine displaylist und ein vbo zu erstellen.
Sprich du erstellst ein VBO für den kompletten Text, dabei sortierst du das mesh, so, dass die anzahl der bindings auf das absolute minimum reduziert wird, erstellst für genau diesen Text eine/mehrere FontTextur/en und verpackst das ganze in eine displaylist. Das VBO und die Texturen können nach N Zeit wieder aus dem Grafikspeicher entfernt werden und in den Arbeitsspeicher gehalten werden. Durch Scissor kannst du dann dir den entsprechenden bereich deines Text dann Anzeigen. Damit brauchst du wegen den zugeschnittenden Texturen zwar mehr Speicher(Arbeitsspeicher oder VRAM) aber hast die höhere Performance erreicht. Das ganze läuft dann auch auf opengl1.2 mit vbo arb funktion.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich habe diesen Thread nur überflogen, vielleicht hat das schon jemand gesagt...jedenfalls würde ich da so rangehen:

1. Du hast eine Textur die sämtliche Buchstaben enthält. Möglicherweise mehrere Texturen bei verschiedenen Schriftarten/-größen.
2. Du übergibst den zu rendernden Text (also quasi den String) als Uniform-Array (z.B. mit glUniform1iv). Bei langen Texten könnte man das auch über eine Textur oder besser ein Texturbufferobject machen.
3. Du renderst nur ein einziges Quad, welches nur aus 2D-Vertices besteht, dieses aber via Instancing so oft wie Buchstaben im Text sind. Dafür muss soweit ich weiß auch bei OpenGL 3 nicht unbedingt ein VBO verwendet werden. VBOs rendert man mit glDrawArrays und das kann auch einfache Arrays rendern.
4. Der Vertexshader holt sich mit gl_InstanceID als Arrayindex den aktuellen Buchstaben aus dem Uniform-Array bzw. der Textur. Mit der gl_VertexID weißt du welcher Vertex gerade verarbeitet wird und kannst die entsprechenden Positionen und Texturkoordinaten (etc.) schreiben.
5. Der Fragmentshader entscheidet anhand einer weiteren Uniform-Variable welcher Schrifttyp (=Textur) verwendet werden soll.

Ggf. brauchst du weitere Uniforms für Zeilenumbruch und solche Sachen.

_________________
Yeah!