Performancenachteile/vorteile durch mehrere VBuffer?
-
Hi!
Hat jemand von euch Erfahrungen gemacht, wie es sich auf die Performance aus-
wirkt mehrere VBuffer gleichzeitig zu haben und diese per Shader zu vereinen?Beispielsweise Texturdaten und Positionsangaben zu trennen? Wie führt man diese
Streams dann wieder zusammen? Reicht es die Vertex Deklaration entsprechend zu
setzen (Stream-Member)?Wie funktioniert das dann mit den Indizes? Kann man einen Index Stream für alle
Vertex Buffer nehmen??MfG,
EnERgYzEr
-
EnERgYzEr schrieb:
Hi!
Hat jemand von euch Erfahrungen gemacht, wie es sich auf die Performance aus-
wirkt mehrere VBuffer gleichzeitig zu haben und diese per Shader zu vereinen?als ich es mal vor längerrer zeit getestet hatte war es ca halb so schnell wie ein interleaved buffer. vorteile bringt es nur wenn du dafür ne unmenge von daten sparrst. z.b. ein terrain das immer die selben texturcoordinaten hat und man nur unheimlich viele positionen hat.
EnERgYzEr schrieb:
Wie führt man diese
Streams dann wieder zusammen? Reicht es die Vertex Deklaration entsprechend zu
setzen (Stream-Member)?ja, so einfach ist das.
EnERgYzEr schrieb:
Wie funktioniert das dann mit den Indizes? Kann man einen Index Stream für alle
Vertex Buffer nehmen??ja, so läuft das zur zeit. ab SM3.0 kann man einstellen das es nur ein streamelement weiter geht beim durchlauf eines anderen stream, sehr gut für 3d-particle (z.b. bäume in FarCry)
rapso->greets();
-
[quote="EnERgYzEr"]Hi!
Hat jemand von euch Erfahrungen gemacht, wie es sich auf die Performance aus-
wirkt mehrere VBuffer gleichzeitig zu haben und diese per Shader zu vereinen?[/quote]das dürfte drauf ankommen, was du in deiner pipeline sonst noch alles anstellst. wenn am ende sowieso noch ein komplexer fragment shader wartet, dann dürfte der unterschied minimal ausfallen.
wirklich machen würde ich das aber nur, wenn es wirklich sinn hat. das angesprochene terrain z.b., mit der art spar ich jede menge speicher (shameless plug: http://festini.device-zero.de/Programming/Downloads/jstart.zip -rad9700 oder gf fx bzw. höher nötig-)
alle x,z koordinaten sind z.b. schwer redundant, also werden nur die höhenwerte gespeichert und für einen "patch" die x,z koordinaten. der rest läuft dann über offsets. ist zwar mehr aufwand im vertex shader, aber dafür bekommt man in 17mb eine 2048x2048 landschaft unter (auf ner nvidia sogar 4096x4096)
falls du aber darauf schielst, für jeden stream getrennte index-buffer zu benutzen, dann hast du pech. alle vertex attribute benutzen den gleichen index.