Archiv verlassen und diese Seite im Standarddesign anzeigen : Wodurch entsteht CPU- bzw. GPU-Limitierung
Hallo,
ich habe nach Benutzung der Suche nicht gefunden, also die Frage.
Durch welche Elemente entsteht in Spielen eine der beiden Limitierungen.
GPU-Limitierung:
-Auflösung
-AF/AA
-hochauslösende Texturen
CPU-Limitierung:
-aufwendige Geometrie, viele Polys (?)
-Physik
-KI
Wie sieht es mit verschiedenen "Effekten/Detaillevel" aus, mir ist aufgefallen das in CPU Benches sehr niedrige Auflösungen gewählt werden, um GPU-Limitierung zu vermeiden. Aber dennoch wird oftmals mit MAX Detail gebencht. Belasten diese Effekte, Reflexionen usw. also doch die CPU ?
Ich hoffe mir kann das jemand mal erklären, welche Art von Effekten die Graka belasten und welche die CPU.
Weil so kann man vielleicht herausfinden, ob der Verzicht auf Effekt XY die vorhandene GPU/CPU-Limitierung aufhebt, falls in nem Spiel die Frames zu schlecht werden.
Piffan
2006-11-13, 23:03:33
Hallo,
ich habe nach Benutzung der Suche nicht gefunden, also die Frage.
Durch welche Elemente entsteht in Spielen eine der beiden Limitierungen.
GPU-Limitierung:
-Auflösung
-AF/AA
-hochauslösende Texturen
CPU-Limitierung:
-aufwendige Geometrie, viele Polys (?)
-Physik
-KI
Wie sieht es mit verschiedenen "Effekten/Detaillevel" aus, mir ist aufgefallen das in CPU Benches sehr niedrige Auflösungen gewählt werden, um GPU-Limitierung zu vermeiden. Aber dennoch wird oftmals mit MAX Detail gebencht. Belasten diese Effekte, Reflexionen usw. also doch die CPU ?
Ich hoffe mir kann das jemand mal erklären, welche Art von Effekten die Graka belasten und welche die CPU.
Weil so kann man vielleicht herausfinden, ob der Verzicht auf Effekt XY die vorhandene GPU/CPU-Limitierung aufhebt, falls in nem Spiel die Frames zu schlecht werden.
Wo ist denn nun die Frage? :tongue:
Du hast oben eigentlich alles schön aufgezählt und alles stimmt. Was willst Du eigentlich außerdem wissen?
Es gibt sicher viele Effekte, die auch die CPU belasten. Ergo wird man bei bestimmten Benches volle Details einstellen....Zumal man aus den Beschreibungen der Ingame- Optionen oftmals nicht schlau wird und da gar nicht mal erkennen kann, ob die Details mehr die Graka oder mehr den Proz fordern. Lobenswert wäre ne Einteilung der Optionen nach hauptsächlicher Belastung......
Probieren geht über studieren. Gerade bei Gothic 3 muss man ganz schön rumtesten, bis man merkt, welche Optionen die Performance in erster Linie runterziehen, das hängt ja sehr stark vom System des Spielers ab und vom jeweiligen Spiel. So ist Gothic 3 ein ziemliches Texturenmonster, so dass die hohen Texturen auf vielen Systemen die Karte spürbar ausbremsen. Andere Karten schwächeln erst, wenn man bei AF und Auflösung in die Vollen geht.
Hallo,
ich habe nach Benutzung der Suche nicht gefunden, also die Frage.
Durch welche Elemente entsteht in Spielen eine der beiden Limitierungen.
CPU-Limitierung:
-aufwendige Geometrie, viele Polys (?)
Dazu hätt ich auch mal noch ne Frage.
Habe schon öfters gelesen das aufwändige Geometrie die CPU belastet.
Dabei werden doch die Verticies nur 1 mal erzeugt und dann von der Grafikkarte transformiert und verschoben und gerendert ?!
Warum ist es also so CPU belastend ?
Spasstiger
2006-11-14, 01:01:00
Sichtweite geht in der Regel gleichermaßen auf CPU und GPU, Schatten fressen oft mehr CPU-Leistung als GPU-Leistung (außer Softshadows wie in Riddick). Große Mengen an Instanzen (Objekte, KI-gesteuerte Einheiten) fressen auch viel CPU-Power, besonders wenn noch eine Physikengine mit ins Spiel kommt (probier mal die Custom-Map Matto2 für Farcry aus, ruckelt stellenweise sehr stark mit Mainstream-CPUs, obwohl die Map optisch nicht so der Brüller ist; Problem sind die vielen Physikobjekte, die im Level verteilt sind).
Außerdem gibts noch sowas wie RAM-Limitierung, merkt man daran, dass während dem Spielen Nachladeruckler auftreten und von der Festplatte gelesen wird.
BlackBirdSR
2006-11-14, 01:10:08
Außerdem gibts noch sowas wie RAM-Limitierung, merkt man daran, dass während dem Spielen Nachladeruckler auftreten und von der Festplatte gelesen wird.
Oder daran, dass die CPU Daten nicht schnell genug bekommt ;)
Dann gibt es noch Cache-Limitierung, Latenz-Limitierung etc etc..
Nur in Extremfällen heißt CPU-Limitiert, dass die CPU am Limit arbeitet. Eher schon ist das gesamte System ein Engpass der die CPU nicht schnell genug beliefern kann. Schnellere CPUs lockern diesen durch schnellere Caches und geringere Latenz etwas.
Fein fein
Abet was hat es nun mit der Geometrie aufsich ?
Dazu hätt ich auch mal noch ne Frage.
Habe schon öfters gelesen das aufwändige Geometrie die CPU belastet.
Dabei werden doch die Verticies nur 1 mal erzeugt und dann von der Grafikkarte transformiert und verschoben und gerendert ?!
Warum ist es also so CPU belastend ?weil du in einer komplexen Geometrie ganz viele Vertices hast, von denen jeder 1mal erzeugt werden muß? Und dieses Erzeugen allein Sache des Prozessors ist?
Nimm als einfaches Beispiel an, du bewegst dich als Beobachter geradlinig durch eine statische 3D-Szene. Dann muß für jedes Frame zumindest die z-Koordinate jedes Vertex neu berechnet werden. Heißt: für jeden Vertex muß der Prozessor pro Frame eine solche Operation durchführen:
vertex.z += delta_z;
Der Aufwand wächst in diesem Beispiel einfach linear mit der Zahl der Vertices.
Ist die Szenerie dann auch noch dynamisch, d.h. sind Objekte enthalten die sich selbst bewegen oder verformen, und ist die Bewegung des Beobachters nicht mehr geradlinig, wird die Berechnung der Vertexpositionen noch deutlich komplizierter.
Die Grafikkarte kann dem Prozessor davon nichts abnehmen, die kommt erst im nächsten Schritt zum Zuge, wenn es an die Transformation der Vertices von 3D in 2D geht.
weil du in einer komplexen Geometrie ganz viele Vertices hast, von denen jeder 1mal erzeugt werden muß? Und dieses Erzeugen allein Sache des Prozessors ist?
Nimm als einfaches Beispiel an, du bewegst dich als Beobachter geradlinig durch eine statische 3D-Szene. Dann muß für jedes Frame zumindest die z-Koordinate jedes Vertex neu berechnet werden. Heißt: für jeden Vertex muß der Prozessor pro Frame eine solche Operation durchführen:
vertex.z += delta_z;
Der Aufwand wächst in diesem Beispiel einfach linear mit der Zahl der Vertices.
Ist die Szenerie dann auch noch dynamisch, d.h. sind Objekte enthalten die sich selbst bewegen oder verformen, und ist die Bewegung des Beobachters nicht mehr geradlinig, wird die Berechnung der Vertexpositionen noch deutlich komplizierter.
Die Grafikkarte kann dem Prozessor davon nichts abnehmen, die kommt erst im nächsten Schritt zum Zuge, wenn es an die Transformation der Vertices von 3D in 2D geht.
Dann hab ich das falsch begriffen ich dachte die Bewegung der Kamera(Beobachter) also die relative Verschiebung der Vertices übernimmt die Grafikkarte ???
Neomi
2006-11-14, 22:29:32
Ist die Szenerie dann auch noch dynamisch, d.h. sind Objekte enthalten die sich selbst bewegen oder verformen, und ist die Bewegung des Beobachters nicht mehr geradlinig, wird die Berechnung der Vertexpositionen noch deutlich komplizierter.
Die Grafikkarte kann dem Prozessor davon nichts abnehmen, die kommt erst im nächsten Schritt zum Zuge, wenn es an die Transformation der Vertices von 3D in 2D geht.
Du kannst gerne fragen, wenn du darüber keinen Überblick hast, aber bitte erzähle doch nicht so einen Quatsch. Vor allem nicht mit so einer Überzeugung, damit verwirrst du nur Laien.
Geometrie wird in Buffern gespeichert, die meist im Grafikspeicher liegen und nicht mehr von der CPU verändert werden, nachdem sie angelegt und gefüllt wurden. Sämtliche Transformationen (natürlich inklusive Objekt- und Kameraposition) werden auf der Grafikkarte durchgeführt.
tokugawa
2006-11-14, 22:44:25
weil du in einer komplexen Geometrie ganz viele Vertices hast, von denen jeder 1mal erzeugt werden muß? Und dieses Erzeugen allein Sache des Prozessors ist?
Nimm als einfaches Beispiel an, du bewegst dich als Beobachter geradlinig durch eine statische 3D-Szene. Dann muß für jedes Frame zumindest die z-Koordinate jedes Vertex neu berechnet werden. Heißt: für jeden Vertex muß der Prozessor pro Frame eine solche Operation durchführen:
vertex.z += delta_z;
Der Aufwand wächst in diesem Beispiel einfach linear mit der Zahl der Vertices.
Ist die Szenerie dann auch noch dynamisch, d.h. sind Objekte enthalten die sich selbst bewegen oder verformen, und ist die Bewegung des Beobachters nicht mehr geradlinig, wird die Berechnung der Vertexpositionen noch deutlich komplizierter.
Die Grafikkarte kann dem Prozessor davon nichts abnehmen, die kommt erst im nächsten Schritt zum Zuge, wenn es an die Transformation der Vertices von 3D in 2D geht.
In jeder Einführungs-Lehrveranstaltung für Computergrafik wärst du mit diesem Absatz schon negativ...
Geometrie wird in Buffern gespeichert, die meist im Grafikspeicher liegen und nicht mehr von der CPU verändert werden, nachdem sie angelegt und gefüllt wurden. Sämtliche Transformationen (natürlich inklusive Objekt- und Kameraposition) werden auf der Grafikkarte durchgeführt.
Man sollte hinzusagen, dass dies erst auf Grafikkarten ab der GeForce (Einführung von T&L) gilt. Voodoo5 & Co. haben noch keinen Vertex-Buffer, daher muss die Geometrie permanent neu über den Bus gepustet werden => fieser Engpass.
MfG,
Raff
haifisch1896
2006-11-14, 23:51:50
Zählt das auch für die Kyro oder hatte die einen Vertex-Buffer?
Neomi
2006-11-15, 02:21:29
Man sollte hinzusagen, dass dies erst auf Grafikkarten ab der GeForce (Einführung von T&L) gilt. Voodoo5 & Co. haben noch keinen Vertex-Buffer, daher muss die Geometrie permanent neu über den Bus gepustet werden => fieser Engpass.
Zwar durchaus richtig, aber eigentlich keiner Erwähnung mehr wert. Solche Karten sind nur noch für Historiker interessant. Support für Hardware unterhalb von Shadermodel 2 kann man sich in der Entwicklung inzwischen auch sparen, es ist den Extraaufwand einfach nicht mehr wert.
Zählt das auch für die Kyro oder hatte die einen Vertex-Buffer?
Nein, die Kyro muß ohne T&L auskommen und deshalb alle Vertices von der CPU transformieren lassen.
Heißt: für jeden Vertex muß der Prozessor pro Frame eine solche Operation durchführen:
Was ein Schwachsinn. Sämtliche Transformationen (Kamera-Translation, Kamera-Rotation, perspektivische Projektion, Scherung, Skalierung und was dir sonst noch einfällt) können in einer 4x4 Matrix zusammen ausgedrückt werden und werden dann komplett auf der GPU berechnet mit einer Matrix-Vektor-Multiplikation pro Eckpunkt.
Natürlich ist das dann linear von der Zeit, aber der Prozessor (ja da wirklich) kann vorher anhand einer hierarchischen Szenenstruktur alles was außerhalb der Sicht ist verwerfen und auch vieles andere was nicht sichtbar ist (und das ist eher O(log n) als O(n) wenn die Programmierer halbwegs fähig sind)
Was ein Schwachsinn. Sämtliche Transformationen (Kamera-Translation, Kamera-Rotation, perspektivische Projektion, Scherung, Skalierung und was dir sonst noch einfällt) können in einer 4x4 Matrix zusammen ausgedrückt werden und werden dann komplett auf der GPU berechnet mit einer Matrix-Vektor-Multiplikation pro Eckpunkt.
Natürlich ist das dann linear von der Zeit, aber der Prozessor (ja da wirklich) kann vorher anhand einer hierarchischen Szenenstruktur alles was außerhalb der Sicht ist verwerfen und auch vieles andere was nicht sichtbar ist (und das ist eher O(log n) als O(n) wenn die Programmierer halbwegs fähig sind)
Heisst also die Cpu ist nur fürs grobe Clipping zuständig (um mal wieder auf meine Frage zurückzukommen) und das mit der Geometrielast ist ein Mythos ?
tokugawa
2006-11-15, 19:32:38
Heisst also die Cpu ist nur fürs grobe Clipping zuständig (um mal wieder auf meine Frage zurückzukommen) und das mit der Geometrielast ist ein Mythos ?
Culling heißt das in dem Fall, nicht Clipping. Genauer: Visibility Culling.
Geometrielast ist kein Mythos, aber heutzutage eher seltener der Fall (falls du Vertex-Limitierung meinst).
Ich empfehle den Artikel "Graphics Pipeline Performance" im Buch GPU Gems, das erklärt sehr gut wie die einzelnen Teile der Grafikpipeline von CPU über Vertex-Processing-Einheiten über Pixel-Processing-Einheiten zusammenspielt, und wodurch in jeder Stufe dieser Pipeline ein Flaschenhals (d.h. eine "Limitierung") auftreten kann.
Culling heißt das in dem Fall, nicht Clipping. Genauer: Visibility Culling.
Geometrielast ist kein Mythos, aber heutzutage eher seltener der Fall (falls du Vertex-Limitierung meinst).
Ich empfehle den Artikel "Graphics Pipeline Performance" im Buch GPU Gems, das erklärt sehr gut wie die einzelnen Teile der Grafikpipeline von CPU über Vertex-Processing-Einheiten über Pixel-Processing-Einheiten zusammenspielt, und wodurch in jeder Stufe dieser Pipeline ein Flaschenhals (d.h. eine "Limitierung") auftreten kann.
Ja danke für die erste konkrete Antwort !
Piffan
2006-11-15, 21:16:37
Wahrscheinlich wird die Geometrielast höher, wenn mehr "Zerstörungsphysik" praktiziert wird, Stichwort Partikel- Systeme....Wenn ich das richtig geschnallt habe, ist aus diesem Grunde der Agaia- Chip ein Rohrkrepierer, die aufgepeppten Effekte verpuffen an den Limitierungen von DX10.
Es gibt ja den Ansatz, eine zusätzliche Grafikkarte mit Effektphysik zu beschäftigen. Hat dann diese Grafikkarte keine weiteren Render- Aufgaben mehr? Irgendwie riecht das dann nach massigen Datenschiebereien, Engpässe ahoi .
Rechenmonster wie die G80 sollten doch Effektphysik mit links erledigen und außerdem noch das Rendern leisten, so dass alles unter einem Dach abläuft und Busse entlastet werden.
Dann hab ich das falsch begriffen ich dachte die Bewegung der Kamera(Beobachter) also die relative Verschiebung der Vertices übernimmt die Grafikkarte ???hm, mir fällt gerade ein, unter OpenGL gibt es Funktionen wie glTranslate, glRotate oder gluLookAt, mit denen man das Koordinatensystem und/oder die Position des Beobachters verschieben kann. Nimmt man diese zur Realisierung des Kamerabewegung, kann es tatsächlich so sein, daß die Grafikkarte alle Berechnungen übernimmt. Allerdings sind diese Funktionen problematisch wenn man Transparenzeffekte nutzt (Blending): dann muß nämlich sichergestellt werden, daß die am weitesten hinten liegenden Objekte zuerst gerendert werden. Und das wird schwierig, wenn man nach diversen Manipulationen des Koordinatenursprungs und der Beobachterposition nicht mehr aus der z-Koordinate eines Vertex erkennen kann, ob der Vertex vorne oder hinten liegt.
Davon unbetroffen bleibt natürlich der Fall einer veränderlichen Geometrie, wo sich also nicht nur die Kameraposition verändert, sondern auch die relative Position der Vertices zueinander (Extrembeispiel: Partikel die wild durcheinander fliegen). Da muß dann trotzdem die CPU ran. Vertexshader werden dieser da zwar immer noch etwas Arbeit abnehmen können, aber wohl nur in begrenztem Maße.
Was ein Schwachsinn. Sämtliche Transformationen (Kamera-Translation, Kamera-Rotation, perspektivische Projektion, Scherung, Skalierung und was dir sonst noch einfällt) können in einer 4x4 Matrix zusammen ausgedrückt werden und werden dann komplett auf der GPU berechnet mit einer Matrix-Vektor-Multiplikation pro Eckpunkt.
Natürlich ist das dann linear von der Zeit, aber der Prozessor (ja da wirklich) kann vorher anhand einer hierarchischen Szenenstruktur alles was außerhalb der Sicht ist verwerfenwidersprichst du dir hier nicht? Wenn wir entsprechend deines ersten Absatzes annehmen, daß - um beim OpenGL-Fall zu bleiben - alle Kamerabewegungen mit gluLookAt & co. realisiert werden, würde der daraus resultierende Vorteil (der Prozessor muß nicht mehr ständig die Vertex-Positionen neu berechnen) nicht wieder verloren gehen, wenn der Prozessor stattdessen jeden Vertex auf Sichtbarkeit überprüfen muß? Was ja aufgrund der Realisierung der Kamerabewegung viel schwieriger ist wenn die Kamerar immer in (0,0,0) bleiben würde?
Ja danke für die erste konkrete Antwort !
Was war jetzt an meiner nicht konkret?
widersprichst du dir hier nicht?
Nein. Es wird nicht auf Vertexebene gearbeitet auf der CPU sondern in viel gröberen Maßstäben (grobes verwerfen anhand Octree/BSP/Quadtree/ABT dann ganzer Mesh etc.) und es wird auch nichts transformiert (mal abgesehen von animierten Modellen, aber das ist spätestens mit D3D10 auch Geschichte).
Eine Engine die statische Geometrie jedes Frame auf Vertexebene anfasst ist eine völlige Fehlkonstruktion.
Nimmt man diese zur Realisierung des Kamerabewegung, kann es tatsächlich so sein, daß die Grafikkarte alle Berechnungen übernimmt.
Das klingt so als wäre das der Außnahmefall. Das krasse Gegenteil ist der Fall. Die paar animierten Figuren in einem Level und Partikelsystem die sortiert werden müssen (man verwendet da aber auch gerne additives Blending, womit das sortieren wieder wegfällt) gehen tatsächlich durch die CPU, aber keinerlei statische Geometrie bei einer vernünftigen Engine.
Sind es jetzt eigentlich zwei Gäste oder nur einer? Auf jeden Fall haben beide gefährliches Halbwissen. Mehr statische Geometrie ist keine Belastung für die CPU, wenn die Anzahl der Objekte in der Szene nicht zunimmt.
Wenn man dann natürlich Physik damit berechnet und keine vereinfachten Modelle dafür verwendet sieht die Sache natürlich nochmal anders aus (Ach übrigens wird auch wenn ein statisches Objekt durch die Gegend fliegt nicht jeder Vertex angefasst, sondern nur die lokale Modelspace-Matrix verändert, nur damit da nicht wieder ein Missverständnis auftritt).
Heisst also die Cpu ist nur fürs grobe Clipping zuständig (um mal wieder auf meine Frage zurückzukommen) und das mit der Geometrielast ist ein Mythos ?
Ja und Jain.
Falls die Geometrie statisch ist bzw auf durch die GPU umgebaut werden kann, kostet das Zeichnen die CPU gar keine Leistung. Was aber massiv Leistung kostet, ist der Befehl selbst etwas zu zeichnen. Klingt für normale Menschen krank, ist aber so. X-D
Deswegen wird momentan viel Energie darin gesteckt, möglichst viel Geometrie in einen Buffer zu stecken, den man mit einem einzigen Befehl/Aufruf zeichnen lassen kann. Geometry Instancing geht auch genau in diese Richtung.
Es ist fast egal wieviel Geometrie es ist, nur sollte es mit möglichst wenig Aufrufen gerendert werden können.
Falls die Geometrie statisch ist bzw auf durch die GPU umgebaut werden kann, kostet das Zeichnen die CPU gar keine Leistung. Was aber massiv Leistung kostet, ist der Befehl selbst etwas zu zeichnen. Klingt für normale Menschen krank, ist aber so. X-D
Unter OpenGL und Direct3D unter Vista ist das aber lange nicht so ein Problem wie bei D3D und 2000/XP. Da hat MS damals einfach Müll gebaut beim Treiberinterface.
Es ist fast egal wieviel Geometrie es ist, nur sollte es mit möglichst wenig Aufrufen gerendert werden können.
Ack.
tokugawa
2006-11-16, 00:21:13
hm, mir fällt gerade ein, unter OpenGL gibt es Funktionen wie glTranslate, glRotate oder gluLookAt, mit denen man das Koordinatensystem und/oder die Position des Beobachters verschieben kann. Nimmt man diese zur Realisierung des Kamerabewegung, kann es tatsächlich so sein, daß die Grafikkarte alle Berechnungen übernimmt. Allerdings sind diese Funktionen problematisch wenn man Transparenzeffekte nutzt (Blending): dann muß nämlich sichergestellt werden, daß die am weitesten hinten liegenden Objekte zuerst gerendert werden. Und das wird schwierig, wenn man nach diversen Manipulationen des Koordinatenursprungs und der Beobachterposition nicht mehr aus der z-Koordinate eines Vertex erkennen kann, ob der Vertex vorne oder hinten liegt.
Schwierig? Sortieren ist das älteste Informatik-Problem überhaupt, und Depth-Sorting (egal ob - je nach gewünschtem Effekt - front-to-back oder back-to-front) ist ziemlich üblich. Im Prinzip reicht's einfach den Abstand zum Augpunkt zu berechnen, und zu hoffen dass es keine konkave transparente Geometrie gibt, die Cross-Overlapping erzeugt (wo das Sortieren schwer wird).
Back-to-front für Blending, und Front-to-Back falls man Early-Z-artige Optimierungen ausnutzen will (und kein Blending hat).
glTranslate, glRotate, usw, komponieren auch nur einfach eine 4x4 Matrix. Konkret multiplizieren sie einfach eine Translations-, Rotations- usw. -Matrix zur aktuellen hinzu.
Die Transformation der Vertizes selbst, mit hilfe dieser finalen Modelview und Projection Matrix übernimmt die Grafikkarte: dies geschieht nämlich genau im Vertexshader (ist ja dessen Aufgabe).
Davon unbetroffen bleibt natürlich der Fall einer veränderlichen Geometrie, wo sich also nicht nur die Kameraposition verändert, sondern auch die relative Position der Vertices zueinander (Extrembeispiel: Partikel die wild durcheinander fliegen). Da muß dann trotzdem die CPU ran.
Naja, jedes Partikel kann man als einzelne starre Geometrie (2 Dreiecke, also 1 Viereck) modellieren, dann hast überhaupt keine "veränderliche" Geometrie mehr.
Dadurch erhöhst du natürlich die Anzahl der Draw-Calls, was dann eine API-Limitierung verursacht (die zur CPU-Limitierung gehört). Hat aber nichts mit "veränderlicher" Geometrie zu tun.
Trotzdem sind Partikel in der Regel extrem Fillrate-limitiert. Mal abgesehen davon dass es mittlerweile mit Geometry Instancing eine Möglichkeit gibt, diese Drawcall-Limitierung zu sanieren.
Vertexshader werden dieser da zwar immer noch etwas Arbeit abnehmen können, aber wohl nur in begrenztem Maße.
In meiner Partikelsystem-Implementation macht fast alles der Vertexshader...
Ich glaube du solltest dir nochmal anschauen was ein Modellkoordinatensystem ist (auch Objektkoordinatensystem genannt), wie man davon ins Kamerakoordinatensystem kommt, und weiters in das Projektionskoordinatensystem (Post-Perspective Clip Space). Also im Prinzip die Transformationspipeline. Dann siehst du dass das einzige mal wo wirklich "veränderliche" Geometrie ist, nur dann ist wenn sich von einem Objekt die Vertizes _relativ_ zueinander ändern (nicht wenn sich einfach nur das ganze Objekt selbst bewegt).
Und selbst bei solcher "veränderlicher" Geometrie (die etwa bei Animation auftritt) kann man mittels Vertexshader eigentlich zu 99% die Gesamtarbeit übernehmen.
widersprichst du dir hier nicht? Wenn wir entsprechend deines ersten Absatzes annehmen, daß - um beim OpenGL-Fall zu bleiben - alle Kamerabewegungen mit gluLookAt & co. realisiert werden, würde der daraus resultierende Vorteil (der Prozessor muß nicht mehr ständig die Vertex-Positionen neu berechnen) nicht wieder verloren gehen, wenn der Prozessor stattdessen jeden Vertex auf Sichtbarkeit überprüfen muß? Was ja aufgrund der Realisierung der Kamerabewegung viel schwieriger ist wenn die Kamerar immer in (0,0,0) bleiben würde?
Nicht per Vertex. Per Vertex wäre es CPU-Overkill.
Außerdem steht bei Coda das kleine Wörtchen "hierarchisch". D.h., die Szene wird sowieso hierachisch in einer Bounding-Volume-Hierarchie gespeichert. D.h. man kann große Teile der Szene früh als "nicht sichtbar" verwerfen, ohne die detaillierteren Teile einzeln zu testen.
In der Regel funktioniert Culling bis auf Objekt-Ebene, je nach Spatial Hierarchy aber auch bis auf Polygonebene.
Ja und Jain.
Falls die Geometrie statisch ist bzw auf durch die GPU umgebaut werden kann, kostet das Zeichnen die CPU gar keine Leistung. Was aber massiv Leistung kostet, ist der Befehl selbst etwas zu zeichnen. Klingt für normale Menschen krank, ist aber so. X-D
Deswegen wird momentan viel Energie darin gesteckt, möglichst viel Geometrie in einen Buffer zu stecken, den man mit einem einzigen Befehl/Aufruf zeichnen lassen kann. Geometry Instancing geht auch genau in diese Richtung.
Es ist fast egal wieviel Geometrie es ist, nur sollte es mit möglichst wenig Aufrufen gerendert werden können.
Wobei man hier auch erwähnen muß dass dies eher ein DX9-Problem ist, und OpenGL und Direct3D10 dieses Problem weit weniger haben.
Und unter DX9 ist es (laut GPU-Optimierungs-Dokumenten von ATI und NVIDIA) auch nicht wirklich das der Drawcall an sich, sondern es liegt daran dass State-Changes "gesammelt" werden und erst beim Drawcall das State-Change-Delta auf einmal "deferred" angewandt wird - was natürlich viel kosten kann. Ich hab das aber nicht näher überprüft, da das Ergebnis gleich bleibt: sparen mit Drawcalls unter DirectX9.
Was war jetzt an meiner nicht konkret?
Ich glaube da liegt jetzt ein Gästemissverständnis vor, meine Frage war die aus dem zweiten Post konkret wollt ich wissen warum immer gesagt wird das
die CPU ne hohe Last durch Geometriedingens halt hat. Du hast zwar geschrieben das alles auf der Graka abläuft aber der Aussage hast du nicht widersprochen.OK vielleicht wars ja auch rethorisch gemeint und ich sollt mir meinen Teil denken ?
Zitat von Gast
Falls die Geometrie statisch ist bzw auf durch die GPU umgebaut werden kann, kostet das Zeichnen die CPU gar keine Leistung. Was aber massiv Leistung kostet, ist der Befehl selbst etwas zu zeichnen. Klingt für normale Menschen krank, ist aber so.
Unter OpenGL und Direct3D unter Vista ist das aber lange nicht so ein Problem wie bei D3D und 2000/XP. Da hat MS damals einfach Müll gebaut beim Treiberinterface.
Zitat von Gast
Es ist fast egal wieviel Geometrie es ist, nur sollte es mit möglichst wenig Aufrufen gerendert werden können.
Ack.
Heißt das jetzt das die reinen Api Aufrufe den Flaschenhals darstellen weil sie von der CPU in Grafikartensprache gewandelt werden müssen ?
Und mit Dx10 die Gpu zum Cpuversteher wird ?
tokugawa
2006-11-16, 00:35:38
Heißt das jetzt das die reinen Api Aufrufe den Flaschenhals darstellen weil sie von der CPU in Grafikartensprache gewandelt werden müssen ?
Und mit Dx10 die Gpu zum Cpuversteher wird ?
Also, API-Aufrufe sind nur dann ein Flaschenhals, wenn sie ein Flaschenhals sind, sprich: all diese "Limitierungen" sind nur dann Limitierungen, wenn die spezielle Szene, die man rendert, oder der Teil der Szene, gerade diese Charakteristik hat. Das kann selbst innerhalb eines Spiels, oder innerhalb desselben Frames anders sein.
D.h. man kann nicht sagen "diese reinen API Aufrufe sind Flaschenhälse", nein.
Flaschenhals wird der API-Aufruf durch verschiedene Faktoren:
- Die Grafikkarte hat einen Command Buffer, wo Befehle reingeschoben werden, und diese asynchron zur CPU abgearbeitet werden. Wenn die CPU nicht schnell genug liefern kann oder zu komplexe API-Aufrufe gehäuft vorkommen, dann wird dieser Command Buffer zu schnell abgearbeitet, und die GPU muß warten
- Ein API-Aufruf kann einfach nur teuer sein, bzw. besteht selbst aus mehreren Operationen der GPU, und muß erst in diese Teil-Operationen aufgebrochen werden.
- Ein API-Aufruf kann so viel "Management-Zeugs" zusätzlich machen, dass einfach ein Riesenoverhead entsteht.
Im Übrigen kann eine Limitierung auch dadurch entstehen, dass ein anderer Teil der Pipeline einfach "schneller" ist. Ist also nicht immer deswegen weil etwas "langsam" ist (obwohl, relativ zu den anderen Teilen der Pipeline ist der Flaschenhals natürlich "langsamer").
Aber das schwierige ist ja, dass Limitierungen selbst in derselben Szene, in demselbem variieren können, und man daher fast nie pauschal sagen kann "Spiel X ist GPU oder CPU-limitiert", sondern nur tendenziell.
API-Limitierung ist kein Problem der GPU, sondern - wie der Name schon sagt - eher ein Problem des API-Designs, also im Prinzip ein Softwareproblem, kein Hardwareproblem.
^^yo thx habs gelesen und denk drüber nach irgendwie spür ich schon wie die nexten Fragen hochkommen *würg aber heute nicht mehr ;-)
Schwierig? Sortieren ist das älteste Informatik-Problem überhaupt, und Depth-Sorting (egal ob - je nach gewünschtem Effekt - front-to-back oder back-to-front) ist ziemlich üblich. Im Prinzip reicht's einfach den Abstand zum Augpunkt zu berechnen, und zu hoffen dass es keine konkave transparente Geometrie gibt, die Cross-Overlapping erzeugt (wo das Sortieren schwer wird).aber muß diese Berechnung nicht für jeden Vertex einzeln durchgeführt werden, was den Rechenaufwand für die CPU dann wieder linear mit der Zahl der Vertices skalieren läßt?
Naja, jedes Partikel kann man als einzelne starre Geometrie (2 Dreiecke, also 1 Viereck) modellieren, dann hast überhaupt keine "veränderliche" Geometrie mehr.ich sprach von der Bewegung der Partikel relativ zueinander.
Ich nehme an, du willst mir sagen, daß man diese durch Manipulationen des Koordinatensystems realisieren kann? Diese muß man dann aber für jedes Partikel einzeln durchführen, d.h. z.B. für jedes Partikel einen neuen Koordinatenursprung berechnen. Das ist genauso rechenaufwändig als wenn man die 4*4-Matrix in Ruhe läßt und stattdessen die Position jedes Partikels berechnet.
Noch dazu ist es zumindest unter OpenGL so, daß du für die Ursprungsneuberechnung pro Partikel einen eigenen glBegin(GL_QUADS)-glEnd()-Block benötigst, da du innerhalb eines Blocks keine glTranslates und glRotates machen kannst. Die Positionsneuberechnungs-Strategie dagegen erlaubt, alle Partikel in einen einzigen glBegin(GL_QUADS)-glEnd()-Block zu packen, was erfahrungsgemäß eine bessere Performance liefert.
In meiner Partikelsystem-Implementation macht fast alles der Vertexshader...warte mal... im 3DMark2001 gibt es doch diesen Vertexshader-Test, wo man ganz viele durcheinander laufende und sich gegenseitig erschießende Max Paynes sieht. Wird deren Bewegung durch den Vertexshader realisiert? Das war mir bislang gar nicht klar gewesen. Es wird aber doch wohl so sein, daß ein Vertexshader-Programm für alle Objekte immer nur genau die gleiche Bewegung realisiert, die Max Paynes im 3DMark bewegen sich ja auch alle genau gleich, nur mit unterschiedlichen Startpositionen. Wenn sich aber in einer Partikel-Engine jedes Partikel eigenständig bewegen soll, müßte man für jedes Partikel ein eigenes Shaderprogramm laden, was doch sicherlich auch wieder aufwändig für die CPU wäre.
Dann siehst du dass das einzige mal wo wirklich "veränderliche" Geometrie ist, nur dann ist wenn sich von einem Objekt die Vertizes _relativ_ zueinander ändernhabe ich von etwas anderem gesprochen?
Nicht per Vertex. Per Vertex wäre es CPU-Overkill.
Außerdem steht bei Coda das kleine Wörtchen "hierarchisch". D.h., die Szene wird sowieso hierachisch in einer Bounding-Volume-Hierarchie gespeichert. D.h. man kann große Teile der Szene früh als "nicht sichtbar" verwerfen, ohne die detaillierteren Teile einzeln zu testen.ist das diese Geschichte mit den Szenengraphen?
Das klingt so als wäre das der Außnahmefall. Das krasse Gegenteil ist der Fall. Die paar animierten Figuren in einem Level und Partikelsystem die sortiert werden müssen (man verwendet da aber auch gerne additives Blending, womit das sortieren wieder wegfällt) gehen tatsächlich durch die CPU, aber keinerlei statische Geometrie bei einer vernünftigen Engine.
Sind es jetzt eigentlich zwei Gäste oder nur einer? Auf jeden Fall haben beide gefährliches Halbwissen.man könnte ja jetzt den Eindruck gewinnen, daß du hingegen ein sehr fundiertes Fachwissen in dieser Thematik hast. Daß dem aber offenbar nicht so, zeigt sich daran, daß du nicht weißt, ob und inwiefern das Rendern in eine Textur und die Zweckentfremdung von Shadern zu mathematischen Berechnungen mit einem Rückkanal von der Grafikkarte zur CPU zusammenhängen (zu erkennen an der nicht vorhandenen Antwort auf die Frage im Nachbarthread http://www.forum-3dcenter.org/vbulletin/showthread.php?t=331170&page=2, #23).
Was laberst du für Blödsinn? Ich muss doch nicht jeden Thread lesen in dem ich mal geantwortet hab?
Crushinator
2006-11-20, 10:21:48
Was laberst du für Blödsinn? Ich muss doch nicht jeden Thread lesen in dem ich mal geantwortet hab?
Das muß doch wirklich nicht sein. Besänftige bitte Deinen Tonfall!
Diskussionen über Verwarnungen sind bei Bedarf in einem ggf. zu erstellenden Thread im "Diskussionen zu moderativen Entscheidungen - Forum" zu führen bzw. per PN mit dem jeweiligen Moderator, denn hier wären sie OT. Siehe dazu auch: Regeln und Richtlinien für die Moderation
tokugawa
2006-11-20, 14:37:33
aber muß diese Berechnung nicht für jeden Vertex einzeln durchgeführt werden, was den Rechenaufwand für die CPU dann wieder linear mit der Zahl der Vertices skalieren läßt?
Das kannst du auch grober machen, pro Objekt, und nicht pro Vertex. Wenn du keine transparenten Objekte hast die Crossoverlapping ermöglichen, dann reicht das vollkommen.
ich sprach von der Bewegung der Partikel relativ zueinander.
Ich nehme an, du willst mir sagen, daß man diese durch Manipulationen des Koordinatensystems realisieren kann? Diese muß man dann aber für jedes Partikel einzeln durchführen, d.h. z.B. für jedes Partikel einen neuen Koordinatenursprung berechnen. Das ist genauso rechenaufwändig als wenn man die 4*4-Matrix in Ruhe läßt und stattdessen die Position jedes Partikels berechnet.
Was insgesamt nicht besonders rechenaufwändig ist. Du mußt für diese einzelnen Partikel sowieso die Matrix beeinflussen, um sie an der View auszurichten (Partikel sind Quads die einfach immer so ausgerichtet sind, dass die Viewplane-parallel sind).
Eine solche Matrix aufzustellen ist billig. Und die Transformation selbst geschieht im Vertexshader. Noch mehr Performance könnte man durch Geometry Instancing und/oder Point-Sprites gewinnen. Meiner Erfahrung und Messungen nach ist bei (transparenten) Partikelsystemen der Flaschenhals sehr oft die reine Fillrate (oft sogar der ROP-Teil der Pixel-Pipeline bei Alphablending).
Noch dazu ist es zumindest unter OpenGL so, daß du für die Ursprungsneuberechnung pro Partikel einen eigenen glBegin(GL_QUADS)-glEnd()-Block benötigst, da du innerhalb eines Blocks keine glTranslates und glRotates machen kannst. Die Positionsneuberechnungs-Strategie dagegen erlaubt, alle Partikel in einen einzigen glBegin(GL_QUADS)-glEnd()-Block zu packen, was erfahrungsgemäß eine bessere Performance liefert.
Das nennt sich Batching, ja. Unter OpenGL ist dieses Problem aber nicht so schlimm wie unter DirectX. Außerdem ist das glBegin/glEnd der Immediate-Mode - für Performance würdest du sowieso VBOs (Vertexbuffer Objects) verwenden. Da einzelne Partikel ja sogar statisch sind, würden sogar Display-Lists ausreichen.
warte mal... im 3DMark2001 gibt es doch diesen Vertexshader-Test, wo man ganz viele durcheinander laufende und sich gegenseitig erschießende Max Paynes sieht. Wird deren Bewegung durch den Vertexshader realisiert? Das war mir bislang gar nicht klar gewesen. Es wird aber doch wohl so sein, daß ein Vertexshader-Programm für alle Objekte immer nur genau die gleiche Bewegung realisiert, die Max Paynes im 3DMark bewegen sich ja auch alle genau gleich, nur mit unterschiedlichen Startpositionen. Wenn sich aber in einer Partikel-Engine jedes Partikel eigenständig bewegen soll, müßte man für jedes Partikel ein eigenes Shaderprogramm laden, was doch sicherlich auch wieder aufwändig für die CPU wäre.
Nein, das Shaderprogramm wär gleich, nur die Parameter (also Inputs) für das Programm wäre anders.
ist das diese Geschichte mit den Szenengraphen?
Ja, auch. Obwohl ein Szenegraph die Szene eher logisch unterteilt (z.B. "Auto hat 4 Räder, die 4 Räder sind also Child-Nodes vom Auto") als räumlich. Oft ist aber räumlich und logisch eh dasselbe.
Jedenfalls geht's in diesem Fall um die räumliche Hierarchie (spatial Hierarchy), welche etwa durch kd-Trees, Octrees, Binary Space Partitioning (BSP) Trees, und ähnliches realisiert werden kann.
Eigentlich Standard-CG-Zeugs.
man könnte ja jetzt den Eindruck gewinnen, daß du hingegen ein sehr fundiertes Fachwissen in dieser Thematik hast. Daß dem aber offenbar nicht so, zeigt sich daran, daß du nicht weißt, ob und inwiefern das Rendern in eine Textur und die Zweckentfremdung von Shadern zu mathematischen Berechnungen mit einem Rückkanal von der Grafikkarte zur CPU zusammenhängen (zu erkennen an der nicht vorhandenen Antwort auf die Frage im Nachbarthread http://www.forum-3dcenter.org/vbulletin/showthread.php?t=331170&page=2, #23).
Ich kann Coda voll verstehen: wieso sollte das Nichtbeantworten ein "Beweis" sein, dass er es nicht weiß? Ziemlicher Trugschluß. Könnte ja auch daran liegen dass man nicht jeden Thread und jedes Posting verfolgen kann - geht mir ja genauso.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.