DirectX VertexBuffer Lockzeiten Frage
-
Es kann nicht sein, dass du irgendwie falsche Werte an den Aufruf zum rendern hast, oder? - Also falsche Anzahl o.ä.? - Das in Verbindung mit Debug Ausgaben kann die FPS schon recht senken. (Also hast du DX Debug an?)
Im release hast du auch kompiliert? (blöde Frage ich weiss, aber man muss mal sicher gehen. ;)) - Sollte hier zwar nicht allzu viel ausmachen, da du ja lediglich einmal befüllst, aber könnte sonst was sein.
-
drakon schrieb:
Es kann nicht sein, dass du irgendwie falsche Werte an den Aufruf zum rendern hast, oder? - Also falsche Anzahl o.ä.? - Das in Verbindung mit Debug Ausgaben kann die FPS schon recht senken. (Also hast du DX Debug an?)
Im release hast du auch kompiliert? (blöde Frage ich weiss, aber man muss mal sicher gehen. ;)) - Sollte hier zwar nicht allzu viel ausmachen, da du ja lediglich einmal befüllst, aber könnte sonst was sein.
Falsche Werte sind ausgeschlossen. Ich habe den Vertexbuffer gekapselt, dort werden alle Primitiven zwischen gespeichert und dann in einem Rutsch mit nem Lock rübergeschoben. Der Drawcall ist auch Fehlerfrei, der Vertexbuffer ist korrekt im Stream gesetzt und die Anzahl der zu zeichnenden Primitiven stimmt auch. Debug Modus für DX is aus.
Release hab ich auch gemacht, sonst wäre es ja auf den anderen Rechnern garnicht gelaufen.
Ich hab auch das ganze mal durch ein Array im RAM ersetzt das befüllt und gerendert wird, da ist das Problem 1:1 das gleiche, das schließt den Vertexbuffer ansich schonmal aus. Einstellungen an DX werden sonst auch nirgens vorgenommen (auch nicht in der Nachrichtenfunktion). Neben einigen kleinen matrix berechnungen wird ind er Schleife nur die Kamera gesetzt, und die 40k Primitive in 20 Drawcalls gezeichnet.
Ich bin mir sicher das irgendwo ein fehler sien muß, nur leider kann ich keine Unstimmigkeiten fidnen, vor allem Kurios ist die Tatsache das das einmalige Lock/Unlock des Bufefrs am start des programms die FPS in den Keller drückt.
-
OK, wollte nur mal sicher gehen.
Vor der Schleife. Rendere ich jetzt die 120k Vertices ohne vorher ein Update zu machen, also nur mit dem Datenmüll der an der Stelel ist, erhalte ich 660FPS, Update ich ihn aber dropt alles auf 6FPS, dabei ist es egal ob ich den Buffer 1x pro Frame oder einmal am Anfang des Programms fülle.
Ich verstehe nicht ganz, was du meinst mit Updaten.. - Du erstellst ja einen VertexBuffer mit
Device::CreateVertexBuffer (..)und da ist ja erstmal nix drin. Und dann füllst du da (random?) Dreiecke ein.
Aber was für Datenmüll? - Oder meinst du, dass du zuerst random Vertices reinschiebst?
-
drakon schrieb:
Ich verstehe nicht ganz, was du meinst mit Updaten.. - Du erstellst ja einen VertexBuffer mit
Device::CreateVertexBuffer (..)und da ist ja erstmal nix drin. Und dann füllst du da (random?) Dreiecke ein.
Aber was für Datenmüll? - Oder meinst du, dass du zuerst random Vertices reinschiebst?Naja du erstellt den Buffer ja eigentlich und machst dann ein Update (also locken reinschieben unlocken). Wenn man den Buffer erstellt ist ja aber schon irgendwas drin, der wurde ja erstellt und liegt auf einem Stück VRAM, so war das gemeint, mit Datenmüll meine ich das was ohne Updaten im Buffer wäre und ansonsten fülle ich ihn mit 120k Vertices die 20k Quadrate ergeben, die liegen alle übereinander, dh jedes verdeckt seinen Vorgänger, also im Grund ein Stack. Ich habe vorhin auchmal Zufallswerte genommen für die 4Ecke, bei denen sie sichtbar wären, dabei war dann die FPS nichtmehr ermittelbar, da wäre dann eine Angabe in Frames per Minute angebracht gewesen.
-
Hmm. Ich bin mir nicht mehr ganz sicher, aber ich dachte, dass ich auch mal relativ viele Vierecke aufeinander gehabt habe (also identische Position) und da sind mir die FPS ebenfalls abgekracht..
Ordne die Dreiecke mal zu einer Tilemap an und schau, was dann passiert.Also ich kann mit ~5FPS (2 Jahre altes Notebook) ~1'800'000 Dreiecke rendern.
Das sollte also prinzipiell gehen. Aber ich dachte wirklich,dass wenn die Dreiecke aufeinadner liegen die Graka i-wie ein Problem damit hat. (Vielleicht können gewisse Optimierungen nicht ausgenutzt werden, weil ja immer die gleichen Bereiche angesprochen werden müssen und so gewisse Parallele Operationen nicht gehen.. So stelle ich mir das in etwa vor)
-
Ja das is es, ich hab jetzt 12 Lagen a ~200k Polys in nen Buffer gestopft und damit ~2,7Mio mit 12FPS gerendert. Danke für den Anstoß, hätte nicht damit gerechnet da smir hier die Technik einen Strich durch die Rechnung macht.
-
OK. Das klingt jetzt realistisch.
-
Xebov schrieb:
und ansonsten fülle ich ihn mit 120k Vertices die 20k Quadrate ergeben, die liegen alle übereinander, dh jedes verdeckt seinen Vorgänger, also im Grund ein Stack.
Falls die alle Bildschirmfüllend waren, dann hast du da 20.000 mal auf jeden Pixel gerendert. Also Overdraw-Faktor 20.000. Natürlich ist das langsam.
Oder waren da die Dreiecke flächenmässig ca. gleich gross wie beim späteren Test mit "12 Lagen"?
-
hustbaer schrieb:
Xebov schrieb:
und ansonsten fülle ich ihn mit 120k Vertices die 20k Quadrate ergeben, die liegen alle übereinander, dh jedes verdeckt seinen Vorgänger, also im Grund ein Stack.
Falls die alle Bildschirmfüllend waren, dann hast du da 20.000 mal auf jeden Pixel gerendert. Also Overdraw-Faktor 20.000. Natürlich ist das langsam.
Oder waren da die Dreiecke flächenmässig ca. gleich gross wie beim späteren Test mit "12 Lagen"?
Nein, die waren 200x200 Pixel und lagen alel üebreinander, also 20k Facher Overdraw. Die 12 Lagen waren je 660k a 4x4.
-
Xebov schrieb:
hustbaer schrieb:
Xebov schrieb:
und ansonsten fülle ich ihn mit 120k Vertices die 20k Quadrate ergeben, die liegen alle übereinander, dh jedes verdeckt seinen Vorgänger, also im Grund ein Stack.
Falls die alle Bildschirmfüllend waren, dann hast du da 20.000 mal auf jeden Pixel gerendert. Also Overdraw-Faktor 20.000. Natürlich ist das langsam.
Oder waren da die Dreiecke flächenmässig ca. gleich gross wie beim späteren Test mit "12 Lagen"?
Nein, die waren 200x200 Pixel und lagen alel üebreinander, also 20k Facher Overdraw. Die 12 Lagen waren je 660k a 4x4.
OK.
Du weisst aber schon dass Grafikkarten nicht bloss für jedes Dreieck Zeit brauchen, sondern auch für jeden Pixel?
-
hustbaer schrieb:
Xebov schrieb:
hustbaer schrieb:
Xebov schrieb:
und ansonsten fülle ich ihn mit 120k Vertices die 20k Quadrate ergeben, die liegen alle übereinander, dh jedes verdeckt seinen Vorgänger, also im Grund ein Stack.
Falls die alle Bildschirmfüllend waren, dann hast du da 20.000 mal auf jeden Pixel gerendert. Also Overdraw-Faktor 20.000. Natürlich ist das langsam.
Oder waren da die Dreiecke flächenmässig ca. gleich gross wie beim späteren Test mit "12 Lagen"?
Nein, die waren 200x200 Pixel und lagen alel üebreinander, also 20k Facher Overdraw. Die 12 Lagen waren je 660k a 4x4.
OK.
Du weisst aber schon dass Grafikkarten nicht bloss für jedes Dreieck Zeit brauchen, sondern auch für jeden Pixel?Ja, das Problem hing aber nur an den 20k Schichten, ich hatte es glaube ich garbnicht erwähnt das die mit Alphablending gemacht wurden.
