Hallo allerseits mal wieder,

Habe mich mal an einer Performance Optimierung für mein Spiel bemüht. Dabei habe ich 2 Sachen ausprobiert und die Ergebnisse finde ich persönlich sehr verwirrend, weil sie dem widersprechen was ich im Wiki gelesen habe.

1. Z Only Pass
Um Performance einzusparen wollte ich diesen einbauen, doch er hat genau das Gegenteil bewirkt:
Bei wenig Objekten - mit Z Only Pass: 16% Graka Auslastung (mit MSI Afterburner ausgelesen)
Bei wenig Objekten - ohne Z Only Pass: 13% Auslastung
Bei vielen Objekten - mit Z Only Pass: 80% Graka Auslastung
Bei vielen Objekten - ohne Z Only Pass: 60% Graka Auslastung

2. Statechange Minimierung
Ich hab die Objekte so angeordnet, dass nur noch 2 Texture Changes nötig waren, vorher war 2x Anz Objekte.
Bei wenig Objekten - mit Sortierung: 13% Graka Auslastung (mit MSI Afterburner ausgelesen)
Bei wenig Objekten - ohne Sortierung: 13% Auslastung
Bei vielen Objekten - mit Sortierung: 48% Graka Auslastung
Bei vielen Objekten - ohne Sortierung: 45% Graka Auslastung
Hier ist der Unterschied zwar nicht groß, aber ein Vorteil erkenne ich darin nicht.

Hier mal der Code für den Z Only Pass, falls ich da was falsch gemacht hab:


Hier auch noch mal der Code von der "Sortierung" bzw. wie es angewandt wird (in gekürzter Form):

Sortiertes Rendern:


Und hier für das unsortierte Rendern:


Das wäre es dazu. Und dann hätte ich noch eine Frage, wie man bei vielen Objekten, die Last auf der CPU durch die vielen Matrix Operationen gering hält?

Vielen Dank schonmal.

So wie ich das sehe, versuchst du am falschen Ende zu optimieren. Als erstes solltest du schauen, was bei dir die Performanceprobleme verursacht. Im groben unterteilt man das in vier Bereiche:

• CPU deine Spiellogik ist nicht schnell genug
• BUS du schickst zu viele Befehle an die Grafikkarte. Der Bus kann diese nicht schnell genug übermitteln.
• Vertex (Shader)-Limitierung du hast zu viele Vertices oder deine Vertex-Shader sind zu anspruchsvoll
• Fragment (Shader)-Limitierung du benutzt zu viele Texturen oder eine Fragment-Shader sind zu anspruchsvoll

(die Liste ist relativ grob und nicht 100%ig exakt. Aber für die erste Erklärung reichts)

Punkt 1 lasse ich mal weg, denn deine Grafikkarte sollte das nicht stören. Ich würde ziemlich sicher auf Punkt 2 tippen. Dafür sprechen die Messergebnisse sowie dein Quellcode. Daher bringt dir der Z-Only-Pass überhaupt nichts - im Gegenteil, denn der ist eher eine Lösung für Punkt 4. Punkt 3 könnte rein theoretisch auch noch sein, denn die Symptome wären mit den aktuellen ziemlich identisch. Ich bin jetzt aber einfach mal Frech und behaupte, dass du keine 30 Millionen Vertice pro Frame renderst (theoretische Leistung einer GeForce 7900 GT aus dem Jahre 2006: 940 Millionen Vertices / Sekunde) oder komplexe Vertex-Shader benutzt .

Bei dir ist einfach das Problem, dass du zu kleine und zu viele Draw-Befehle (glCallList bei dir) rendern lässt. Somit solltest du dich erst mal nicht um Z-Pre-Pass oder sonstige Sachen kümmern, sondern dein Renderpfad optimieren. Versuche nicht sichtbare Objekte wegzulassen und fasse mehrere kleinere, identische Objekte zu einem großen Objekt zusammen (falls die Objekte statisch sind). Wenn es jedoch nur sehr wenige statische Objekte gibt, musst du wie bereits erwähnt schauen, ob ein Objekt aktuell überhaupt sichtbar ist und es nur bei Bedarf zeichnen (Stichworte: Frustum Culling, Octree, BSP-Bäume, Portal). Für den Anfang dürfte das Frustum Culling erstmal reichen. Sobald die Spielwelt komplexer wird, sollten die anderen Techniken auch in Betracht gezogen werden.

Was du aber auf jeden Fall weiter verfolgen solltest ist die Minimierung der State-Changes. Sowas später im Nachhinein implementieren zu wollen, wenn alles bereits relativ rund läuft und ein gewisser Komplexitätsgrad erreicht ist, ist nicht gerade eine schöne Aufgabe. Einen Pre-Depth-Pass kann man hingegen schnell einbauen.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Frustrum Culling ist schon drin, das hatte ich für den Test aber absichtlich deaktiviert, um ein deutlicheres Ergebnis zu erzielen ^^. Hat ja scheinbar eher das Gegenteil bewirkt

Danke auf jeden Fall.

P.S. Dazu nochmal eine Frage, in einem kleinen Mini Nebenprojekt, hab ich für ein Quad eine Displayliste gemacht ist in so einem Fall dann sogar Direct-Mode besser? weil dann spar ich mir ja erstens den ganzen Haufen Draw Calls und ich könnte einfach die Quads selbst verschieben und mir auch noch die Matrix Operationen sparen. (2D Projekt).
Oder Anders gefragt, wie render ich am besten ganz viele simple Objekte? Muss ich da zwangsläufig auf Instacing zurückgreifen, weil das scheint mir schon mächtig kompliziert :/

Hey,

die Seite hilft vll noch weiter beim generellen Verständnis was man optimieren kann und wie man rausfindet wo das problem liegt:
http://http.developer.nvidia.com/GPUGem ... _ch28.html

Ganz viele simple Objekte renderst du am besten alle auf einmal. In vielen Fällen jedenfalls dürfte das eine gute lösung sein.
Dazu kannst du (bei gleichen Objekten aber unterschiedlichen positionen/rotationen) instancing benutzen. Oder wenn die Objekte statisch sind (sich nicht bewegen) kannst du sie auch in einem pre-processing step in einen großen Buffer packen, was die Menge der Vertex-Daten natürlich erhöht, bei simplen Objekten wahrscheinlich aber nicht ins Gewicht vällt.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Ich sage es ja nur ungern. Aber die GPU Auslastung alleine betrachtet ist ziemlich nichtssagend. Wenn du (wie ich vermute) in einer ungebremsten Schleife deine Frames zeichnest, dann ist eine höhere GPU Auslastung besser. Ideal wäre da sicher eine Auslastung der GPU von 100%. Denn das würde bedeuten, dass deine GPU auf Nichts anderes warten muss als auf sich selbst. Auch wenn sich das sicher nicht immer pauschal sagen lässt.
Aber zu deinen Tests. Du musst natürlich bei der GPU Auslastung auch immer die FPS mit betrachten. Denn wenn diese gleich bleibt oder geringer wird, dann ist die höhere GPU Auslastung definitiv negativ. Wenn diese durch die Optimierungen aber gestiegen ist, dann ist eine höhere GPU Auslastung aber nur noch logisch. Denn das bedeutet, dass die Arbeit effektiver erledigt wurde.

Wie sich aber die FPS in deinem Test verhalten hat ist zu mindest für mich nicht ersichtlich. Und damit sind die Ergebnisse nur die halbe Wahrheit. Wenn nicht sogar unbrauchbar. Am Sinnvollsten kann man wohl die Geschwindigkeit in einer komplett ungebremsten Schleife messen. Mit komplett meine ich, dass du auch V-Sync mit berücksichtigen musst. Also deaktivieren. Denn das kann in Situation mit wenig Arbeit dafür sorgen, dass die FPS die 60Hz nicht überschreiten und die GPU auf den Monitor waren muss. Dadurch würden die Messergebnisse auch wieder verfälscht werden.

@Lossy Ex: Es ist mir schon klar das ich die FPS mit einbeziehen muss. In denNvidia-Systemeinstellungen ist VSync bei mir automatisch aktiviert -> max 60 FPS. Bei den vielen Objekten betrug die eigentliche GPU Auslastung gerade mal 40% Bei 30 FPS. Und das habe ich dan auf 60 FPS umgerechnet -> Folglich 80% bei den vielen Objekten mit Z Only Pass. Ich hab somit die Auslastung immer umgerechnet auf 60 FPS, damit sollten die Ergebnisse doch auch brauchbar sein?

Bei einer ungebremsten Schleife kommt die CPU nicht mit, da ich ja wie gesagt die CPU seitigen Optimierungen für den Test deaktiviert hatte und bei meinem Test wollte ich lediglich nur den Unterschied auf der GPU feststellen, in wie fern sich das dort lohnt, daher wollte ich die CPU erstmal außenvor lassen.

@Shaijan: OK, Danke, dann les ich mich doch mal in Instancing rein.

Wenn du 40% last bei 30 FPS hast, aber VSync 60 FPS erlaubt, heißt das, dass dein CPU-seitiger Code nicht damit hinterher kommt, die daten schnell genug auf die GPU zu schieben oder es zu viele Daten für den bus sind.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ähm, statt du rätseln, was es sein könnte empfehle ich lieber es einfach mal nach zu schauen.
Bei AMD CPU CodeXL,
bei Intel CPU VTune oder CodeXL,
bei AMD GPU CodeXL,
bei Nvidia GPU Perfkit oder CodeXL,
bei Intel GPU GPA oder CodeXL.

Nach messen, gucken wo die Zeit hin geht und anfangen Pläne zu schmieden.

edit:
Um den in Hardware gegossene Pipeline für Pre Z-Pass zu verwenden ist folgendes notwendig.
-Farben schreiben deaktivieren
-fragmentshader muss mindestens Tiefenwerte schreiben(sollte auch nur dies tun)
-alpha test muss deaktiviert sein

Um es sinnvoll zu nutzten render von near zu far clipping plane, damit der fragmentshader geskippt wird und kein overdraw passiert. Ergo Tiefentest solltest du anschalten !

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Oh, mit VSync ist das nicht so einfach. VSync limitiert nicht einfach nur bei der Bildwiederholrate des Bildschirms.

Angenommen der Bildschirm hat eine Wiederholrate von 60Hz (links: wie schnell die Grafikkarte rendert, rechts: die tatsächlichen FPS):

• 100 FPS -> 60 FPS
• 60 FPS -> 60 FPS
• 59 FPS -> 40 FPS oder auch 30 FPS (abhängig vom Monitor)

Die Grafikkarte wartet also immer auf den nächsten Refresh-Zyklus des Monitors, somit kann 30/40 FPS auch bedeuten, dass du ohne VSync 59 FPS schaffen könntest. John Carmack hat im Laufe der Entwicklung von Rage eine neue Extension vorgeschlagen: Adaptive Vertical Sync. Hierbei wird alles über 60 FPS auf 60 FPS limitiert, alles was darunter liegt wird ohne Sync an den Monitor geschickt. Die Extension ist relativ neu, ich weiß leider nicht genau wie sie genau heißt geschweige denn welche Grafikkarten diese unterstützen. Zum ersten reinlesen eignet sich dieser Link. Aber das nur so am Rande. Kernaussage: bei Performance-Messungen VSync IMMER deaktivieren.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Das was littleDave angebracht hat sollte in jedem Fall berücksichtigt werden. Genau darauf habe ich auch angespielt.

Aber die Verrechnung von FPS und Leistung finde ich auch nicht gut. Denn solltest du mal den Fall haben, dass du 30fps und 100% last hast, dann landest du bei 200% Last. Das ist verwirrend. Als anderes Beispiel. Du hast 30fps und 30% Last. Ergeben 60% Last. Du hast aber mit einem anderen Algorithmus 10fps und 10% Last. Würden also auch 60% Last ergeben. Klar. Das letztere wäre definitiv schonender für die GPU. Aber besser wäre dennoch das erste Ergebnis. Okay. Du sagtest, dass du nur die GPU testen wolltest. Aber wenn du die GPU besser ausnutzen könntest dafür aber die CPU massiv überforderst. Würdest du im Endeffekt ja aber schlechter dastehen. Von daher denke ich, dass man bei solchen Tests alle beteiligten berücksichtigen muss. Da denke ich, dass man die CPU nicht außen vor lassen darf.

PS: Weiß nicht ob ich gerade sinnvoll in der Lage nicht zu wirre Gedanken zu haben.

Das kommt darauf an, was das Quad machen soll.
Wenn das Quad immer die gleichen UV's benutzt, dann kannst du über eine OpenGL Extension Point Quads benutzen, bzw. über ein Geometry Shader das gleiche erreichen(aus jeden Punkt wird ein Quad mit -0.5 bis 0.5 für x und y erstellt und UV's von 0-1.0 generiert).
So braucht man nur noch eine Textur binden und kann mit Punkten arbeiten.

Wenn das immer noch zu langsam ist, weil man viele millionen davon hat, dann kann man das bewegen auch auf die Grafikkarte verlagern, das macht man dann über transform feedback und es gibt dazu ein gutes Tutorial in unserem Wiki(dank coolcat).
Dabei benutzt du 2 Texturen, die erste kodiert in rgb die xyz Koordinaten und in der 2. den Bewegungsvektor.
Man kann es für 2D auch auf eine Textur verpacken, rg=positionXY ba=forceXY.
Was man dann macht ist forceXY[Z] durch ein neuen Impulse zu ersetzen, wenn man ein Objekt bewegen will.
Dabei kann man dann weitere Kräfte, wie Schwerkraft, Reibung im Shader durch Konstanten rein rechnen.
Das ist dann halt Physik und da kann man halt immer weiter gehen aber kurz gesagt, du kannst ohne Schwerkraft und Dämpfung z.B. bei Spieler läuft vorwärts durch einmal schreiben des Impuls laufen lassen und beim loslassen der Taste wird der Impulse auf 0.0f gesetzt.
Das Culling kann man auch im Geometry Shader machen.

Da man schon lesen kann, dass dies nicht so einfach ist, kann ich folgendes sagen.
Je mehr Performance man raus kitzeln will, des so komplexer wird es.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004