Geometry Instancing?

[PhoenixFG]

Lt. Release Notes beherrscht der neue Cat. 4.8 ja nun diese Technologie.

Könnte jemand erklären, was dieses Verfahren genau bedeutet und wie es funktioniert?
Wie und unter welchen Umständen bringt das Verfahren etwas? Gibt es Nachteile?
Funktioniert das bei allen ATI-KArten oder nur bei der X800-Serie?
Wie sieht es bei Nvidia aus? Wird diese Technologie dort auch verwendet?

MfG

[saaya]

heisst so weit ich weiss dass mehrere berechnungen zusammengefasst werden (in eine gruppe?) und dann schneller berechnet werden koennen als ob man jedes teil einzeln berechnen wuerde.

koennen alle ati karten ab 9500 so weit ich weiss, bei nvidia bin ich mir nicht sicher, aber ich glaub erst ab der fx serie.

nachteile... hmmm ich denk mal wenn zu viel zusammengefasst wird wird die karte nur langsamer, aber ich glaub die entscheidung welche sachen zusammengefasst werden trifft der compiler im treiber (?) und daher sollte sich die karte also nie uebernehmen.

bin mir echt nicht sicher, hab auch nur geantwortet weil noch keiner ueberhaupt was gesagt hat :D bitte korrigiert mich!

[Ronny145]

Lt. Release Notes beherrscht der neue Cat. 4.8 ja nun diese Technologie.

Könnte jemand erklären, was dieses Verfahren genau bedeutet und wie es funktioniert?
Wie und unter welchen Umständen bringt das Verfahren etwas? Gibt es Nachteile?
Funktioniert das bei allen ATI-KArten oder nur bei der X800-Serie?
Wie sieht es bei Nvidia aus? Wird diese Technologie dort auch verwendet?

MfG


Bei computerbase stand gut beschrieben was Geometry Instancing bewirkt:
http://www.computerbase.de/news/hardware/grafikkarten/2004/juli/far_cry_version_12_sm_20b/

[PhoenixFG]

Danke für den Link. Nun ist schon mal erklärt, welche Karten es beherrschen und was man damit anfangen kann.
Aber wie funktioniert es eigentlich?

MfG

[Xmas]

Die Daten, die an den Vertex Shader gehen sollen, kommen in so genannte Streams. Nun kann man alle Eckpunkt-spezifischen Daten in einen Stream packen, und alle Objekt-spezifischen in einen anderen. Dann sagt man der GPU, dass sie für jeden neuen Vertex im ersten Stream um eine Position vorrücken soll, vom zweiten Stream aber erst n-mal dieselben Daten verwenden soll bevor es zur nächsten Position weitergeht.

Also wenn man ein Model aus 30 Eckpunkten hat, das man 5 Mal an verschiedenen Positionen rendern will, packt man die 30 Eckpunktdatensätze in einen Stream, und 5 Transformationsmatrizen in einen anderen.
Während der erste Stream dann Schritt für Schritt durchlaufen wird, bleibt der zweite 30 Mal an derselben Position stehen, bis auch er eins weiterrückt und der erste Stream erneut von Anfang an durchlaufen wird.

[PhoenixFG]

OK, soweit hab ich es wahrscheinlich gelöffelt. Ich schnapp mir also nacheinander alle 30 Eckpunkte und führe für sie meinetwegen eine Transformation A durch. Ist das erledingt, steht man Objekt an der Stelle A fest und ich schnapp mir wieder alle 30 Eckpunkte und führe Transformation B durch usw.
Richtig?
Klingt ja soweit ganz logisch und sinnvoll. Aber wo ist jetzt der Aha-Effekt.
Anders gefragt, wo liegt hier der große Fortschritt. Wie werden die Objekte denn behandelt, wenn man nicht nach dieser Vorschrift vorgeht?

Wenn ich das Beispiel richtig verstanden habe, muss ich ja trotz allem 150 Tranformationen durchführen, egal wie ich es nun drehe und wende.

Oder geht die ganze Sache schneller, weil ich die Transformationsvorschrift nur 5 mal laden muss, um sie dann jeweils auf 30 Datensätze anzuwenden, anstatt mir einen Eckpunkt zu schnappen und dann die 5 Transformationen jedesmal laden zu müssen, wenn man einen neuen Eckpunkt bearbeitet?

Ich hoffe, ich hab nix durcheinander gebracht.

MfG

[Demirug]

Für den Chip macht es nicht wirklich einen grossen unterschied ob er jetzt 150 Verticen oder 5*30 Verticen rendert. Für die CPU macht es allerdings schon einen unterschied ob man jetzt einmal 150 Verticen oder 5 mal 30 rendern lässt. Für die CPU macht die Anzahl der Verticen nämlich keinen Unterschied. Man spart also durch OI in diesem Beispiel 80% CPU Leistung. Da man für das OI aber uch noch etwas overhead hat ist es natürlich weniger.

[marco42]

Für den Chip macht es nicht wirklich einen grossen unterschied ob er jetzt 150 Verticen oder 5*30 Verticen rendert. Für die CPU macht es allerdings schon einen unterschied ob man jetzt einmal 150 Verticen oder 5 mal 30 rendern lässt. Für die CPU macht die Anzahl der Verticen nämlich keinen Unterschied. Man spart also durch OI in diesem Beispiel 80% CPU Leistung. Da man für das OI aber uch noch etwas overhead hat ist es natürlich weniger.

Wenn die aber schon im Speicher der GPU liegen, wie dass bei VBOs(wie die unter D3D heissen weiss nicht nicht) der Fall sein kann, was ist da eigentlich noch der grosse Unterschied. Soviel kann ein function call nun auch wieder kosten?

[Demirug]

Wenn die aber schon im Speicher der GPU liegen, wie dass bei VBOs(wie die unter D3D heissen weiss nicht nicht) der Fall sein kann, was ist da eigentlich noch der grosse Unterschied. Soviel kann ein function call nun auch wieder kosten?

Doch Function Calls sind teuer. Deswegen ändert MS ja für Longhorn die Schnittstelle beim DX-DDK.

nVidia meinte ja auch schon das sich Instancing eigentlich nur für DX lohnt weil bei OpenGL bei ihnen der Overhead nicht gross genug wäre als das es sich lohnt.

[marco42]

Doch Function Calls sind teuer. Deswegen ändert MS ja für Longhorn die Schnittstelle beim DX-DDK.

nVidia meinte ja auch schon das sich Instancing eigentlich nur für DX lohnt weil bei OpenGL bei ihnen der Overhead nicht gross genug wäre als das es sich lohnt.

Also deswegen gibt es keine Extension? Es ist also eher ein DX Workaround?

[KiBa]

Doch Function Calls sind teuer. Deswegen ändert MS ja für Longhorn die Schnittstelle beim DX-DDK.

nVidia meinte ja auch schon das sich Instancing eigentlich nur für DX lohnt weil bei OpenGL bei ihnen der Overhead nicht gross genug wäre als das es sich lohnt.
ich bin etwas verwirrt... ;) welcher overhead soll das bei d3d sein? letztens hattest du mir noch klar gemacht, dass die aufrufe in ogl (dll) und d3d (über com) ähnlich schnell gehen, obwohl ich eher dachte, die direkten aufrufe von ogl wären einiges schneller... oder hab ich da was falsch verstanden?

[Demirug]

ich bin etwas verwirrt... ;) welcher overhead soll das bei d3d sein? letztens hattest du mir noch klar gemacht, dass die aufrufe in ogl (dll) und d3d (über com) ähnlich schnell gehen, obwohl ich eher dachte, die direkten aufrufe von ogl wären einiges schneller... oder hab ich da was falsch verstanden?

Da ging es um Longhorn. Bei XP ist der Overhead bei D3D-Calls um einiges grösser als bei OpenGL. Die Gründe dafür ergeben sich aus der Art wie D3D Treiber programmiert werden müssen. Das ganze ist für eine kurze Antwort jetzt allerdings etwas zu kompliziert. Im DDK findet man alle Details dazu.

[Ailuros]

Die Daten, die an den Vertex Shader gehen sollen, kommen in so genannte Streams. Nun kann man alle Eckpunkt-spezifischen Daten in einen Stream packen, und alle Objekt-spezifischen in einen anderen. Dann sagt man der GPU, dass sie für jeden neuen Vertex im ersten Stream um eine Position vorrücken soll, vom zweiten Stream aber erst n-mal dieselben Daten verwenden soll bevor es zur nächsten Position weitergeht.

Also wenn man ein Model aus 30 Eckpunkten hat, das man 5 Mal an verschiedenen Positionen rendern will, packt man die 30 Eckpunktdatensätze in einen Stream, und 5 Transformationsmatrizen in einen anderen.
Während der erste Stream dann Schritt für Schritt durchlaufen wird, bleibt der zweite 30 Mal an derselben Position stehen, bis auch er eins weiterrückt und der erste Stream erneut von Anfang an durchlaufen wird.

Womoeglich dumme Frage: aendert sich was besonderes, wenn man theoretisch versuchen wuerde die Groesse der Modelle beim Instancing zu variieren?

[Demirug]

Womoeglich dumme Frage: aendert sich was besonderes, wenn man theoretisch versuchen wuerde die Groesse der Modelle beim Instancing zu variieren?

Im Prinzip nicht. Nur wird GI mit zunehmeder Modelgrösse immer uninteresanter.

[IVN]

That means vegetation and small RTS unites are perfect for GI.

[Ailuros]

Im Prinzip nicht. Nur wird GI mit zunehmeder Modelgrösse immer uninteresanter.

Danke. Ich dachte nun eben an die kommende Serious Sam2 engine. Schon in der ersten Spielen gab es die oeden "Flammenmonster". Trifft man eins, dann erscheinen mehrere kleine davon. Etwa mit dem Gedanken hab ich gespielt. Bei einer handvoll von Modellen ist es ja eigentlich egal, aber ich hab den Eindruck dass deren neue Engine eine Unzahl von Monstern an den Spieler werfen will.

[Exxtreme]

That means vegetation and small RTS unites are perfect for GI.
Ja. Auch in Strategiespielen, in denen Massen von gleichen Einheiten bewegt werden, könnten davon profitieren. =)

[Quasar]

Ja. Auch in Strategiespielen, in denen Massen von gleichen Einheiten bewegt werden, könnten davon profitieren. =)

"small RTS unites" Das ist dasselbe. ;)
RTS = Real Time Strategy

[IVN]

@Quasar

It's nice to see,that you know what i mean. :up:

[Spawn182]

@Ailuros
Eine Änderung der Größe ist auch nur eine Transformation, wie auch die Angabe von Ort im Raum etc. also kannst du das auch unter Einsatz von GI.
Ich denke aber hier geht es auch nicht um 30 Punkte, die 5 mal transformiert werden müssen :) Sondern eher um 30 Punkte sammt Texturinformationen möglicher Shaderinformation, die dann im Fall von Vegetation 500 oder gar 5000 oder mehr mal tranformiert werden. Da würde dann schon ein etwas größerer Overhead entstehen. Es können aber auch wesentlich komlexere Obejkte sein, das Limit ist halt der Speicher der Grafikkarte, denn ist erster Linie geht es ja darum, dass die Geometriedaten nicht jedes mal über den Grafikbus geschoben werden müssen.
Ähnliche Prinzipien benutzen ja aktuelle Grafikengines auch schon n ihrer Software. Zum Beispiel die Unreal Engine mit StaicMeshes, wo es nahezu egal ist, ob ein StaticMesh einmal oder 100mal in einer Szene auftaucht.