Der Geometry Shader ist der zuerst aufgerufende Shader, welcher dafür sorgt, dass die herreingekommenden Meshes verarbeitet werden. In die Renderpipeline kommen Meshdaten hinein, in Form von glBegin(...) ... glEnd(...) bzw. über VBO und diese werden nun auf richtigkeit geprüft. Dann werden diese im Geometry Shader zur veränderung frei gegeben. Man kann also aus einen Dreieck und den Normal z.B. das Dreieck in viele kleine zerlegen und dann geht es in der Renderpipeline weiter.(Ich habe noch keine Geometry Shader verwendet oder mich dazu groß belesen und daher weiß ich nicht ob der Schritt mit dem zerlegen in Triangle davor oder danach passiert.)
Zuerst wird der Vertexshader ausgeführt, dann der Geometryshader (wenn aktiv) und am Schluss der Pixelshader.
Verwendet man einen Geometryshader, muss man auch einen Vertexshader definieren.
Der Geometryshader kann vom Prinzip die gleichen Dinge tun wie der Vertexshader, hat aber diverse Vorteile:
verarbeitet man z.B. Dreiecke, kann man ein Dreieck als ganzes Verarbeiten. Man bekommt also für jede varying-Variable ein Array der Größe 3 als Input.
es gibt neben den bekannten GL_POINTS, GL_LINES und GL_TRIANGLES neue Input-Geometrietypen, z.B.: GL_TRIANGLES_ADJACENCY_EXT und GL_TRIANGLE_STRIP_ADJACENCY_EXT. Diese erlauben es nicht nur auf das aktuelle Dreieck zuzugreifen, sondern auch auf die benachbarten Dreiecke. Bei GL_TRIANGLES_ADJACENCY_EXT bekommt man dann ein Array der Größe 6 für jede varying-Variable. Diese Adjazenz-Informationen müssen natürlich auch bereits so im Vertexbuffer gegeben sein, haben aber den Vorteil das man so beispielsweise Shadowvolumes im Shader erzeugen kann.
der Geometryshader stellt zwei neue Funktionen bereit mit denen man neue Primitive zusammenbauen kann: EmitVertex() und EndPrimitive(). Vom Prinzip schreibt man wie gewohnt alle varying-Variablen für den aktuellen Vertex, ruft dann aber EmitVertex() auf und kann den nächsten Vertex schreiben. Es gibt nur drei mögliche Outputtypen: GL_POINTS, GL_LINE_STRIP und GL_TRIANGLE_STRIP
Alle Primitive die den Geometryshader verlassen sollen muss man selbst erzeugen. Man kann also auch einfach keine Primitive erzeugen und so eine Art discard für den Vertexshader erhalten.
Nun kommt der große Nachteil: Man muss die maximal mögliche Anzahl der im Geometryshader erzeugten Vertices vorher festlegen. Für diese Vertices muss Speicher reserviert werden, der dann nicht von anderen parallel laufenden Shaderunits benutzt werden kann. Will man also viele Vertices oder sehr große Vertices erzeugen hat man möglicherweise das Problem, dass nicht alle Shaderunits arbeiten können und das ganze wird ziemlich langsam!
Aus diesem Grund eignet sich der Geometryshader im Augenblick eben nur für kleine Modifikationen und nicht für irgendwelche LOD-Detailstufen, etc.
richtig interessant wird der Geometryshader in Kombination mit Transform-Feedback. Diese Extension erlaubt es die verarbeiteten Vertices komplett oder auch nur Teile davon direkt wieder in einen Texturbuffer zu schreiben. Texturbufferobjects haben gegenüber normalen Texturen den Vorteil, dass man sie auch als Vertexbuffer nutzen kann!
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Coolcat hat geschrieben:
Will man also viele Vertices oder sehr große Vertices erzeugen hat man möglicherweise das Problem, dass nicht alle Shaderunits arbeiten können und das ganze wird ziemlich langsam!
Nur der Vollständigkeit halber: Was sind große Vertices? Die sind doch immer alle gleich groß, oder beziehst du das auf Datentypen? Wobei selbst die in das interne Format der GraKa umgerechnet werden. War die Formulierung einfach flapsig, oder steckt da doch noch mehr dahinter?
PS: Deine Erklärung hier klingt wieder sehr schön ausgewogen, informativ und deshalb wikiwürdig. Wenn der obige Punkt geklär ist, können wir deine Erklärung gleich ins Wiki transferieren. Der Shader-Artikel ist für das Thema etwas zu unvollständig.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Bevor der Pixelshader anlaufen kann müssen erstmal sämtliche Vertices im Speicher gesammelt werden. Überlegen wir wie viel Platz braucht so ein Vertex? Naja, er braucht genau soviel Platz wie wir aktive varying floats haben. Also alle eingebauten varyings, sowie die selbst definierten. Beim compilieren wird ermittelt welche varyings tatsächlich benutzt werden, diese nennt man dann "aktiv".
Meine Nvidia 9800GT hat z.B. GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_EXT = 1024. Ich kann im Geometryshader also insgesamt maximal 1024 Komponenten (float oder unsigned) schreiben. Wenn ich da jetzt die maximale Vertexgröße von 60 floats voll ausnutze, bin ich schnell mit dem Speicher fertig. Man muss ja auch überlegen, die Karte hat 112 Shaderunits die parallel laufen. Und man will schließlich nicht nur Vertices im Cache haben....sondern z.B. die Input-Geometrie oder Texturen müssen ja auch irgendwo hin. Ohne zu wissen wie groß genau der Cache ist kann man dazu nicht mehr sagen.
3.4.14. Too many generated primitives in Geometry Shader Geometry Shaders have the ability to output new primitives generated procedurally in the shader. Be careful to use this feature judiciously as on all current generation hardware the performance of the geometry shader is directly proportional to the number of output attributes. In general outputting the same number as input or a few more is acceptable, but 10x the number of input primitives will start to slow the shader down to the point where it will become the bottleneck. See section 4.6 for more information.
Zitat:
For example, on a GeForce 8800 GTX a GS that outputs at most 1 to 20 scalars in total would run at peak performance, whereas a GS would run at 50% of peak performance if the total maximum output was declared to be between 27 and 40 scalars.
Zitat:
Thus, it is important to understand that the main use of the geometry shader is NOT for doing heavy output algorithms such as tessellation.
Zitat:
4.6.1. GS Performance Bottleneck (“maxvertexcount”) Keep maxvertexcount as low as possible! In addition, one thing to be aware of when outputting many attributes from a Geometry Shader program is that if you are outputting a dynamically variable number of attributes for each primitive then ALL primitives executing the geometry shader will run at the worst case of the geometry shader output. That is, when declaring the geometry shader you must define the maximum number of vertices that the shader will output. It is THIS declaration that determines the speed with which the GS runs.
Der Shader-Artikel ist für das Thema etwas zu unvollständig.
Macht es wirklich Sinn das in den Shader-Artikel zu packen? Geometryshader sind nun wirklich fortgeschritten und sollten daher meiner Meinung nach in einen eigenen Artikel. Gleiches gilt für Transform-Feedback, da kann man auch einen ganz eigenen Artikel drüber schreiben.
Demnächst irgendwann könnte ich auch den Artikel GLSL_Partikel ausbauen, der ist nämlich ziemlich veraltet. Wir arbeiten hier an einem Highend-System für die Nvidia Demo Competition hier an der RWTH Aachen. Allerdings muss ich erst mit meinem Teamkollegen absprechen, ob wir die Techniken in unserem GPU-Partikelsystem veröffentlichen bevor die Competition zu Ende ist....wir wollen ja schließlich gewinnen
Geplant sind z.B. Dinge wie eine Interaktion der Partikel untereinander, sowie Selfshadowing. Der Knüller wird wahrscheinlich die Z-Sortierung der Partikel auf der GPU. State-of-the-Art scheint da Odd-Even-Mergesort zu sein. Wir verwenden einen stark verbesserten Algorithmus, der hoffentlich etwa 4mal so schnell ist. Aktuell ist aber nur das Basissystem implementiert. Die Engine schafft bisher mühelos 1 Mio Partikel, wenn diese nicht zu groß (oder nicht im Bild) sind. Insbesondere die Z-Sortierung wird man aber über mehrere Frames verteilen müssen, weil die einfach zu aufwendig ist.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Klingt interessant. Schön einen weiteren Profi/Forscher hier bei DGL zu haben.
Wegen dem Artikel:
Im Shaderartikel fände ich es praktisch, wenn dort die verschiedenen Shadertypen, ihre Abhängigkeiten und ihre Zwecke kurz beschrieben werden würden. Das man zu den einzelnen Shadertypen eigene Artikel schreiben könnte (und sollte) ist allerdings richtig.
Wenn du in den Shaderartikel mal 10min investieren könntest fände ich das klasse.
Und wenn ihr eure Ergebnisse (nachdem ihr gewonnen habt ) hier auch veröffentlichen könntet, wäre das super.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Wenn du in den Shaderartikel mal 10min investieren könntest fände ich das klasse.
Okay, ich glaub das waren etwas mehr als 10 Minuten, eher 4-5 Stunden....aber ich schreibe gerne und irgendwie muss man sich ja auch vor dem lernen für die nächste Prüfung drücken
Ich habe versucht Shader zu erklären ohne zu sehr ins Detail zu gehen und irgendwelche uralten Extensions zu erwähnen. Es macht einfach keinen Sinn, dass jemand der jetzt mit Shader anfängt sich noch in die uralten Assembler-Programme mit Shader Model 1.0 einarbeitet. Das ganze soll einen Überblick verschaffen wozu Shader gut sind und was man damit alles machen kann. Vielleicht sollte man noch einige Details aus dem alten Artikel übernehmen, aber nicht all zu viel.
Darauf aufbauend sollte es nun einzelne Artikel zu den Shader geben, wobei man Vertex- und Fragmentshader durchaus in einen Artikel packen kann. Vom Prinzip reicht da auch schon das GLSL-Tutorial.
Vielleicht sollte man das GLSL-Tutorial aktualisieren, Shader sind ja mittlerweile keine Extension mehr sondern Bestandteil von OpenGL. Ansonsten ist das aber für den Einstieg noch immer Top. Ich habe mit diesem Tutorial übrigens selbst Shader gelernt Den ganzen Shader 4.0 Kram sollte man da noch nicht einbauen, da wohl noch nicht jeder so eine Grafikkarte hat. Ich selbst hab ja auch erst seit knapp zwei Monaten entsprechende Hardware.
Wenn Interesse besteht kann ich in den nächsten Wochen/Monaten für die folgenden Extensions eine kurze Einführung schreiben:
- GL_EXT_gpu_shader4
- GL_EXT_geometry_shader4
- GL_NV_transform_feedback
(Ist das hier eigentlich der richtige Ort für diese Diskussion?)
Achso:
Bei dem Absatz über die verschiedenen Shader-Model-Versionen. Ich bin mir da nicht ganz sicher ob das alles so stimmt. Also z.B. das es keine Texturzugriffe im Vertexshader bei SM 2.0 gab.....vielleicht kennt sich da jemand besser aus oder kann seine Grafikkarte fragen
Sollte man da vielleicht auch gar nicht das ShaderModel, sondern die GLSL-Version angeben?
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Gefällt mir sehr gut. Ich muss sagen die 4-5h hast du, aus meiner Sicht, gut angelegt.
Und zu deinen Fragen: Ich denke Sascha (der ja das GLSL Tutorial geschrieben hat) kann dazu vielleicht auch was sagen. Außerdem gibts hier im Forum noch 2-3 andere Shader Spezies. Wenn ihr alle nochmal eure Nase in Coolcats Version steckt, haben wir einen wirklich tollen Shader-Artikel.
Wenn wir da noch 1-2 Bilder reinbekommen, nominier ich den glatt als exzellenten Artikel.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich habs mal kurz überflogen. Ich finde, das ist durchaus eine verbesserung, vorallem mit den vielen Beispielen. Super gemacht .
Nur eine Sache habe ich auszusetzen. Der Tiefentest ist, glaube ich, nach dem Fragmentshader. Es gibt da die eine oder andere Technik, die damit arbeitet, die Z-Werte des Fragmentes zu verändern (die einzige Koordinate, die man aus dem Fragmentshader heraus ändern kann) um Billboards ansprechender zu machen und ihnen Tiefe zu geben (z.B. Explosionen). Daher, der Tiefentest müsste danach einsetzen.
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
Nur eine Sache habe ich auszusetzen. Der Tiefentest ist, glaube ich, nach dem Fragmentshader. Es gibt da die eine oder andere Technik, die damit arbeitet, die Z-Werte des Fragmentes zu verändern (die einzige Koordinate, die man aus dem Fragmentshader heraus ändern kann) um Billboards ansprechender zu machen und ihnen Tiefe zu geben (z.B. Explosionen). Daher, der Tiefentest müsste danach einsetzen.
Im Bild ist der Tiefentest doch nach dem Fragmentshader? Vor dem Fragmentshader ist nur der Early-Z-Test. So wie ich das verstanden habe wird dieser Test angewendet, wenn man im Shader die Variable gl_FragDepth unverändert lässt. Würde jedenfalls Sinn machen.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Oh, sorry, das habe ich übersehen.
Also, jetzt ein uneingeschränktes "Super" von mir
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
Habe jetzt noch diverse Bildchen eingefügt. Außerdem den Abschnitt "Wie geht es nun weiter?" angefügt wo ich ein paar Links zum weiterlesen gesammelt habe.
Ich würde nun sagen wir belassen den alten Shader-Artikel so wie er ist, benennen ihn nur in "Shader_(Alt)" oder sowas um. Falls nämlich aus irgendeinem Grunde jemand nochmal seine alte Shader 1.0 Karte programmieren will muss der Artikel ja nicht verloren gehen? In meinem Shader-Artikel gibt es dann unter "Wie geht es nun weiter?" einen Link auf den alten Artikel.
Mitglieder in diesem Forum: 0 Mitglieder und 15 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.