Minimieren von Kommunikation zu GraKa?



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


  • Mod

    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();



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

    1. ok
    2. 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?
    3. ok ­čÖé Haett ich wohl auch draufkommen muessen.


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



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



  • Lieber mehrere kleine Buffer verwenden?

    Bye, TGGC (W├Ąhle deine Helden)



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



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


Log in to reply