Grafik Benchmarks schreiben
-
Mahlzeit Leute,
braucht man eigentlich übermenschliche Kräfte um Benchmarks zu programmieren ?
Ich habe mittlerweile mehrmals (versucht) sowas zu programmieren (Primitive Programme, die die Grafikkarte mit Tonnen von Polys bombardieren und die Frame-Rate messen
) aber nie konnte ich zum Schluss verwertbare Ergebnisse erzielen. Wie schreibe ich eine (OpenGL) Anwendung so, das die Leistung möglichst stark an der Grafikkarte und nicht am restlichen System hängt ?
Ist das überhaupt möglich ? Angenommen ich rendere sehr feine Geometrie - "Un-Gecullte" Models mit jeweils um die 50.000 Polys - Was bei Benchmarks ja durchaus noch Sinn machen könnte. Braucht man dann nicht ohnehin erstmal ein superschnelles System, das die Datenmengen zur Karte schaufeln kann ?
Wie machen das die Professionellen Benchmarks ? (3D Mark, Aquamark) Klar, da gibts Mindestanforderungen. Aber wenn man sich mal die Ergebnisse einer identischen Graka unter verschiedenen Systemen ansieht, merkt man das die sich nur wenig unterscheiden. Um es auf den Punkt zu bringen: Wie verschaffe ich meiner Grafikkarte möglichst viel Arbeit, ohne das restliche System zu sehr zu belasten ?
-
Cpp_Junky schrieb:
Braucht man dann nicht ohnehin erstmal ein superschnelles System, das die Datenmengen zur Karte schaufeln kann ?
Sorry - willst du die AGP Bandbreite testen, oder die Grafikkarte?
Wenn die GFX Karte, dann wuerde ich mal vorschlagen, du nimmst VRAM, und speicherst deine Geometrie dort. Bei NV immer noch mit VAR, die VBO implementation bei NV ist immer noch nicht so wirklich toll. Bei ATI kannst du ruhig VBO nehmen. So hast du schonmal den Flaschenhals los. Dann tun die 50k Triangles oder so auch nicht mehr wirklich weh.Ich schlage vor, du benchst erstmal die verschiedenen Rendermodi -> Interleaved, Locked ( Bringt bei NV irgendwie nicht wirklich viel ), VAR / VBO. Dann weist du wie du das System entlastest
-
Öhm, wie krieg ich denn die Model-Daten ins VRAM ?
Über Display-Listen ? (Programmier in OpenGL)
-
Cpp_Junky schrieb:
Öhm, wie krieg ich denn die Model-Daten ins VRAM ?
Über Display-Listen ? (Programmier in OpenGL)Wie ich vorhin gesagt habe - such mal auf der OpenGL.org die ossi Seite ( Extension Registry )
Da findest du VAR ( NV Vertex Array Range ), VBO ( Vertex Buffer Object ) - die baust du ein, und schon hast du ein XFaches der Geschwindigkeit, die du vorher hattest. Und mal ehrlich - was sind 50k Triangles? Normaler durchschnitt, den jede neuere Karte leicht herbringt, mit genug Reserven.Wenn du willst suche ich mal mein altes Framework - da habe ich auf jeden Fall noch VBO drin, und glaube sogar VAR.
P.S. Display Listen sind nur was fuer statische Geometrie, aber immerhin schneller, als wenn du jedes mal Zufuss den ganzen Kram Richtung Grafikkarte schiebst
-
Wenn du das Geld für ein paar unterschiedliche Systeme und gute Connections zu den GraKa Herstellern "übermenschliche Kräfte" nennst.
Bye, TGGC \-/
-
SnorreDev schrieb:
Wenn du willst suche ich mal mein altes Framework - da habe ich auf jeden Fall noch VBO drin, und glaube sogar VAR.
P.S. Display Listen sind nur was fuer statische Geometrie, aber immerhin schneller, als wenn du jedes mal Zufuss den ganzen Kram Richtung Grafikkarte schiebst
Sind nun VBOs oder VARs neuer und zukunftssicherer? An deinem Framework, oder zumindest einem Teil davon, wäre übrigens auch ich sehr interessiert
Und hab ich richtig verstanden, was ich irgendwo mal gelesen habe:- Um VBOs nutzen zu können, muss man erstmal ein ganz normales Vertexarray haben
- Man könnte theoretisch auch die Vertexarrayaufrufe zusammen mit ModelViewMatrixänderungen in ne Displaylist packen und nochmal einen Performancegewinn bekommen?
@Topic: Vielleicht wären für so einen Benchmark auch das verwenden anspruchsvoller Shader nicht schlecht. Da kannste gleich noch rausfinden wie gut die GRaKa-Treiber sind
-
spl@t schrieb:
Sind nun VBOs oder VARs neuer und zukunftssicherer?
VAR ist die NVidia Extension. Also sowieso nur Herstellerspezifisch.
VBO ist seit GL 1.4 keine Extension mehr, sondern fester Bestandteil von OpenGL.- Um VBOs nutzen zu können, muss man erstmal ein ganz normales Vertexarray haben
Du kannst direkt on the Fly in den VBO Ram schreiben. Der VBO selbst ist das VertexArray im VRAM.
- Man könnte theoretisch auch die Vertexarrayaufrufe zusammen mit ModelViewMatrixänderungen in ne Displaylist packen und nochmal einen Performancegewinn bekommen?
Nie ausprobiert. Glaube aber eher nicht.
An deinem Framework, oder zumindest einem Teil davon, wäre übrigens auch ich sehr interessiert
http://www.c-plusplus.net/forum/viewtopic.php?t=80764
<<
Wenn du mir bei diesem Problem helfen kannst, ueberlasse ich dir gern den Code, der ist da naemlich drauf! Er steht unter LGPL, wurde aber nie wirklich veroeffentlicht, da ich keine Zeit zur weiterentwicklung hatte, und das Framework nur Grundlegende Sachen, wie Console mit Lua Support, VBO beherrscht.
-
Tja, hab leider wirklich keine Ahnung von Linux und so weiter...
Hab aber trotzdem was gepostet (was nicht gut aussieht, glaub ich
)
-
SnorreDev schrieb:
Und mal ehrlich - was sind 50k Triangles? Normaler durchschnitt, den jede neuere Karte leicht herbringt, mit genug Reserven.
Wenn du willst suche ich mal mein altes Framework - da habe ich auf jeden Fall noch VBO drin, und glaube sogar VAR.
P.S. Display Listen sind nur was fuer statische Geometrie, aber immerhin schneller, als wenn du jedes mal Zufuss den ganzen Kram Richtung Grafikkarte schiebst
das was die rechenleistung aus macht in modernen grafiken sind nicht die polys sondern die hardware-seitigen sachen wie schatten reflexionen und und und das poly ansich ist null rechenleitung
-
bsunisol schrieb:
das was die rechenleistung aus macht in modernen grafiken sind nicht die polys sondern die hardware-seitigen sachen wie schatten reflexionen und und und das poly ansich ist null rechenleitung
Hast du eine Ahnung. Wozu, denkst du, verwenden die Next Generation Spiele Normal Maps?
