Minimieren von Kommunikation zu GraKa?

durito

Hi,

Erstmal: ich bin shader-noob, also bitte kein Auslachen bei allfaelligen dummen Fragen

Ich moechte den Datenaustausch zur Grafikkarte weit moeglichst entlasten. Gerendert werden deformierbare Objekte, d.h. ich muss die gesammte Geometrie jeweils neu laden. Dazu einige Fragen:

Es waere moeglich, die Normalen jeweils mit Shader auf der Grafikkarte zu berechnen, oder? Und somit nur die Geometrie im immediate Mode zu uebertragen?

Gibts ne Moeglichkeit, gewisse Geometrie-Daten im vram zu behalten und nur jeweils die Daten die aenderten zu uebertragen?

glCopyTexture2D() scheint auf meinem System offensichtlich nicht von framebuffer nach vram zu kopieren, sondern belastet den Bus ziemlich deftig.. Ehm.. Wie sonst koennte ich render to texture, von framebuffer nach vram, machen?

rapso

durito schrieb:

Hi,
Es waere moeglich, die Normalen jeweils mit Shader auf der Grafikkarte zu berechnen, oder? Und somit nur die Geometrie im immediate Mode zu uebertragen?

normalen gehören zur geometrie, nein es wäre nicht möglich die normalen im VShader zu berechnen, dafür müßte der vertexshader die topologieinformationen der umliegenden triangles haben und zugriff auf die nachbarvertices... das lässt sich nur mit ziemlich viel aufwand realisieren.

durito schrieb:

Gibts ne Moeglichkeit, gewisse Geometrie-Daten im vram zu behalten und nur jeweils die Daten die aenderten zu uebertragen?

ja, über mehrere streams, für statische daten einen und für dynamische einen.

durito schrieb:

glCopyTexture2D() scheint auf meinem System offensichtlich nicht von framebuffer nach vram zu kopieren, sondern belastet den Bus ziemlich deftig.. Ehm.. Wie sonst koennte ich render to texture, von framebuffer nach vram, machen?

indem du render to texture z.b. mittels pbuffer durchführst anstatt "render to framebuffer and slowly copy and convert to texture" zu verwenden.

rapso->greets();

durito

rapso schrieb:

durito schrieb:

Hi,
Es waere moeglich, die Normalen jeweils mit Shader auf der Grafikkarte zu berechnen, oder? Und somit nur die Geometrie im immediate Mode zu uebertragen?

normalen gehören zur geometrie, nein es wäre nicht möglich die normalen im VShader zu berechnen, dafür müßte der vertexshader die topologieinformationen der umliegenden triangles haben und zugriff auf die nachbarvertices... das lässt sich nur mit ziemlich viel aufwand realisieren.

durito schrieb:

Gibts ne Moeglichkeit, gewisse Geometrie-Daten im vram zu behalten und nur jeweils die Daten die aenderten zu uebertragen?

ja, über mehrere streams, für statische daten einen und für dynamische einen.

durito schrieb:

glCopyTexture2D() scheint auf meinem System offensichtlich nicht von framebuffer nach vram zu kopieren, sondern belastet den Bus ziemlich deftig.. Ehm.. Wie sonst koennte ich render to texture, von framebuffer nach vram, machen?

indem du render to texture z.b. mittels pbuffer durchführst anstatt "render to framebuffer and slowly copy and convert to texture" zu verwenden.

rapso->greets();

hi rapso,

Danke fuer die Antworten!

ok
Ja das hab ich bereits so, es werden nur die dynamischen Daten uebertragen. Allerdings werden nicht alle dynamischen Daten jedes Frame veraendert; ich moechte nicht einen Stream welcher alle dynamischen Daten updated, sondern nur ein paar "ausgewaehlte" (also veraenderte). Wie koennte das gehen?
ok Haett ich wohl auch draufkommen muessen.

0x00000001

Inwiefern änderst Du die Geometrie denn? Hast Du schonmal darüber nachgedacht, ob Du diese Veränderungen vielleicht auf der GPU in einem Vertexshader durchführen könntest?
Damit müsste dann nichts mehr über den Bus gehen.

durito

0x00000001 schrieb:

Inwiefern änderst Du die Geometrie denn? Hast Du schonmal darüber nachgedacht, ob Du diese Veränderungen vielleicht auf der GPU in einem Vertexshader durchführen könntest?
Damit müsste dann nichts mehr über den Bus gehen.

Ne das geht leider auch nicht. Die Berechnungen fuer die Veraenderungen sind ziemlich fett und werden auf nem grossen SMP ausgefuehrt.

TGGC

Lieber mehrere kleine Buffer verwenden?

Bye, TGGC (Wähle deine Helden)

ABC++ 0

Ich muss das Problem mal aufgreifen.
ich hätte da ein ähnliches:
Ich habe eine Simulation in der ein Köper (bestehend aus vielen Triangles) verändert wird. Dabei müssen aber nur Teile des Körpers pro Frame aktualisiert werden.
Zur Zeit werden die kompletten Triangles für jedes Frame über den Bus geschickt (per GLdraw Arrays).

Welche Methoden kann man hier (konkret für Opengl) anwenden um den Datenstrom zu reduzieren. Dabei sollen keine Funktionen verwendet werden wie z.B. die VBO-Sachen, die den Gragabuffer direkt ansprechen (soll auf alten Gragas laufen).

Gruß ABC++

durito

Hm, was das "render to PBuffer" betrifft: Hab ich vergessen, aber das ist unter Linux noch nicht so ausgereift, z.B. geht das mit aktuellen Treibern noch nicht mit Antialiasing. Geht glaub ich erst mit GLX 1.4 (aber ohne Garantie..)

@ABC: Hört sich nach einem ähnlichen Problem an. Evt. kann der Körper ja sinnvoll nach TGGC's Vorschlag in verschiedene kleine Buffer aufgeteilt werden (Sowas kann ich mir in meinem Fall aber nicht vorstellen. Zudem würdest Du da "VBO-Sachen" brauchen"). Oder jenachdem gewisse unveränderte Teile des Körpers mit DisplayLists rendern, und nur veränderte Teile im immediate Mode. Kommt aber eben stark drauf an, wie denn der Körper aussieht und verändert wird.