spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich persönlich verwende im Moment auch in etwa so ein System, habe aber ernste Zweifel an der Sinnhaftigkeit des Ganzen. Ich hab's nicht ausprobiert, aber ich würde vermuten, dass die simple Variante mit einfach per CPU die fertigen Vertices in einen Buffer packen und rendern (ganz ohne Geometry Shader und sonstigen Glamour) immer noch am schnellsten ist. Auf jeden Fall würd ich keinen Constant Buffer verwenden, sondern einen ganz normalen Buffer oder zumindest einen Texture Buffer. Constant Buffer sind auf Broadcastzugriff ausgelegt, kreuz und quer drin rumlesen ist wohl mit Abstand das Schlechteste, was man mit einem Constant Buffer machen kann (Constant Memory ist sehr schnell, so lange parallel an der selben Adresse gelesen wird – ideal für Shader Uniforms – die Performance nimmt dafür aber linear mit der Anzahl der parallelen Zugriffe auf unterschiedliche Adressen ab, da diese serialisiert werden müssen). Der Input Assembler dagegen, wäre z.B. genau für sowas gebaut...

Ich hab eine Textur, die als Glyphen Cache dient und einen Buffer, der Glyphen Indizes auf Texcoords, Größen etc. mapped. Als Input verwend ich einen dynamischen Vertex Buffer, der einfach nur Glyphen Index und Ziel Position enthält. Die rendere ich als Punktliste mit einem Geometry Shader, der dann basierend auf Glyphen Index und Position mit den Infos aus der Glyphen Map ein Quad generiert. Ich hab allerdings nie wirklich die Performance analysiert; wenn dir fad ist und du das mal Benchmarken willst: Deine Ergebnisse würden mich auch interessieren...

Zitat von »LukasBanana«

Ich hab noch einen Constant-Buffer der in etwa so aussieht (hier vereinfacht):

	C-/C++-Quelltext
1 2 3 4	cbuffer BufferText : register(b1) { uint Text[1024]; };

Da steht der Text drin. Ein Character braucht normaler Weise nur ein "unsigned char", also werden hier 4 Character pro Eintrag im Array gespeichert.
Damit kann der Text maximal 4192 Zeichen lang sein (reicht für eine Zeile Text).

Aber woher weißt du jetzt, an welcher Position auf dem Bildschirm du den Buchstaben zeichnen musst? Schließlich kann jeder Buchstabe unterschiedlich breit sein oder hinter beliebig vielen Zeilenumbrüchen liegen … ich hatte jetzt so verstanden, dass du deshalb einen zweiten Constant Buffer anlegst, wo die fertig berechneten Positionen der Buchstaben-Quads auf Bildschirm und Textur drin sind. Aber wenn das so ist, ist einer der beiden Puffer überflüssig (sogar alle drei, würde ich sagen), denn kannst du die Textzeichen ja gleich mitspeichern, zumal der Input Assembler des Vertex Shaders 8-Bit-Integer unterstützt (und dir damit das Entpacken abnimmt).

Ich denke hier wie dot. Es mag technisch prima gehen, aber solange nicht gerade hunderttausende Zeichen gerendert werden sollen, dürfte das Bind für den Shader am Ende mehr Zeit verbraten als einmal auf der CPU die Vertices für den Text festzulegen und diese dann zu rendern. Text-Änderungen entstehen auch selten jeden Frame, die Daten sind also oft für viele Frames konstant und bedürfen gar keines Updates.
Die Sinnhaftigkeit des ganzen Unterfangens ist also höchst fragwürdig.