VBO langsamer als Display List??
-
Mein Programm zeichnet mir standardmaessig eine Heightmap mit ca. 35 FPS bei ~1Mio Quads, wobei ich Display Lists verwende. Nun dachte ich mir, vielleicht kriege ich etwas mehr Performance, wenn ich einen VBO fuer die Vertexdaten nehme. Nachdem ich das gemacht hatte, krieg ich jedoch maximal 15 FPS raus... Ich hatte schon einen Beitrag gefunden, der schon einige Zeit zurueck liegt und das Problem bei einer ATI Radeon 7xxx Karte schildert. Allerdings tauchte bei dem das Problem erst auf, als er mit glNormalArray() Normalen fuer die Vertices definierte. Habe schon so einiges versucht: Beleuchtung ausgeschalten, Normalen entfernt, glInterleavedArrays durch glVertexPointer/glNormalPointer() ersetzt, aber nichts scheint zu klappen... Die Display Liste ist viel schneller.
Hat jemand eine Idee, was ich noch versuchen koennte? Liegt es vielleicht daran, dass ich Quads statt Triangles benutze?
Edit: Grafikkarte ist ATI Radeon HD4870 (512MB), OS: Windows 7
-
Wenn VBOs langsamer sind als irgendwas andres dann verwendest du VBOs falsch. Als erstes solltest du mal von Quads Abstand nehmen. Die Grafikkarte kann nur Dreiecke rendern, alles andre muss erst entsprechend aufbereitet werden. Nachdem es sich bei deinem Terrain wohl um ein zusammenhängendes Dreiecksnetz handelt führt der effizienteste Weg es zu rendern über VBOs und indizierte Dreieckslisten (glDrawRangeElements() + GL_TRIANGLES).
Abgesehen von all dem sind ~1M Quads schon ein ganzer Haufen. Ist da immer alles sichtbar? Ein einfacher Quadtree oder sogar schon eine Unterteilung in kleinere Patches könnte in Verbindung mit Frustrum Culling schon einiges bringen wenn du nicht grad das Terrain von oben anschaust...
-
Wie macht man denn überhaupt aus Quads ein Terrain ohne die Ebene des Quads kaputtzumachen?
Oder ist das egal, weil die Graka das zu Triangles zerschnippelt?
-
Ja es wird im Endeffekt alles in Dreiecke zerschnippelt da die Graka nichts andres rendern kann. Ich weiß jetzt nicht viel über den genauen Overhead von Quads aber ich könnt mir durchaus vorstellen dass das gar nicht so unwesentlich zum Vorteil der Displaylists beiträgt, da der Treiber dort einfach schon beim Erstellen der Liste Dreiecke machen kann.
-
dot schrieb:
Wenn VBOs langsamer sind als irgendwas andres dann verwendest du VBOs falsch.
Diese pausschalaussage ist falsch. Renderlisten haben mehr optimierungen als nur vertex bezogen sind, deswegen kann eine RL schneller sein und dennoch ist es keine falschverwendung eines VBOs.
-
Cpp_Junky schrieb:
Oder ist das egal, weil die Graka das zu Triangles zerschnippelt?
Die Grafikkarte vermutlich nicht, aber der Treiber. Auf jeden Fall kann man "nicht-flach" Quads an OpenGL oder Direct3D übergeben, und bekommt ein Ergebnis. Man kann sich dann nur nicht aussuchen wie der Quad "zerschnitten" wird.
rapso schrieb:
dot schrieb:
Wenn VBOs langsamer sind als irgendwas andres dann verwendest du VBOs falsch.
Diese pausschalaussage ist falsch. Renderlisten haben mehr optimierungen als nur vertex bezogen sind, deswegen kann eine RL schneller sein und dennoch ist es keine falschverwendung eines VBOs.
Wäre es richtig zu sagen dass man mit VBOs immer gleich schnell oder schneller ist, wenn man auch alle anderen Dinge "richtig" macht?
-
hustbaer schrieb:
Cpp_Junky schrieb:
Oder ist das egal, weil die Graka das zu Triangles zerschnippelt?
Die Grafikkarte vermutlich nicht, aber der Treiber. Auf jeden Fall kann man "nicht-flach" Quads an OpenGL oder Direct3D übergeben, und bekommt ein Ergebnis. Man kann sich dann nur nicht aussuchen wie der Quad "zerschnitten" wird.
rapso schrieb:
dot schrieb:
Wenn VBOs langsamer sind als irgendwas andres dann verwendest du VBOs falsch.
Diese pausschalaussage ist falsch. Renderlisten haben mehr optimierungen als nur vertex bezogen sind, deswegen kann eine RL schneller sein und dennoch ist es keine falschverwendung eines VBOs.
Wäre es richtig zu sagen dass man mit VBOs immer gleich schnell oder schneller ist, wenn man auch alle anderen Dinge "richtig" macht?
du meinst, unter der annahme dass du
-zugangn zu allen dingen hast die auch der treiber zugreifen kann
-das wissen ueber alle optimierungen hast die display lists machen
-du fuer jede hardware auf ihre spezifischen eigenschaften optimierst so wie es der treiber ueber profile macht
?falls du das meinst, dann waere es richtig zu sagen, dass wenn du das gleiche machst, du das gleiche ergebniss erzielst (ich denke schneller wirst du nicht sein bei gleicher arbeit).
oder habe ich falsch verstanden was du mit "richtig" meinst?
-
@rapso:
Ne, ich meine nur die Dinge "richtig" machen die man über die normale API (OpenGL oder eben Direct3D) machen kann.
Und mit "richtig machen" meine ich nicht Wissen über die Internas des Grafikkarten-Treibers auszunutzen, sondern einfach die API so zu verwenden wie zu verwenden sie gedacht ist, damit man optimale Performance rausholen kann.
-
Also ob man mit VBOs genau so schnell oder schneller sein kann, wenn man weniger optimierungsmoeglichkeiten zur verfuegung hat und weniger optimierungen kennt?
ich glaube das beantwortet sich von selbst
du kannst genau so schnell sein, du kannst manchmal schneller sein (weil manche optimierungen zu zeitaufwendig sind beim compilieren von displaylisten) und du kannst aber auch langsammer sein, weil displaylisten eben mehr machen koennen als nur vertexbuffer zu optimieren (selbst wenn du alles richtig machst, z.B. fuer alle renderstates commandbuffer bauen und auch in einer feineren granularitaet redundante states entfernen).
wenn du es drauf anlegst und wirklich optimierst bis du vor cutting-edge blutest, kannst du sicherlich oft schneller sein fuer deinen spezifischen fall, aber das ist dann nicht mehr wirklich VBO related (und von treiber zu treiber, oder hersteller zu hersteller kann die situation anders aussehen).
-
@dot: Nein, es ist nicht immer alles sichtbar und Frustum Culling verwende ich noch nicht. Es ging mir auch nur um eine Antwort zu der Frage, warum es langsamer sein kann. Deine Erklaerung leuchtet mir ein, ich werde mir eventuell ueberlegen, das Ganze mit indizierten Trianglearrays nochmal auszuprobieren. Ob der Aufwand bei meinem Projekt gerechtfertigt ist, bleibt noch zu ueberpruefen. Bei der Display List habe ich auch beobachtet, dass die Framerate hoch geht, wenn nicht alles sichtbar ist, bzw. nach oben schnellt, sobald die Heightmap aus dem Viewing Frustum verschwindet. Das konnte ich beim VBO nicht beobachten.
Edit: Btw, was ist ein Quadtree/wie funktioniert der?
-
Ein Beispiel, in dem Displaylisten schneller sein müssten - so zumindest meine Vorstellung - , ist Multiindexing. Wenn man Texturkoordinaten, Normalen oder andere Vertexattribute per Element oder anderen "Render-"Einheiten definiert ist das mit VBOs nicht so leicht abzubilden.
-
Nein das ist mit VBOs total straightforward. Displaylisten sollten dann nen Vorteil haben wenn du viel API Overhead sparen kannst, z.B. indem du haufenweise Statechanges etc. mit in eine Displayliste packst sodass der Treiber sich intern qausi direkt den Commandbuffer fürs Rendern von einem Objekt zusammenbauen kann und du dann später in jedem Frame nurmehr den Befehl geben musst alles an die Graka zu schicken.
