Performance: Unterschied zwischen den Versionen
Aus DGL Wiki
(Die Seite wurde neu angelegt: {{Offline}} === Einstieg === # Vermeide Kommunikation zwischen CPU und GPU. #* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Verme...) |
|||
| Zeile 3: | Zeile 3: | ||
=== Einstieg === | === Einstieg === | ||
# Vermeide Kommunikation zwischen CPU und GPU. | # Vermeide Kommunikation zwischen CPU und GPU. | ||
| − | #* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also [[glBegin]]() und [[glEnd]](). Sofern du aber | + | #* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also [[glBegin]]() und [[glEnd]](). Sofern du aber nur ein, zwei einzelne Dreiecke rendern möchtest ist der Immediate Mode akzeptabel. |
#* Verwende [[VBO|Vertexbuffer-Objects]] oder [[Displayliste]]n. | #* Verwende [[VBO|Vertexbuffer-Objects]] oder [[Displayliste]]n. | ||
| − | # Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint | + | # Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint die irgendetwas rendern, z.B. [[glDrawArrays]], [[glDrawElements]], ..., aber auch [[glMultiDrawArrays]], usw... |
#* Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst. | #* Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst. | ||
#* Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht. | #* Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht. | ||
| Zeile 14: | Zeile 14: | ||
# Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim SwapBuffers wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst swapBuffers auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert. | # Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim SwapBuffers wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst swapBuffers auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert. | ||
| − | === | + | === Fortgeschrittene Techniken === |
| − | # Wenn du viele identische Objekte renderst, überlege ob du Instancing einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware. | + | # Wenn du viele identische Objekte renderst, überlege ob du [[GL_ARB_draw_instanced|Instancing]] einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware. |
| − | # Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im Shader berechnest. (Beispiel: [[ | + | # Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im Shader berechnest.<br>(Beispiel: [[Shader#Beispiel:_Heightmap-Terrain|Heightmap-Terrain]]) |
# Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Siehe vorheriger auch Tipp. Was sinnvoll ist hängt davon ab, ob eher Rechenleistung oder Speicher(-bandbreite) knapp sind. | # Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Siehe vorheriger auch Tipp. Was sinnvoll ist hängt davon ab, ob eher Rechenleistung oder Speicher(-bandbreite) knapp sind. | ||
| − | # Überlege ob du aufwendige Berechnungen, z.B. ein [[GLSL_Partikel_2|Partikelsystem]] nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: [[Tutorial_Framebufferobject|Framebuffer-Objects]] und [[Shader#Transform-Feedback_(auch_Stream-Out)|Transform-Feedback]]. | + | # Überlege ob du aufwendige Berechnungen, z.B. ein [[GLSL_Partikel_2|Partikelsystem]], nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: [[Tutorial_Framebufferobject|Framebuffer-Objects]] und [[Shader#Transform-Feedback_(auch_Stream-Out)|Transform-Feedback]]. |
=== Quellen === | === Quellen === | ||
* [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GPU Programming Guide] | * [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GPU Programming Guide] | ||
Version vom 30. März 2009, 19:22 Uhr
Bitte haben Sie etwas Geduld und nehmen Sie keine Änderungen vor, bis der Artikel hochgeladen wurde. |
 |
Einstieg
- Vermeide Kommunikation zwischen CPU und GPU.
- Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also glBegin() und glEnd(). Sofern du aber nur ein, zwei einzelne Dreiecke rendern möchtest ist der Immediate Mode akzeptabel.
- Verwende Vertexbuffer-Objects oder Displaylisten.
- Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint die irgendetwas rendern, z.B. glDrawArrays, glDrawElements, ..., aber auch glMultiDrawArrays, usw...
- Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst.
- Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht.
- Nutze den Z-Buffer aus.
- Sortiere nicht deine Polygone einzeln nach der Entfernung zur Kamera (Painters-Algorithm), sondern verwende den Z-Buffer.
- Sofern du aufwendige Shader oder viele Texturen verwendest, rendere deine Objekte (nicht Polygone) von vorne nach hinten. Also grob sortieren und den Rest den Z-Buffer machen lassen.
- Wenn du transparente Objekte hast, rendere zunächst von die undurchsichtigen Objekte. Die transparenten Objekte renderst du dann sortiert von hinten nach vorne.
- Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim SwapBuffers wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst swapBuffers auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert.
Fortgeschrittene Techniken
- Wenn du viele identische Objekte renderst, überlege ob du Instancing einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware.
- Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im Shader berechnest.
(Beispiel: Heightmap-Terrain) - Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Siehe vorheriger auch Tipp. Was sinnvoll ist hängt davon ab, ob eher Rechenleistung oder Speicher(-bandbreite) knapp sind.
- Überlege ob du aufwendige Berechnungen, z.B. ein Partikelsystem, nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: Framebuffer-Objects und Transform-Feedback.
