Wieviele Dreiecke schaffen aktuelle Grafikkarten je Sekunde?

[Robbson]

Hallo mal wieder!

Früher wurde zu den Grafikkarten immer angegeben, wieviele Dreiecke sie pro Sekunde schaffen... z.B. bei der 3Dfx Voodoo3 3000: 7 million triangles/second.
Heute dürften das ja ein paar mehr sein... Darum kam ich kürzlich auf die Idee, es einfach 'mal selbst auszuprobieren bzw. 'mal zu gucken inwiefern das überhaupt so geht, anstatt immer nur theoretisch d'rüber zu labern *gg.

Sprich, ich habe mit Direct3D eine kleine poblige Anfänger-Testapplikation geschrieben... Hatte vor Jahren nur mit OpenGL zu tun, aber man fängt ja klein an. ;-)
So und in dieser app habe ich nun einen Würfel konstruiert mit den üblichen minimalen 12 Dreiecken, um alle 6 Seiten darzustellen (in einem VertexBuffer).
Dann vervielfältige ich den Würfel beim Rendern (also mehrfach nebeneinander den gleichen VertexBuffer einzeichnen), sodaß ein größerer Quader entsteht,mit den Maßen 30x20x10, also 6000 Würfel auf dem Bildschirm!
Das bedeutet, es müßten pro Frame 6000x12=72000 Dreiecke gerendert werden.
Leider kann mir das kein Programm, wie "3DAnalyzer" von Tommti Systems, bestätigen, denn die zählen wohl "ein paar" Dreiecke zu viel.

Na egal, die Framerate liegt dann jedenfalls bei ca. 34 Frames/Sekunde.
D.h., ich komme auf 34x72000=2.448.000 Dreiecke/Sekunde... Und das auf meinem System (6800GT, Athlon64 "3600+")... ist zwar nicht mehr das Neueste, aber irgendwie sind das am Ende nicht einmal 2.5 Mio Dreiecke pro Sekunde... kann ja irgendwie nicht sein. Ich benutze übrigens den Wireframe-Modus, dann sieht man die Dinger auch ordentlich.

Sooo... natürlich ist das auch eine Optimierungssache, doch ich habe mich an die üblichen Microsoftvorgaben gehalten... und bis auf die Wireframe-Darstellung ist nix weiter zu sehen... keine Texturen, keine Beleuchtung, nix!
Selbst wenn ich mehrere Cubes in einen einzigen Vertexbuffer packe (welch' Speicherverschwendung), ergibt sich kein Performance-Vorteil. Auch ist das D3D Device so eingerichtet, daß es Hardware Vertex Berechnungen nutzt.
Auch die Kompilierung im Releasemode bringt keinen Zuwachs an Speed. Naja und AA, AF, etc. ist natürlich deaktiviert.

Irgendwo muß hier doch ein gewaltiger Denkfehler sein, denn mickrige 2.5 Mio Dreiecke pro Sekunde?? Die kann ich ja fast an der Hand abzählen. ;-)
Das müßten doch mindestens 5x soviele sein... und ich kann mir keine "nicht vorhandene Optimierung" vorstellen, die um ein fünftel die Speed bremst....

In Rätseln...
Robbson.

[Gast]

das theoretische maximum lässt sich recht einfach ausrechnen:

taktfrequenz*anz-VS/4

für eine 7900GTX also ~1,3Mrd. vertices/sekunde

praktisch liegt es natürlich einiges darunter.

das höchste was ich bei mir real gemessen habe war farcry mit aktivem GI und hoher sichtweite ~30Mio/s.

das ganze war allerdings ziemlich cpu-limitiert und lediglich mit einem P4 2,4GHz, heute mit dem gleichgetakteten P-M dürften es um einiges mehr sein.

wenn es dir um theoretische werte geht könnten dir auch die entsprechenden tests in den 3dmarks helfen.

[Robbson]

das theoretische maximum lässt sich recht einfach ausrechnen:

taktfrequenz*anz-VS/4

für eine 7900GTX also ~1,3Mrd. vertices/sekunde

praktisch liegt es natürlich einiges darunter.

das höchste was ich bei mir real gemessen habe war farcry mit aktivem GI und hoher sichtweite ~30Mio/s.

das ganze war allerdings ziemlich cpu-limitiert und lediglich mit einem P4 2,4GHz, heute mit dem gleichgetakteten P-M dürften es um einiges mehr sein.

wenn es dir um theoretische werte geht könnten dir auch die entsprechenden tests in den 3dmarks helfen.

Danke für die Infos! 30 Mio.... das klingt doch schonmal ganz vernünftig.
Dann muß mir bei der Entwicklung meiner Mini-Applikation ja ein riesiger Fehler unterlaufen sein... den ich aber beim besten Willen nicht finden kann... komisch... da muß es wohl noch irgendwo ein "Turbo-Flag" geben.

Grüße,
Robbson.

[Gast]

ich hab mal gehört dass wireframe auf non-quadro-karten extrem langsam läuft, mit quadro-treiber teilweise 5x schneller.

weiters sind die angegebenen werte eigentlich immer vertices/s und nicht zwangsläufig polys/s.

[Coda]

Man wird Vertexdurchsatz nur messen können wenn man auch VertexShader-limitiert ist. Mit 12 Dreiecken pro Frame hast du aber den absoluten Anti-Fall konstruiert.

Ergo: Nimm 100.000 Dreiecke/Frame (am besten einen optimierten indizierten Mesh) mit geringer Framebuffer-Auflösung und mess nochmal.

[Robbson]

@Gast
Das spielt anscheinend keine Rolle... auch der Standart Gouroud Shader oder Flat Shader ist nicht schneller.
Was Du meinst, sind die AA Wireframes, die meist nur mit den Workstation Treibern funzen... jedenfalls in den 3D Modellern.

@Coda:
12 Dreiecke pro Frame ? ;-)
Naja, ein riesiges großen Mesh könnte man natürlich auch noch versuchen einzuladen... aber so kann ich die Masse an Dreiecken optimal konfigurieren und die eigentlichen Cube-Daten sind effizienterweise nur ein einziges Mal vorhanden. Ach ja und mein Frame ist gerade mal 800x600 Punkte groß.

Ich habe das Programm ja nicht wirklich zum "Messen" geschrieben, sondern weil es mich gerade interessiert, wieviele Dreiecke man "selbst" auf den Bildschirm bringen kann... sprich ohne 3DMark oder irgendwelche Games.
Und die Cubes als Primitive brauche ich demächst auch noch ;-)


Robbson.

[Xmas]

Hallo mal wieder!

Früher wurde zu den Grafikkarten immer angegeben, wieviele Dreiecke sie pro Sekunde schaffen... z.B. bei der 3Dfx Voodoo3 3000: 7 million triangles/second.
Die Angabe liegt ziemlich weit neben der Realität.

2.2 3D Performance
16-bits per pixel, 640x480
1 pixel gouraud, Z, unlit 1.8M tris/sec
5 pixel gouraud, Z, unlit 1.8M tris/sec
50 pixel gouraud, Z, unlit 1.4M tris/sec
1000 pixel gouraud, Z, unlit 70k tris/sec
50 pixel Z, blinear textured 1.0M tris/sec
50 pixel Z, trilinear mip-mapped 375K tris/sec
Das sind Zahlen direkt von 3dfx für Avenger (scheint mit 143MHz zu sein).

Sprich, ich habe mit Direct3D eine kleine poblige Anfänger-Testapplikation geschrieben... Hatte vor Jahren nur mit OpenGL zu tun, aber man fängt ja klein an. ;-)
So und in dieser app habe ich nun einen Würfel konstruiert mit den üblichen minimalen 12 Dreiecken, um alle 6 Seiten darzustellen (in einem VertexBuffer).
Dann vervielfältige ich den Würfel beim Rendern (also mehrfach nebeneinander den gleichen VertexBuffer einzeichnen), sodaß ein größerer Quader entsteht,mit den Maßen 30x20x10, also 6000 Würfel auf dem Bildschirm!
Das bedeutet, es müßten pro Frame 6000x12=72000 Dreiecke gerendert werden.
Wenn du kein Instancing verwendest, bist du hier mit Sicherheit Drawcall-limitiert. Verwende lieber ein Objekt mit viel mehr Dreiecken, dazu bitte Indexed Triangle Lists mit DrawIndexedPrimitive.

Ich benutze übrigens den Wireframe-Modus, dann sieht man die Dinger auch ordentlich.
Böse Falle. Wireframe ist um einiges langsamer. Nicht nur dass die Anzahl der Dreiecke um mindestens den Faktor 3 steigt, der Treiber muss auch noch die Index- und Vertexbuffer umbauen.


das theoretische maximum lässt sich recht einfach ausrechnen:

taktfrequenz*anz-VS/4

für eine 7900GTX also ~1,3Mrd. vertices/sekunde

praktisch liegt es natürlich einiges darunter.
Das ist allerdings nur das theoretische Maximum für Vertextransformationen. Mit Index Buffer und Vertex Cache kann man da theoretisch annähernd das Dreifache an Dreiecken rausholen.
Andererseits ist man natürlich schon lange vorher Setup-limitiert. Als Extrembeispiel Xenos: Bis zu 6 Mrd. transformierte Eckpunkte, aber "nur" 500 Mio. Dreiecke pro Sekunde im Setup.

[Coda]

StandartNein. Standard. Nach neuer und alter dt. Rechtschreibung sowie im Englischen auch.

12 Dreiecke pro Frame ? ;-)Entschuldige, hab nicht ganz richtig gelesen. Dann bist du eindeutig Drawcall-limitiert. 12 Triangles/Batch ist mindestens genauso böse wie 12 Triangles/Frame :tongue:

[Robbson]

Die Angabe liegt ziemlich weit neben der Realität.
...
Das sind Zahlen direkt von 3dfx für Avenger (scheint mit 143MHz zu sein).

Nun, das mag ja sein, aber Gouroud, usw. nutze ich hier ja nicht. Außerdem habe ich die Zahl von Guru3D... also einer renommierten Quelle. ;-)


Wenn du kein Instancing verwendest, bist du hier mit Sicherheit Drawcall-limitiert. Verwende lieber ein Objekt mit viel mehr Dreiecken, dazu bitte Indexed Triangle Lists mit DrawIndexedPrimitive.

Also zunächst einmal benutze ich indizierte Triangle Lists... damit blos kein Vertex zu viel mit drin steht, also auch DrawIndexedPrimitive.
Aber ich sehe ehrlich gesagt nicht wirklich den Sinn in einem größeren Vertexbuffer mit mehr Triangles, wenn (bis auf die Position) alle Vertices und Indices gleich sind. D.h. ich hätte irgendwo bspw. 100x die Datenstruktur des Cubes gespeichert... was für eine Verschwendung.
Testhalber habe ich 'mal eine ganze Reihe an cubes in einem VertexBuffer gespeichert (spart also ordentlich DrawCalls), bringt aber nix.


Böse Falle. Wireframe ist um einiges langsamer. Nicht nur dass die Anzahl der Dreiecke um mindestens den Faktor 3 steigt, der Treiber muss auch noch die Index- und Vertexbuffer umbauen.

Ich wollte einen fairen Test, sprich es müssen auch alle Dreiecke zu sehen sein, die ich rendere, sodaß HDSR und Co umgehen kann.
Im Übrigend ist der StandarD Gouroud Shader schneller... keine Frage, kann aber auch nicht mehr als 6.000.000 Dreiecke/Sekunde 'rausholen.
Noch ein wenig mehr bringt das BackfaceCulling, doch so schalte ich ja selbst im Wireframe immer mehr Dreiecke aus... so komme ich ja sonst nie an die Grenzen des Möglichen.

Das Problem für meine spätere Anwendung wird sein, daß ich fast ausschließlich einfache Quader habe und davon Massen.

Robbson.

[Coda]

Du bist Drawcall-limitiert = Du verwendest zuviele Drawcalls, wieviel Dreiecke gerendert werden pro DrawIndexedPrimitive ist dabei völlig egal.

Das ist bei DX9 besonders böse wegen dem beschissenen Treibermodell (bis einschließlich XP, mit Vista wirds besser), deshalb gibts auch die Instancing-API.

[Robbson]

Nein. Standard. Nach neuer und alter dt. Rechtschreibung sowie im Englischen auch.

Yo, das weiß ich... kann ich mir nur blos nicht merken... den Fehler mache ich schon seit Jahren... ohne es je bemerkt zu haben... weshalb der Standar(t) auch 47x in meiner Diplomarbeit vorkommt. :-/
Aber keine Sorge, ich hätte auch nicht mit der neuen, neueren oder neuesten Rechtschreibung argumentiert. Das Ding mit t sitzt bei mir so fest wie die Unterscheidung zwischen links und rechts oder oben und unten.


Entschuldige, hab nicht ganz richtig gelesen. Dann bist du eindeutig Drawcall-limitiert. 12 Triangles/Batch ist mindestens genauso böse wie 12 Triangles/Frame :tongue:

Also auch hier wieder das Argument DrawCall... also ist mehr Performance nur durch Speicherverschwendung zu erreichen? Ich bin begeistert.

Robbson.

[Coda]

Also auch hier wieder das Argument DrawCall... also ist mehr Performance nur durch Speicherverschwendung zu erreichen? Nein. Entweder durch:

1) Windows Vista
2) OpenGL
3) Instancing (leider nur mit SM 3.0 möglich)
4) Geometry-Shader in D3D10 der dir Boxen aus einfachen Koordinaten + Matrix macht ;)

Oder wenn alle 4 nicht in Frage kommen: Dynamische Vertexbuffer füllen (paar tausend Polygone pro Buffer) bis sie voll sind und dann abschicken (den letzten natürlich mit weniger drin) - so blöd es klingen mag. Also wenn du wirklich viele Boxes brauchst für irgend ne Anwendung.

[Robbson]

Vorbemerkung: Unsere Messages laufen leicht Asynchron ;-)

Du bist Drawcall-limitiert = Du verwendest zuviele Drawcalls, wieviel Dreiecke gerendert werden pro DrawIndexedPrimitive ist dabei völlig egal.

Das ist bei DX9 besonders böse wegen dem beschissenen Treibermodell (bis einschließlich XP, mit Vista wirds besser), deshalb gibts auch die Instancing-API.

Ok... moment... hier enden wohl meine Minimal D3D Kenntnisse. D.h. also, auch wenn ich alle 6000 Cubes in einen einzigen Vertex Buffer schreiben und diesen mit einem mal anzeige, bin ich immernoch Draw Call limitiert? Aber dann habe ich doch nur noch einen einzigen DrawCall...

Und die Instancing-API sagt mir nu garnix... Ist das 'nen Bestandteil von Direct3D oder eine 3rd Party API ?
<--- Etwas verwirrt.

Robbson.

[Coda]

Ok... moment... hier enden wohl meine Minimal D3D Kenntnisse. D.h. also, auch wenn ich alle 6000 Cubes in einen einzigen Vertex Buffer schreiben und diesen mit einem mal anzeige, bin ich immernoch Draw Call limitiert?Nein, natürlich nicht.

Und die Instancing-API sagt mir nu garnix... Ist das 'nen Bestandteil von Direct3D oder eine 3rd Party API ?Bestandteil von DX9, mit SM 3.0 als Vorraussetzung.

[Robbson]

Ok, ich danke Euch für die Infos!

Ich muß die Tatsachen erstmal verdauen.... :-)
Und dann einige Optimierungen (außer Vista und die Extrawürste) 'mal ausprobieren... bin schon jetzt gespannt, was dabei herauskommt.

Robbson.

[Xmas]

Nun, das mag ja sein, aber Gouroud, usw. nutze ich hier ja nicht. Außerdem habe ich die Zahl von Guru3D... also einer renommierten Quelle. ;-)
Mit Flat Shading wirds nicht schneller. Wie gesagt, die Zahlen sind direkt von 3dfx.

Also zunächst einmal benutze ich indizierte Triangle Lists... damit blos kein Vertex zu viel mit drin steht, also auch DrawIndexedPrimitive.
Aber ich sehe ehrlich gesagt nicht wirklich den Sinn in einem größeren Vertexbuffer mit mehr Triangles, wenn (bis auf die Position) alle Vertices und Indices gleich sind. D.h. ich hätte irgendwo bspw. 100x die Datenstruktur des Cubes gespeichert... was für eine Verschwendung.
Testhalber habe ich 'mal eine ganze Reihe an cubes in einem VertexBuffer gespeichert (spart also ordentlich DrawCalls), bringt aber nix.
Bei einem "realistischen" Objekt hättest du ja auch in der Regel keine Tausende identischer Würfel. Sondern eine komplexe Struktur aus mehreren zehntausend Dreiecken, die sich mit einem einzigen Aufruf von DrawIndexedPrimitive zeichnen lassen.

Ich wollte einen fairen Test, sprich es müssen auch alle Dreiecke zu sehen sein, die ich rendere, sodaß HDSR und Co umgehen kann.
Im Übrigend ist der StandarD Gouroud Shader schneller... keine Frage, kann aber auch nicht mehr als 6.000.000 Dreiecke/Sekunde 'rausholen.
Noch ein wenig mehr bringt das BackfaceCulling, doch so schalte ich ja selbst im Wireframe immer mehr Dreiecke aus... so komme ich ja sonst nie an die Grenzen des Möglichen.
Es besteht durchaus ein Unterschied zwischen berechneten Dreiecken und gerenderten Dreiecken. Mit deiner 6800GT wirst du nicht mal ansatzweise in die Nähe von 100 Millionen gerenderten Dreiecken pro Sekunde kommen können. Zumindest nicht mit Farbe. Verworfen werden können aber mehr. Bei solchen Angaben werden immer alle Dreiecke gezählt, die übergeben werden, nicht nur jene die auch am Ende sichtbar sind.

[Robbson]

Nun, ob meine Dreiecke nun realistisch angeordnet sind oder nicht, das dürfte die Grafikkarte ja wenig interessieren.

Jedenfalls habe ich nun noch einige Tests gemacht, was folgendes Ergebnis erbrachte:
Wenn ich ein dreidimensionales "Feld" erzeuge, das aus 20x10x4=800 Cube primitives besteht und jeden Cube einzeln per DrawIndexedPrimitive() zeichne, so komme ich auf 175 fps (bei einer Fenster-Auflösung von 800x600 Punkten,ohne Backface Culling und als Wireframe dargestellt).
In diesem Fall würde also der VertexBuffer nur aus einem einzigen primitiven Cube bestehen, der 800x zur Anwendung kommt.

Im zweiten Versuch wurden ebensoviele Cubes unter den gleichen Bedingungen gerendert. Der Unterschied: In einem Vertexbuffer befindet sich nicht nur ein einziger, sondern 10x20=200 Cubes. Also sind für die Darstellung von 800 Cubes lediglich 4 (vier) Aufrufe von DrawIndexedPrimitive() nötig. Doch das Ergebnis ist dasselbe: ebenso 175 fps.

Resume:
Egal ob ich 4 mal oder 800 mal einen "DrawCall" tätige, die resultierenden fps sind gleich. Die DrawCalls können also unmöglich limitieren!

Außerdem habe ich noch verschiedene Framegrößen ausprobiert. So erbringen 640x480 Pixel 213 fps, während 1024x768 nur 139 fps bringen. Allerdings ist der Geschwindigkeitszuwags nicht linear zur Auflösungsreduzierung:
320x200 -> 282 fps, 160x200 -> 286 fps.

Wenn man also das Fenster beinahe verschwindend klein darstellt, dürfte auch der "Flaschenhals" des Rasterizers u.ä. wegfallen.

Es mag ja sein, daß mit einem Shader statt Wireframe realistischere Ergebnisse zu erwarten sind... doch dann auch nur, weil über HDSR und Z-Buffer ordentlich Triangles herausfliegen.

Doch daß sich nur so wenige Dreiecke auch tatsächlich darstellen lassen, ist für mich immernoch rätselhaft.
Vielleicht ist der Vergleich noch fairer, wenn man alle Dreiecke so skaliert, daß sie nebeneinander angeordnet werden können. Das ergibt dann selbst bei Wireframe eine einheitliche weiße Fläche, doch so kann man auch die anderen Shader wie FlatShading und Gouroud testen, ohne, daß diese von irgendwelchen Verdeckungen profitieren könnten!

Und ich hoffe immernoch, daß mir irgend ein Detail entgangen ist, das die komplette Leistung kostet...

Robbson.

[HajottV]

Wireframe

Und ich hoffe immernoch, daß mir irgend ein Detail entgangen ist, das die komplette Leistung kostet...


Mach mal Flatshading, Wireframe kostet irre viel bei einer Gamerkarte... und ja, Dir ist bestimmt etwas entgangen. Machst Du z.B. Software Vertexprocessing? Dann kämen 2.5 Mio Polys etw hin.

Gruß

Jörg

[whtjimbo]

@Robbson:
eigentlich müsstest Du ca. 80-90 Mio. Dreiecke/Sek schaffen (nach meiner Erfahrung). Wahrscheinlich sind beim Erstellen des VBO falsche Hints angegeben worden.

[Expandable]

@Robbson:
eigentlich müsstest Du ca. 80-90 Mio. Dreiecke/Sek schaffen (nach meiner Erfahrung). Wahrscheinlich sind beim Erstellen des VBO falsche Hints angegeben worden.

VBO? Er scheibt das in D3D ;)

[whtjimbo]

Das Konzept der DX9 Vertex Buffers unterscheidet sich doch nicht von den OpenGL VBOs. Bei beiden werden Hints vorgegeben und automatisch Verwaltung des System/AGP/Graka Speichers von der API verwaltet, beides sind nichts anderes als schöne grosse dynamische und auch statische Puffer. Somit dürfte er mit meinem Hinweis doch auch klar kommen :=)

[Robbson]

@HajottV
Wie schonmal geschrieben, bieten die anderen Modes natürlich etwas mehr Leistung wegen den Verdeckungungen und so. Allerdings ist es auch nicht sooo viel mehr und ich bin ja auf die darstellbare Dreieckszahl aus, die am Ende tatsächlich herauskommen... und so sehr kann auch der Wireframe mode nicht einknicken, daß "einige" Millionen Dreiecke/s fehlen.
Und ja, D3DCREATE_HARDWARE_VERTEXPROCESSING ist drin, genauso wie das D3DDEVTYPE_HAL Flag zuvor. :rolleyes:

@whtjimbo
Bei der Erstellung des VertexBuffers wird das Flag D3DUSAGE_WRITEONLY angegeben... das sollte also schon das Optimum für statische Objekte sein.

Yo und wenn alle 800 Cubes aus einem einzigen VertexBuffer gerendert werden sollen, sieht das dann so aus:

for(int y=0;y<10;y++)
{
for(int x=0;x<20;x++)
{
for(int z=0;z<4;z++)
{
D3DXMatrixTranslation(&mTemp, -10.0+(float)x, 5.0-(float)y, z);
g_pd3dDevice->SetTransform(D3DTS_WORLD, &mTemp);
g_pd3dDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 36, 0, 12);
}
}
}


Nix weltbewegendes also... und dieselbe Speed, als wenn ich nur 4 x DrawIndexedPrimitive mit einem größeren Vertex Buffer aufrufe.

Robbson.

[Coda]

Das sind doch trotzdem 800 Drawcalls X-D

Du hast nicht wirklich zuvor 800 Vertexbuffer alloziert?

[Robbson]

@Coda
Kurzzeitgedächtnis, wie? :biggrin:
Ich hatte doch in einem Posting zuvor nachgewiesen, daß sich die gleiche Speed auch aus 4 statt 800 DrawCalls ergibt!

Hier mit nur 4 Stück, dafür 200x größerer VertexBuffer:

for(int z=0;z<4;z++)
{
D3DXMatrixTranslation(&mTemp, -10.0, 5.0, z);
g_pd3dDevice->SetTransform(D3DTS_WORLD, &mTemp);
g_pd3dDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 36*200, 0, 12*200);
}




Und alloziert wird insgesamt logischerweise nur ein VertexBuffer... aber auch das schrieb ich gestern schon... :rolleyes: und außerdem kann man das im Code ja auch erkennen... da wird kein Vertex Buffer gewechselt.

Robbson.

[Coda]

Ich hatte doch in einem Posting zuvor nachgewiesen, daß sich die gleiche Speed auch aus 4 statt 800 DrawCalls ergibt!Logisch. Mit 48 Triangles bist du auch in keinster weise Vertexlimitiert.

Du bekommst die Zahlen nur wenn du wirklich große Mengen Dreiecke auf einmal renderst, glaubs mir einfach.

Deshalb sag ich ja auch du sollst entweder Instancing benützen oder dynamische Vertexbuffer befüllen und paar Tausend Dreiecke auf einmal rendern. Das ist von der CPU her immer noch schneller als das was du machst.

[Robbson]

Logisch. Mit 48 Triangles bist du auch in keinster weise Vertexlimitiert.

Du bekommst die Zahlen nur wenn du wirklich große Mengen Dreiecke auf einmal renderst, glaubs mir einfach.

Deshalb sag ich ja auch du sollst entweder Instancing benützen oder dynamische Vertexbuffer befüllen und paar Tausend Dreiecke auf einmal rendern. Das ist von der CPU her immer noch schneller als das was du machst.


Heute mit dem linken Bein :rolleyes: aufgestanden?
Natürlich ist die Zahl der Cubes pro Buffer auf 200 statt nur einem erhöht, wenn ich die 4 DrawCalls mache, damit das gleiche Ergebnis herauskommt...
Einfach nochmal den Posting von heute morgen lesen...

[Coda]

Heute mit dem linken Bein :rolleyes: aufgestanden? Anscheinend. Zeig mal den CreateVertexBuffer-Code.

[Robbson]

Anscheinend. Zeig mal den CreateVertexBuffer-Code.

Null Problemo:


// NEU Vertex und Index Buffer erzeugen für 200 Cubes (Feldanordnung) erzeugen (Performance Test)
if(FAILED( g_pd3dDevice->CreateVertexBuffer(
200*8*sizeof(SIMPLEVERTEX), D3DUSAGE_WRITEONLY /*0*/, D3DFVF_SIMPLEVERTEX, D3DPOOL_DEFAULT, &pVBCube3, NULL) ))return E_FAIL;
if(FAILED( g_pd3dDevice->CreateIndexBuffer(
200*sizeof(iCube), D3DUSAGE_WRITEONLY /*0*/, D3DFMT_INDEX16, D3DPOOL_DEFAULT, &pIBCube3, NULL) ))return E_FAIL;


Also nix besonderes.... In dem obigen Fall erzeuge ich die 200fache Buffergröße, damit in einem zweiten Schritt 200 Cubes in diesem angeordnet werden können.

Robbson.

[Xmas]

Wenn die Leistung so mit der Auflösung skaliert, bist du offensichtlich füllratenlimitiert. Sind die Würfel zufällig relativ groß und du renderst sie back-to-front oder ohne Z-Test?

Doch daß sich nur so wenige Dreiecke auch tatsächlich darstellen lassen, ist für mich immernoch rätselhaft.
Vielleicht ist der Vergleich noch fairer, wenn man alle Dreiecke so skaliert, daß sie nebeneinander angeordnet werden können. Das ergibt dann selbst bei Wireframe eine einheitliche weiße Fläche, doch so kann man auch die anderen Shader wie FlatShading und Gouroud testen, ohne, daß diese von irgendwelchen Verdeckungen profitieren könnten!
Ich weiß nicht warum dir das rätselhaft ist. Die Grafikkarten werden nun mal nicht darauf ausgelegt, 100 Mio. Dreiecke pro Sekunde tatsächlich zu rendern.
1024x768 mit 60 fps sind nicht mal 50 Mio. Pixel pro Sekunde.

[HajottV]

Die Grafikkarten werden nun mal nicht darauf ausgelegt, 100 Mio. Dreiecke pro Sekunde tatsächlich zu rendern.
1024x768 mit 60 fps sind nicht mal 50 Mio. Pixel pro Sekunde.

100 Mio nicht, aber 20-30 Mio pro Sekunde sollten drin sein.

Gruß

Jörg

[Robbson]

So, ich bin's nochmal, diesmal aber:

Neuer Test, neue Ergebnisse!

Wie in einem der letzten Postings angekündigt, habe ich nun 'mal einen anderen Test durchgeführt, bei dem alle Dreiecke auf einer Ebene dargestellt sind. HDSR und Z-Buffer, etc. fällt also flach!

Die globalen Testbedingungen:
- Frame-Auflösung von 1024x768 im Window Mode
- 48fache Darstellung (neben- und untereinander) bzw. DrawCalls eines Vertexbuffers mit je 1250 Dreiecken
-> es sind also 1250 x 48 = 60000 Dreiecke zu sehen
- Augpunkt soweit auf der Z-Achse verschoben, bis alle Dreiecke sichtbar
- Culling ist aktiviert (standartmäßig), macht hier aber natürlich keinen Unterschied
- Beleuchtung deaktiviert

Die Ergebnisse:
- 46 fps bei WireFrame -> 2.750.000 Triangles/Sec
- 863 fps bei Std. (Gouroud) Shading -> 51.780.000 Triangles/Sec

Krasser Unterschied, was? Damit bestätigt sich die Vermutung, daß die Treiber für Wireframe eindeutig EXTREM gebremst sind... Gut, man kann sich ja einen gehackten Quadro-Treiber installieren, was auch schon in Maya & Co riesige Performancesprünge brachte. Doch gibt's dafür nicht einen Hack, ohne auf die Workstation Treiber wechseln zu müssen? Ich würde in meiner Anwendung gerne 'mal in den Wireframe mode schalten, ohne künstlich ausgebremst zu werden.

Hier übrigens noch die Resultate bei reduzierter Auflösung: (320x200 statt 1024x768)
- 46 fps bei Wireframe (also konstant, ist ja eh gebremst)
- 1334 fps bei Std. (Gouroud) Shading -> 80.040.000 Triangles/Sec

Also 80 Mio SICHTBARE Dreiecke pro Sekunde ist doch schonmal nicht schlecht, was? Aber eben nur wenn sie ausgefüllt sind.

Im Übrigen habe ich den gleichen Test auch einmal mit 2 Dreiecken pro VertexBuffer und 30000 !!! DrawCalls ausprobiert und tatsächlich.... hier zeigt sich auch endlich die DrawCall Limitierung, sodaß man selbst mit Gouroud nur 113 fps erreicht :D

Grüße,
Robbson.

PS: 60.000 Dreiecke:

http://mitglied.lycos.de/robbson/Dreiecke.gif

[Coda]

Krasser Unterschied, was? Damit bestätigt sich die Vermutung, daß die Treiber für Wireframe eindeutig EXTREM gebremst sind... Nein, das liegt an der Hardware. Hat dir XMas doch auch schon erklärt.

[Robbson]

Nein, das liegt an der Hardware. Hat dir XMas doch auch schon erklärt.

XMas hat diesbezüglich nicht wirklich 'was relevantes erklärt (Sorry). Denn ob nun die Hardware für irgendwas optimiert wurde oder nicht... die extremen Unterschiede haben nix mit Optimierung zu tun, die sind 100% künstlich.

Mit der Hardware hat das ja auch nix zu tun, sondern mit dem Treiber und das hat sich ja nun erwiesen.
Hast Du schon einmal Maya oder 3D Studio mit gehackten Quadro-Treibern ausprobiert? Nein? Solltest Du mal,
denn dann zeigt sich der Unterschied und das sind Welten!!!

Die Wireframe-Darstellung ist künstlich gebremst, um den teuren Workstation-Karten einen zusätzlichen Performance-Schub zukommen zu lassen... Bisher dachte ich, daß dies ausschließlich für 3D Modeller zutrifft, aber nein, es läßt sich auch so nachweisen...

Robbson.

[tombman]

Also ich hatte mit der XVOX Techdemo sicher schon fast 500Mio/s ;)

http://img209.imageshack.us/img209/2395/farcry20060325204910065pf.th.jpg (http://img209.imageshack.us/my.php?image=farcry20060325204910065pf.jpg)

TPS = triangles per second in million
TPF = -"- per frame in tausend

[Robbson]

Hier nun endlich ein kleines "Tool" zum Selbertesten:

Einfacher Performance Test! (http://mitglied.lycos.de/robbson/D3DExp.exe)

Viel Spaß,
Robbson.

[tombman]

also bei dem tool geschieht genau gar nix, geht auf und wieder zu...

[Formica]

lycos lässt es mich nicht direkt runterladen ...

[misterh]

also bei dem tool geschieht genau gar nix, geht auf und wieder zu...lycos lässt es mich nicht direkt runterladen ...Rechtklickt dann download unter.

Gammachrome S18 Pro

Fullscreen Modus
http://img374.imageshack.us/img374/1540/triangle2jc.jpg

[tombman]

Rechtklickt dann download unter.

Ich HATTE das tool eh, aber es wurde kein Programm ausgeführt, die Anwendung beendete sich sofort wieder...

[Robbson]

@misterh
Wow, 338 Frames im WireFrame Mode... und wieviel sind es im Standard Shaded Mode?

@tombman
Bei XVOX sind aber ein Großteil der Dreiecke verdeckt und nicht sichtbar, außerdem ist es kein Wireframe, deshalb nicht vergleichbar.
Allerdings kann man im Wireframe Mode und bei Ansicht von oben auch ungefähr (aber teils immer noch verdeckte) 60.000 Dreiecke/Sekunde erreiche, sodaß man auf eine ähnliche Framerate kommt. Auch hier ist Wireframe Performance-Einbruch pur.

http://mitglied.lycos.de/robbson/XVOX_60K.GIF

Daß meine Applikation bei Dir nicht funzt könnte mehrere Gründe haben, da ich am Anfang keine Fähigkeiten der Grafikkarte abfrage... was hast denn für 'ne Hardware? Vielleicht gibt's bei Dir ja irgend eine Option nicht und ich muß 'mal 'nen Fallback einbauen.

Robbson.

[tombman]

.. was hast denn für 'ne Hardware? .
X1900 Crossfire, intel presler cpu (ohen CF aber gehts auch ned)

[tombman]

@tombman
Bei XVOX sind aber ein Großteil der Dreiecke verdeckt und nicht sichtbar, außerdem ist es kein Wireframe, deshalb nicht vergleichbar.
Allerdings kann man im Wireframe Mode und bei Ansicht von oben auch ungefähr (aber teils immer noch verdeckte) 60.000 Dreiecke/Sekunde erreiche, sodaß man auf eine ähnliche Framerate kommt. Auch hier ist Wireframe Performance-Einbruch pur..
Dein Bild zeigt aber nicht 60K/sec sondern 60k/frame.

Ich hatte auch mit wireframe von oben schon über 100Mio/sec Dreiecke. (X1900 CF)

[misterh]

Robbson

andere? 456 FPS und sehe nur weiss.

[Xmas]

Krasser Unterschied, was? Damit bestätigt sich die Vermutung, daß die Treiber für Wireframe eindeutig EXTREM gebremst sind... Gut, man kann sich ja einen gehackten Quadro-Treiber installieren, was auch schon in Maya & Co riesige Performancesprünge brachte. Doch gibt's dafür nicht einen Hack, ohne auf die Workstation Treiber wechseln zu müssen? Ich würde in meiner Anwendung gerne 'mal in den Wireframe mode schalten, ohne künstlich ausgebremst zu werden.
Ich würde das nicht unbedingt "künstlich" nennen. Ich kann mir eine Möglichkeit vorstellen wie der Treiber Wireframe bei Quadro-Karten optimiert. Die kostet allerdings Speicher. Da Spiele im Allgemeinen auf Wireframe verzichten, wäre eine solche Optimierung nicht gerade ideal.

Hier übrigens noch die Resultate bei reduzierter Auflösung: (320x200 statt 1024x768)
- 46 fps bei Wireframe (also konstant, ist ja eh gebremst)
- 1334 fps bei Std. (Gouroud) Shading -> 80.040.000 Triangles/Sec

Also 80 Mio SICHTBARE Dreiecke pro Sekunde ist doch schonmal nicht schlecht, was? Aber eben nur wenn sie ausgefüllt sind.
Hast du gezählt?

Dein Screenshot ist 1024x768 Pixel groß, dabei sind 27 Pixel Rand oben + unten sowie 8 Pixel Rand rechts + links. Der Viewport ist also nur 1016x741 Pixel groß. 921x672 Pixel sind von den Dreiecken bedeckt.

Wenn ich das jetzt auf 320x200 übertrage (was du ja wahrscheinlich wiederum auf die Fenstergröße beziehst), hast du einen Viewport von 312x173 Pixeln, wovon 283x158 Pixel von Dreiecken bedeckt sind. 44431 Pixel also, d.h. es sind auch nur 44431 Dreiecke sichtbar. Damit kommst du nur auf 60 Mio. gerenderte Dreiecke pro Sekunde.

[crusader4]

Eine 9800 Pro mit Standardtaktraten erreicht folgendes:
http://img148.imageshack.us/img148/8058/tritestnowf3lm.th.png (http://img148.imageshack.us/my.php?image=tritestnowf3lm.png) http://img155.imageshack.us/img155/8148/tritestwf0bu.th.png (http://img155.imageshack.us/my.php?image=tritestwf0bu.png)

Ich hatte beim ersten Durchlauf AA (6x) und AF (16x) im CCC an, und wunderte mich schon warum ich schlechtere Werte hatte als misterh. ;D

Hab in dem Zusammenhang mal ne Frage:
Muß man die Nutzung von AA und AF in einer Anwendung erlauben, oder wird das dann immer erzwungen wenn es im CP an ist?

Grüße, Crusader

[misterh]

Ich hatte beim ersten Durchlauf AA (6x) und AF (16x) im CCC an, und wunderte mich schon warum ich schlechtere Werte hatte als misterh. ;D

blaaaaaaa :ucrazy3:

[AnarchX]

Bei mir will das Prog auch nicht laufen:

P4 HT
6800GT Forceware 84.25
Windows XP

[Coda]

blaaaaaaa :ucrazy3:Aha. Was möchtest du uns damit sagen?

[misterh]

Aha. Was möchtest du uns damit sagen?

von ein Gammachrome kann man nicht viel erwarten.

daher sollte auch 9800er mehr haben :biggrin:

[Räuber Hotzenplotz]

läuft leider nicht.

GeForce FX 5800
Forceware 84.21
Athlon XP 2000+
Win 2000 SP4 + fixes

[Robbson]

Also nochmal was zur Kompatibilität:
Da läßt sich natürlich einiges machen, aber der Test für meinen eigenen Rechner war ursprünglich auch nicht als öffentliches Tool gedacht, sondern nur auf Anfrage 'rausgespuckt. Dennoch ergibt sich für mich somit 'mal die Herausforderung auch gleich etwas kompatibles hinzubekommen...

@tombman
Also bei Deiner Config sind natürlich ein paar Dreiecke mehr drin ;-)
Und ja, in der einen Message sollten das Dreiecke/Frame und nicht pro Sekunde heißen.

Daß die ATI Karten ebenfalls bei wireframe gebremst sind, ist ebenfalls nix neues. Doch Performance ist eben nicht alles und so gibt es mit den gehackten Fire GL Treibern unter 3D Modellern immerwieder kuriose Probleme... jedenfalls früher, als ich noch davon betroffen war... während die nvidia hacks neben Speed auch Kompatibilität brachten.

@misterh
Daß Du nur weiß siehst, ist schon ok. Bei Deiner Chrome hält sich der Performance-Verlust aber in Grenzen. Du bekommst im "Filled mode" 456 FPS und bei Wireframe 338... das ist also ein Performanceverlust von nicht 'mal 26%, damit könnte ich leben. Außerdem könnte man hier wie Xmas argumentieren, daß die Treiber eher für Games optimiert sind. Doch bei mir liegt der Leistungsverlust bei knapp 97% (von 1334 fps auf 46 fps). Wer hier noch glaubt, daß dies lediglich durch unterschiedliche Optimierungen bedingt ist, der glaubt wohl auch noch an den Weihnachtsmann (wie passend). ;D

Und da ich gerade so in Weihnachtsstimmung bin, komme ich nun zu...

@xmas
Sicher gibt es Möglichkeiten Wireframe zu beschleunigen... aber Du willst mir doch nicht allen Ernstes glauben machen, daß der Wireframe-Mode mehr Speed kostet, als wenn alle Dreiecke gefüllt werden müßten... das wäre wohl leicht paradox. Und bedenke, daß in dem Testprogramm kein Dreieck im R³ verdeckt wird...

Und was Deinen amusischen Gedankengang mit dem Dreieckszählen betrifft: Es ist doch gleichgültig, welche Auflösung eingestellt ist und wenn es nur 30x30 Pixel sind... Der Grafikkarte ist das völlig egal, denn sie berechnet alle sichtbaren (d.h. nicht durch andere Dreiecke verdeckten) Dreiecke... Es gäbe keine aufwendigen LOD Verfahren, wenn die GPU schon "wüßte", daß aufgrund der niedrigen Auflösung best. Dreiecke wegfallen könnten. Deshalb ist Deine Argumentation wohl ziemlich daneben...

Außerdem müßtest Du bedenken, daß natürlich noch viiiieeeel weniger Dreiecke sichtbar sind, wenn der Nutzer vergißt seine Brille aufzusetzen (falls er denn eine benötigt)... :tongue:

Robbson

[The_Invisible]

no AA:
non wireframe: 2200fps
wireframe: 110fps

4x4 SSAA:
non wireframe: 220fps
wireframe: 50fps

man, was für nen performancedrop :eek:

mfg

[Gast]

[QUOTE=Robbson

Und was Deinen amusischen Gedankengang mit dem Dreieckszählen betrifft: Es ist doch gleichgültig, welche Auflösung eingestellt ist und wenn es nur 30x30 Pixel sind... Der Grafikkarte ist das völlig egal, denn sie berechnet alle sichtbaren (d.h. nicht durch andere Dreiecke verdeckten) Dreiecke... Es gäbe keine aufwendigen LOD Verfahren, wenn die GPU schon "wüßte", daß aufgrund der niedrigen Auflösung best. Dreiecke wegfallen könnten. Deshalb ist Deine Argumentation wohl ziemlich daneben...
[/QUOTE]

damit hast du aber nur eine geringe anzahl sichtbarer dreiecke.

die graka berechnet immer alle dreiecke die sie von der cpu bekommt, egal ob sichtbar oder nicht. wenn du hier einsparen willst musst du die nicht sichtbaren dreiecke bereits auf der cpu aussortieren.

deine anwendung ist offensichtlich hochgradig füllratenlimitiert (eventuell auch bandbreitenlimitiert) und nicht durch den dreiecksdurchssatz.

durch das quad-basierte rendering sinkt auch die nutzbare füllrate bei derart kleinen dreiecken auf 1/4.

[HajottV]

aber Du willst mir doch nicht allen Ernstes glauben machen, daß der Wireframe-Mode mehr Speed kostet, als wenn alle Dreiecke gefüllt werden müßten...

Genau das sagen Dir hier mehrere Leute... und genau so ist es bei Gamerkarten.

Gruß

Jörg

[thomas62]

Robbson

andere? 456 FPS und sehe nur weiss.

drück mal die space-taste

[Xmas]

@xmas
Sicher gibt es Möglichkeiten Wireframe zu beschleunigen... aber Du willst mir doch nicht allen Ernstes glauben machen, daß der Wireframe-Mode mehr Speed kostet, als wenn alle Dreiecke gefüllt werden müßten... das wäre wohl leicht paradox. Und bedenke, daß in dem Testprogramm kein Dreieck im R³ verdeckt wird...
Wenn du nicht vollkommen füllratenlimitiert bist, kostet Wireframe mehr Leistung. Das ist überhaupt nicht paradox, sondern ergibt sich einfach daraus dass die GPU Linien in der Regel als zwei Dreiecke darstellt. Und wenn es zum generieren dieser Linien keine spezielle Hardware gibt, muss das der Treiber ausgehend vom Vertex- und Indexbuffer erledigen.

Und was Deinen amusischen Gedankengang mit dem Dreieckszählen betrifft: Es ist doch gleichgültig, welche Auflösung eingestellt ist und wenn es nur 30x30 Pixel sind... Der Grafikkarte ist das völlig egal, denn sie berechnet alle sichtbaren (d.h. nicht durch andere Dreiecke verdeckten) Dreiecke... Es gäbe keine aufwendigen LOD Verfahren, wenn die GPU schon "wüßte", daß aufgrund der niedrigen Auflösung best. Dreiecke wegfallen könnten. Deshalb ist Deine Argumentation wohl ziemlich daneben...
Ich habe vorher schon den Unterschied zwischen berechneten Eckpunkten/Dreiecken (Transformation der Geometrie, Setup) und gerenderten Dreiecken (Rasterizer und Pixel Shader) erläutert. Es können deutlich mehr Dreiecke durch Transformation und Setup, als letztlich gerendert werden können, da nun mal sehr viele Dreiecke beim Setup verworfen werden können: Backface Culling, Clipping, Dreiecke die nicht auf einen Pixel fallen weil sie zu klein sind. Und gerade von Letzteren hast du eben einige bei niedriger Auflösung.

[Robbson]

Wenn du nicht vollkommen füllratenlimitiert bist, kostet Wireframe mehr Leistung. Das ist überhaupt nicht paradox, sondern ergibt sich einfach daraus dass die GPU Linien in der Regel als zwei Dreiecke darstellt. Und wenn es zum generieren dieser Linien keine spezielle Hardware gibt, muss das der Treiber ausgehend vom Vertex- und Indexbuffer erledigen.


Na das klingt ja schon interessanter... :) Eine Linie, die durch 2 Dreiecke dargestellt werden muß... na ok, dann habe ich statt 1350 Frames eben die Hälfte... würde ja auch noch gehen... aber es sind eben "etwas" weniger. So als ob die Wireframe-Darstellung komplett in Software erledigt werden müßte, doch eine schnellere CPU bringt hier offensichtlich auch nix. Rein Hardware-technisch gibt es jedenfalls keine Einschränkung, sonst würde ein gehackter Quadro-Treiber ja nicht zu solchen Performancesprüngen fähig sein.


Ich habe vorher schon den Unterschied zwischen berechneten Eckpunkten/Dreiecken (Transformation der Geometrie, Setup) und gerenderten Dreiecken (Rasterizer und Pixel Shader) erläutert. Es können deutlich mehr Dreiecke durch Transformation und Setup, als letztlich gerendert werden können, da nun mal sehr viele Dreiecke beim Setup verworfen werden können: Backface Culling, Clipping, Dreiecke die nicht auf einen Pixel fallen weil sie zu klein sind. Und gerade von Letzteren hast du eben einige bei niedriger Auflösung.

Nun Backface Culling und Clipping sind in der Anwendung ja schonmal irrelevant... Denn Backfaces sind nicht zu sehen (bzw. können hier überhaupt nicht zu sehen sein)... ja und geclippt wird auch nix.
Und eben weil Dreiecke sicher auch vom Rasterizer verworfen werden, habe ich die Testauflösung soweit heruntergeschraubt, daß keine Füllratenlimitierung mehr gegeben ist.

Schon komisch, wenn man sich von einer S3 Grafikkarte geschlagen geben muß (46fps <-> 338 fps).

Aber unabhängig von der ganzen Diskussion, ob nun der Wireframe Mode für Gamer bzw. Konsumergrafikkarten Sinn macht oder nicht... Man sollte auch bedenken, daß selbst Gamer mit Sicherheit gerne 'mal selber Level basteln und dabei nicht auf große 3D Modelling Tools zurückgreifen. Es wäre ja wohl völlig absurd, wenn Tools wie GMax, Maya PE oder Unreal ED, etc. eine Workstation Grafikkarte benötigten, nur um den Wireframe Mode vernünftig einsetzen zu können (besonders bei den hohen Polygonzahlen von Leveln/Objekten aktueller Games).

Diese User, die Games modden und somit mehr wollen als die offensichtliche Zielgruppe (Zocker), werden künstlich ausgebremst... Von S3 nicht, von Matrox nicht, von ATI etwas und von nVidia ganz besonders.

Robbson.

[Coda]

Aber unabhängig von der ganzen Diskussion, ob nun der Wireframe Mode für Gamer bzw. Konsumergrafikkarten Sinn macht oder nicht... Man sollte auch bedenken, daß selbst Gamer mit Sicherheit gerne 'mal selber Level basteln und dabei nicht auf große 3D Modelling Tools zurückgreifen. Es wäre ja wohl völlig absurd, wenn Tools wie GMax, Maya PE oder Unreal ED, etc. eine Workstation Grafikkarte benötigten, nur um den Wireframe Mode vernünftig einsetzen zu können (besonders bei den hohen Polygonzahlen von Leveln/Objekten aktueller Games).Dafür reicht die Vertexleistung wirklich zur Genüge ;)

Es ist wirklich so wie XMas sagt. Der Rasterizer eine Radeon oder GeForce kann keine Linien zeichnen, auf den Quadros und FireGLs wird nur mehr Speicher verschwendet um das zu optimieren.

[misterh]

@misterh
Daß Du nur weiß siehst, ist schon ok. Bei Deiner Chrome hält sich der Performance-Verlust aber in Grenzen. Du bekommst im "Filled mode" 456 FPS und bei Wireframe 338... das ist also ein Performanceverlust von nicht 'mal 26%, damit könnte ich leben. Außerdem könnte man hier wie Xmas argumentieren, daß die Treiber eher für Games optimiert sind. Doch bei mir liegt der Leistungsverlust bei knapp 97% (von 1334 fps auf 46 fps). Wer hier noch glaubt, daß dies lediglich durch unterschiedliche Optimierungen bedingt ist, der glaubt wohl auch noch an den Weihnachtsmann (wie passend). ;D

Und da ich gerade so in Weihnachtsstimmung bin, komme ich nun zu...

Robbson

:) ok. Dann mal schauen wieviel da Chrome S27 kriegt.

[Xmas]

Na das klingt ja schon interessanter... :) Eine Linie, die durch 2 Dreiecke dargestellt werden muß... na ok, dann habe ich statt 1350 Frames eben die Hälfte... würde ja auch noch gehen... aber es sind eben "etwas" weniger. So als ob die Wireframe-Darstellung komplett in Software erledigt werden müßte, doch eine schnellere CPU bringt hier offensichtlich auch nix. Rein Hardware-technisch gibt es jedenfalls keine Einschränkung, sonst würde ein gehackter Quadro-Treiber ja nicht zu solchen Performancesprüngen fähig sein.
Es ist wahrscheinlich ein Trade-off: schneller Wireframe-Modus und dafür andere Nachteile (z.B. mehr Speicherbedarf) oder langsamer Wireframe-Modus.

Und eben weil Dreiecke sicher auch vom Rasterizer verworfen werden, habe ich die Testauflösung soweit heruntergeschraubt, daß keine Füllratenlimitierung mehr gegeben ist.
Je niedriger du die Auflösung wählst, desto mehr Dreiecke werden verworfen weil sie keinen Pixel bedecken.

Aber unabhängig von der ganzen Diskussion, ob nun der Wireframe Mode für Gamer bzw. Konsumergrafikkarten Sinn macht oder nicht... Man sollte auch bedenken, daß selbst Gamer mit Sicherheit gerne 'mal selber Level basteln und dabei nicht auf große 3D Modelling Tools zurückgreifen. Es wäre ja wohl völlig absurd, wenn Tools wie GMax, Maya PE oder Unreal ED, etc. eine Workstation Grafikkarte benötigten, nur um den Wireframe Mode vernünftig einsetzen zu können (besonders bei den hohen Polygonzahlen von Leveln/Objekten aktueller Games).
Der Wireframe-Modus ist weit davon entfernt, nicht vernünftig einsetzbar zu sein.

[Robbson]

Dafür reicht die Vertexleistung wirklich zur Genüge
Der Wireframe-Modus ist weit davon entfernt, nicht vernünftig einsetzbar zu sein.

Das sehe ich nicht so... überhaupt nicht! Wer schon einmal einen Blick auf aktuelle Games geworfen hat, wird feststellen, daß es in den letzten Jahren ein paar Dreiecke mehr geworden sind... Und 3D Modeller (selbst die kostenlosen Editionen) leiden deutlich unter dem Performanceverlust, das kann ich aus eigener Erfahrung klar bestätigen. Es sei denn, man bastelt nur an "low mesh" Objekten wie denen in Quake1.
Außerdem ist liegt eine 6800GT immer noch im besseren Performance-Segment auf dem Grafikkartenmarkt... viel schlimmer dürfte es bei den kleineren Modellen wie der 6600er und 6200er aussehen...

Wer Zweifel hat, braucht nur 'mal eine größere Map aus Unreal 1 (EINS) in den UnrealED zu laden und auf Wireframe schalten....

Die einzige Lösung ist wohl der Kauf einer neueren Grafikkarte, obwohl die alte dazu im Stande ist. Oder eben der gehackte Quadro-Treiber, falls sowas mit aktuellen Karten noch funktioniert.
Soweit ich mich erinnern kann, ist die Game Performance mit den Quadro-Treiber nur wenige Prozentpunkte schlechter... weshalb ich bei meiner Ansicht bleibe: künstlich ausgebremst, auch wenn die Grafikkarte die Dreiecke umständlicher rendern müßte... mehr Performance müßte in jedem Fall drin sein.

Doch könnte man nicht einen Vertex/PixelShader schreiben, der einem Wireframe vorgaukelt? Würde mich 'mal interessieren, wie's dann mit der Performance aussieht...

Außerdem sind reine Wireframe Games durchaus attraktiv (mit Backface-Culling natürlich)... "Tron 2.0" sah ja auch etwas anders als gewöhnliche Games aus.... ohne Performance-Verlust. :D

Robbson.