Vom Geometry Shader Triangles in Buffer schreiben?
-
rapso schrieb:
wenn er nur die daten des eigentlichen triangles braucht was im pixel shader auf sich zugreift, sollte es gehen, obwohl da vielleicht atomics noetig sind.
Aber für jeweils ein einziges Dreieck bräuchte er doch kein buffer object, das könnte er schließlich einfach so durch die shader stages reichen.
-
Erst mal vielen Dank für die vielen Antworten. Ich habe mit dem Shader Storage Buffer Object sicherlich schon mal das richtige Stichwort gehört.
hustbaer schrieb:
@/rant/
Willst du dass die Daten aller Triangles in dem Puffer stehen bevor der Fragment-Shader für das erste Fragment des entsprechenden Batches läuft?
Also so dass der Fragment-Shader auf die gesamte Tri-List des aktuellen Batches zugreifen kann?Genau das ist die Absicht. Ich würde gerne im Fragment Shader auf die komplette Tri-List (falls möglich inklusive aller notwendigen Vertex-Daten) zugreifen.
-
/rant/ schrieb:
Genau das ist die Absicht. Ich würde gerne im Fragment Shader auf die komplette Tri-List (falls möglich inklusive aller notwendigen Vertex-Daten) zugreifen.
Das geht auf jeden Fall nur in zwei Passes, dafür kannst du einfach die Transform Feedback Stage verwenden. Ich bezweifle allerdings sehr, dass die Lösung die dir vorschwebt ein effizienter Ansatz sein wird. Was genau willst du denn machen?
-
Mehrere Stages sind kein Problem, Effizienz ist für mich zweitrangig. Ich möchte die Triangles beim Deferred Shading zur Verfügung haben und austesten, was man damit alles anstellen kann. Vielleicht sogar vom Deferred Shading wegkommen und etwas anderes probieren.
-
In dem Fall kannst du aber wohl einfach beim Generieren des G-Buffer den Primitive Index mit ausgeben und dann im Deferred Shading Pass Index und Vertex Buffer als Shader Storage Buffer binden und drauf zugreifen...
-
Dann müsste er allerdings im Fragment-Shader alle Berechnungen des Vertex-Shaders/Hull-Shaders etc. wiederholen. Oder nicht?
-
Naja, hängt wohl davon ab, welche Informationen er konkret braucht. Evtl. schon, in dem Fall ist es dann wohl besser, die Primitives rauszustreamen, was aber für die Performance nicht so der Bringer ist, daher besser drauf verzichten so lange es geht...
-
Die ganzen Transforms müssten schon auf die Geometrie angewandt worden sein, damit das etwas nützt. Geht eigentlich so weit, dass Sachen wie Culling wegfallen. Es soll wirklich die ganze Szene abgreifbar sein im Fragment Shader. Performancemässig wäre das vermutlich wirklich tödlich, aber wie gesagt: Ich wäre bereits mit wenigen Frames pro Sekunde zufrieden.
-
Dann go for it, einfach per Transform Feedback den Primitive Stream direkt vor dem Rasterizer abzweigen...
-
hgh schrieb:
rapso schrieb:
wenn er nur die daten des eigentlichen triangles braucht was im pixel shader auf sich zugreift, sollte es gehen, obwohl da vielleicht atomics noetig sind.
Aber für jeweils ein einziges Dreieck bräuchte er doch kein buffer object, das könnte er schließlich einfach so durch die shader stages reichen.
koennte, die frage ist ob er das auch wirklich will. er muss es dann ja pro vertex uebergeben, was 3x der daten sind und im interpolierbarem format. (e.g. 1 bit bool ginge nicht).
-
/rant/ schrieb:
Die ganzen Transforms müssten schon auf die Geometrie angewandt worden sein, damit das etwas nützt. Geht eigentlich so weit, dass Sachen wie Culling wegfallen. Es soll wirklich die ganze Szene abgreifbar sein im Fragment Shader. Performancemässig wäre das vermutlich wirklich tödlich, aber wie gesagt: Ich wäre bereits mit wenigen Frames pro Sekunde zufrieden.
dann waere es eventuell einfachher und sehr viel schneller die transformationen mit einem compute shader zu machen. da ist der output gut planbar, du hast keine vertex redundanz und wenn du die daten fuers rendern nutzt, kannst du die scene mit einem drawcall rendern und die primitive-id gratis bekommen und im gbuffer ablegen.
