• 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!

_________________
Yeah!

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.

Noch ein paar Zitate aus dem NVIDIA GeForce 8 and 9 Series GPU Programming Guide. Insbesondere der Abschnitt 4.6 ist sehr informativ, aber zu lang um ihn hier komplett zu zitieren.

_________________
Yeah!

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.

_________________
Yeah!

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

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

Also erstmal ne Runde Feedback bitte:
http://wiki.delphigl.com/index.php/Benutzer:Coolcat

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?)

_________________
Yeah!

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?

_________________
Yeah!

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

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

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.

http://www.gpgpu.org/w/index.php/Code_E ... pth_Buffer

_________________
Yeah!

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.

_________________
Yeah!

Hab ich gemacht. Shader ist jetzt frei für deine Version. Der alte Artikel steht unter Shader_(historisch).

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

Ok, hab das ganze jetzt nach "Shader" verschoben:
http://wiki.delphigl.com/index.php/Shader

_________________
Yeah!