polygon-performance

[boxleitnerb]

hallo leute, bin neu hier und ich hätte mal ne frage:
die 3d-chiphersteller protzen auf den packungen mit knapp 70mio polys/sek und sei es beim high-polycount test im 3dmark2001 oder bei der neuen codecult demo - ich bekomme nie mehr als 25-30mio poly/sek, beim codecult benchmark sogar nur 6mio. woran liegt das? sind die specs der chips falsch oder versteh ich das was nicht richtig?
bitte klärt mich auf

[barnygumble]

die geben immer nur die idealsten werte an, die in der praxis nie erreicht werden können. sobald lichtquellen dazu kommen, gehts schonmal nach unten (und das nicht zu knapp, acht lichtquellen achteln den wert mindestens) hängen die polys dann nicht zusammen (verschiedene objekte) geht ebenfalls viel verloren, da die hersteller dabei immer nur von einem eckpunkt pro polygon ausgehen, was nur erreicht werden kann, wenn die polys zusammenhängen.

[boxleitnerb]

dnake für die infos

[ow]

Originally posted by barnygumble
(und das nicht zu knapp, acht lichtquellen achteln den wert mindestens)

:lol::lol: nun mal nicht übertreiben

Riva TNT:

High Polygon Count (1 Light): 2267 KTriangles/s
High Polygon Count (4 Lights): 2272 KTriangles/s
High Polygon Count (8 Lights): 2285 KTriangles/s


Erkennst du da eine Achtelung?
Oder hier:

Kyro1:

High Polygon Count (1 Light): 5632 KTriangles/s
High Polygon Count (4 Lights): 5628 KTriangles/s
High Polygon Count (8 Lights): 5591 KTriangles/s

GF2MX (HW):

High Polygon Count (1 Light): 11573 KTriangles/s
High Polygon Count (4 Lights): 7840 KTriangles/s
High Polygon Count (8 Lights): 4666 KTriangles/s

GF2MX (SW)

High Polygon Count (1 Light): 8232 KTriangles/s
High Polygon Count (4 Lights): 8238 KTriangles/s
High Polygon Count (8 Lights): 5785 KTriangles/s

[zeckensack]

Die von den Herstellern angegebenen Polygondurchsätze sind Maximalwerte für die T&L Einheit, die in der Praxis nie erreicht werden. Diesen Durchsatz erreicht man nur dann, wenn man 0 Pixel rendert, Texturen abschaltet und 0 Lichter aktiviert hat. Selbst unter diesen Bedingungen muß man dann noch ein wenig tricksen, um Vertex-Caches optimal zu nutzen.

Siehe zB hier (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005940.html).

[Exxtreme]

@ ow
Ich glaube boxleitnerb meint HW-T&L, weil mir kein GraKa-Hersteller einfällt, der 70 Mio Polygone bei einer Nicht-HW-T&L-GraKa angegeben hat ;).
Bei einer Spiele-HW-T&L-GraKa bricht die Performance bei 8 aktivierten Lichtquellen tatsächlich relativ stark ein. Zwar nicht auf ein Achtel, aber rund auf die Hälfte, da die Spiele-GraKas AFAIK keine 8 Lichtquellen in einem "Pass" berechnen können sondern nur eine einzige. Bei mehreren Lichtquellen brauchen sie mehrere Durchläufe. Die professinellen (teuren) Workstation-GraKas können AFAIK bis zu 16 Lichtquellen in einem Durchgang berechnen.

Gruß
Alex

[Exxtreme]

@ boxleitnerb
Das, was die GraKa-Hersteller auf ihre bunten Kartons schreiben, hat mit der Realität nicht wirklich viel zu tun. Diese Angaben nämlich gehen vom absoluten Idealfall aus. Die Real-World-Performance lässt sich nur mit Praxistests belegen.

Gruß
Alex

[Quasar]

Originally posted by Exxtreme
[B Zwar nicht auf ein Achtel, aber rund auf die Hälfte, da die Spiele-GraKas AFAIK keine 8 Lichtquellen in einem "Pass" berechnen können sondern nur eine einzige. Bei mehreren Lichtquellen brauchen sie mehrere Durchläufe. [/B]

Hast du dazu einen Link, das würde mich BRENNEND interessieren! Ehrlich.

[Exxtreme]

Originally posted by Quasar


Hast du dazu einen Link, das würde mich BRENNEND interessieren! Ehrlich.
Ich habe es selbst getestet, daß 8 Lichtquellen die Performance ggü. 1 Lichtquelle halbieren. Daß die Spiele-GraKas nur eine Lichtquelle in einem Pass berechnen können, das müsste ich suchen. Wenn ich einen Link finde, dann poste ich ihn.

Gruß
Alex

EDIT:
Hab's hier (http://www.3dconcept.ch/artikel/T&L/6.htm) gefunden.

[MaxSPL]

Yo, würde mich auch interessieren...



Cya, MaxSPL

[Quasar]

Danke, Alex!

Auf 3D-Concept ist immer noch Verlass, wie? :)
OK, also werden demnach pro Lightsource min. 1 Taktzyklus (allerdings nur für die Geometrie-Engine, nicht Rendering Passes insgesamt, *puh_glück_gehabt*) verbraucht. Danke für deine Mühe.

[ow]

Originally posted by Exxtreme
@ ow
Ich glaube boxleitnerb meint HW-T&L, weil mir kein GraKa-Hersteller einfällt, der 70 Mio Polygone bei einer Nicht-HW-T&L-GraKa angegeben hat ;).
Bei einer Spiele-HW-T&L-GraKa bricht die Performance bei 8 aktivierten Lichtquellen tatsächlich relativ stark ein. Zwar nicht auf ein Achtel, aber rund auf die Hälfte, da die Spiele-GraKas AFAIK keine 8 Lichtquellen in einem "Pass" berechnen können sondern nur eine einzige. Bei mehreren Lichtquellen brauchen sie mehrere Durchläufe. Die professinellen (teuren) Workstation-GraKas können AFAIK bis zu 16 Lichtquellen in einem Durchgang berechnen.

Gruß
Alex


Spielt doch im Prinzip kein Rolle ob HW oder SW T&L.
Ich bezog mich ja nur auf die Aussage "8 lichtquellen achteln den wert mindestens".

Und das trifft bei keiner Karte zu.

Übrigens:
Die T&L der Radeon1 scheint schwächer als die der MX:

3DM2k default:

Radeon (HW)

High Polygon Count (1 Light): 9442 KTriangles/s
High Polygon Count (4 Lights): 6442 KTriangles/s
High Polygon Count (8 Lights): 4380 KTriangles/s


Radeon (SW), P3 Optimierung auf XP1700

High Polygon Count (1 Light): 7466 KTriangles/s
High Polygon Count (4 Lights): 6621 KTriangles/s
High Polygon Count (8 Lights): 5812 KTriangles/s

[ow]

Meine Radeon1 Werte im 3DM2k default

HW T&L:

High Polygon Count (1 Light): 9442 KTriangles/s
High Polygon Count (4 Lights): 6442 KTriangles/s
High Polygon Count (8 Lights): 4380 KTriangles/s

SW T&L:

High Polygon Count (1 Light): 4519 KTriangles/s
High Polygon Count (4 Lights): 4018 KTriangles/s
High Polygon Count (8 Lights): 3214 KTriangles/s

P3 Opt.:

High Polygon Count (1 Light): 7466 KTriangles/s
High Polygon Count (4 Lights): 6621 KTriangles/s
High Polygon Count (8 Lights): 5812 KTriangles/s


Wieso bricht die CPU eigentlich kaum ein beim Berechnen mehrerer LQ?

[Salvee]

Die Q3-Engine beispielsweise unterstützt gar kein "echtes" HW-T&L,
da de facto das Lightning von der CPU berechnet wird, und nur
die Transformation vom Grafikchip übernommen wird.

[zeckensack]

Originally posted by Salvee
Die Q3-Engine beispielsweise unterstützt gar kein "echtes" HW-T&L,
da de facto das Lightning von der CPU berechnet wird, und nur
die Transformation vom Grafikchip übernommen wird.

Jein, die Q3-Engine benutzt Lightmaps, das funktioniert sowieso ganz anders als Hardware-Lichter. Für ordentliche Resultate mit Hardware-Licht muß man die Geometrie viel höher auflösen, da hier nur pro Vertex die Lichtintensität berechnet und über den Rest des Dreiecks interpoliert wird. Lightmaps sind für statische Beleuchtung auf grober Geometrie der eindeutig bessere Weg und mit Rückständigkeit oä hat das nicht das geringste zu tun.

BTW, wie jedes andere OpenGL-Programm das mindestens auf Version 1.0 ausgelegt ist, benutzt Q3 evtl vorhandene Transformationshardware automatisch. Nur damit hier keine Missverständnisse aufkommen. ;)

[ow]

Wird Q3 bei "Vertex lighting" dann voll HW T&L beschleunigt?
Oder gibt´s da keine Lichtquelle?



BTW, wie jedes andere OpenGL-Programm das mindestens auf Version 1.0 ausgelegt ist, benutzt Q3 evtl vorhandene Transformationshardware automatisch. Nur damit hier keine Missverständnisse aufkommen



Aber nur wenn der OGL Treiber richtg funzt.
Hatte eine Radeon1 auf So7 K6-2 System und da ist unter einigen OGL Anwendungen nix von HW T&L zu spüren. Das Teil kriecht. Eine MX nutzt dagegen immer ihre HW T&L und war auf dem K-6 der Radeon deutlich überlegen.

Jetzt hab ich die Radeon auf einem XP1700 und da funzt HW T&L überall IMO.

[Unregistered]

Originally posted by ow

Wieso bricht die CPU eigentlich kaum ein beim Berechnen mehrerer LQ?

Weil bei der CPU nicht die Rechenleistung das größte Problem ist, sondern der Speicherdurchsatz. Und wenn man einen Vertex sowieso anfassen muß zum Beleuchten, dann sind alle erforderliche Daten in den Caches und deshalb ist der Einbruch nicht sooooo groß, weil die CPU in der Zwischenzeit sowieso nur auf die Daten des nächsten Vertex gewartet hätte.
Allerdings sollte man durch geschicktes Preloaden der CPU Caches diese Wartezeiten minimieren können, und das sollte man bei den DX Programmierern auch erwarten, daß sie alle Register ziehen. Deshalb wundert es micht dann doch, daß die Einbrüche nicht größer sind....

Ich hoffe, ich habe jetzt alle Klarheiten beseitigt...

Pitchfork

[zeckensack]

Originally posted by ow
Wird Q3 bei "Vertex lighting" dann voll HW T&L beschleunigt?
Oder gibt´s da keine Lichtquelle?
In dem Modus gibt's ja bekanntlich überhaupt kein Licht. Da werden einfach nur die Lightmaps abgeschaltet. Ob da jetzt noch irgendwas anderes vorgesehen ist, das wissen wohl nur die Herren aus Texas. AFAIK enthalten die Leveldaten nicht mal die Positionen der globalen Lichter, geschweige denn Oberflächennormalen, und ohne diese Informationen kann man sowieso kein 'echtes' Licht machen.

Aber nur wenn der OGL Treiber richtg funzt.
Hatte eine Radeon1 auf So7 K6-2 System und da ist unter einigen OGL Anwendungen nix von HW T&L zu spüren. Das Teil kriecht. Eine MX nutzt dagegen immer ihre HW T&L und war auf dem K-6 der Radeon deutlich überlegen.

Jetzt hab ich die Radeon auf einem XP1700 und da funzt HW T&L überall IMO.Da will ich dir nicht wiedersprechen. Kann sein, daß der Treiber da irgendeinen Unsinn treibt. Worum es mir eigentlich ging war festzuhalten, daß T&L von Anfang an in OpenGL enthalten ist. Man kann in OpenGL keinen einzigen Strich malen, ohne durch die T&L-Stufe zu gehen. Ob das jetzt SW oder HW ist, das kann die Applikation gar nicht erkennen. Aber diese Unterscheidung wie bei DX6 (Applikation muß selber ran) contra DX7 (Aplikattion kann auf HW oder MS' Software-Emu zurückgreifen) hat es da nie gegeben.

[Salvee]

Dass die Q3-Engine rückständig sei, wollte ich damit natürlich nicht
sagen (welch Blasphemie ;) ), höchstens bei den Ladezeiten von grossen Maps,
das steht hier aber nicht zur Debatte. Eigentlich meinte ich das Dynamic Lightning,
beispielsweise verursacht durch den Rocket Launcher, das nicht per Graka-Lightning
berechnet wird, sondern durch die CPU. Die Lightmaps werden doch schon im Editor
berechnet und sind somit statisch, richtig ?

[zeckensack]

Originally posted by Salvee
Dass die Q3-Engine rückständig sei, wollte ich damit natürlich nicht
sagen (welch Blasphemie ;) ), höchstens bei den Ladezeiten von grossen Maps,
das steht hier aber nicht zur Debatte. Eigentlich meinte ich das Dynamic Lightning,
beispielsweise verursacht durch den Rocket Launcher, das nicht per Graka-Lightning
berechnet wird, sondern durch die CPU.
Soweit ich weiß, werden hier einfach zusätzliche 'bewegliche' Lightmaps auf die Wände gepappt. Für HW-Lighting fehlt hier wie gesagt die geometrische Auflösung und es fehlen auch die Oberflächennormalen.
Was bei zu geringer Geometrieauflösung passiert, kann man hier (http://www.opengl.org/developers/code/features/KilgardTechniques/oglpitfall/oglpitfall.html) schön sehen. Das Bildchen unter Punkt 2 - "Poor Tessellation Hurts Lighting" dürfte das gut demonstrieren.
Die Lightmaps werden doch schon im Editor
berechnet und sind somit statisch, richtig ?
Jupp. Das schöne daran ist, daß man sich hier so richtig Zeit nehmen kann und wahnsinnig komplexe Beleuchtungsmodelle (zB Radiosity) berechnen kann. Der Nachteil ist, daß die Lichter sich nicht bewegen dürfen.

[Xmas]

Die Aussage von barnygumble hätte wohl "Acht Lichtquellen achteln den Wert höchstens" sein müssen, und selbst das trifft bei aktueller Hardware nicht zu. Aber das ist eh von Chip zu Chip verschieden.

Wenn allerdings Vertex Lighting aktiviert ist, glaube ich nicht dass Q3 noch Lightmaps verwendet. In dem Fall wäre es möglich, dass vom Rochet Launcher einfach entfernungsabhängig die Beleuchtung berechnet wird, ohne Normalen. Das sollte für ein kurzes Aufleuchten reichen. Aber ich kann das im Moment nicht nachprüfen.

Man kann natürlich auch in OpenGL die T&L des Treibers (ob nun Software oder Hardware) weitestgehend umgehen, lediglich Clipping und die Viewport-Transformation hat man immer.

[barnygumble]

so, nachdem ihr meine aussage von oben nun gründlich zerlegt habt :)
muß ich zugeben, daß das mit dem achteln wohl ein bischen übertrieben war. ich hatte das eh mal nur so angenommen, aber darum ging es ja eigentlich nicht, sondern nur darum, daß theoretische werte nie erreicht werden, schon garnicht, wenn beleuchtung im spiel ist.

[ow]

Originally posted by zeckensack

In dem Modus gibt's ja bekanntlich überhaupt kein Licht. Da werden einfach nur die Lightmaps abgeschaltet. Ob da jetzt noch irgendwas anderes vorgesehen ist, das wissen wohl nur die Herren aus Texas. AFAIK enthalten die Leveldaten nicht mal die Positionen der globalen Lichter, geschweige denn Oberflächennormalen, und ohne diese Informationen kann man sowieso kein 'echtes' Licht machen.



Das dachte ich mir fast. Haette ja aber sein koenne, das die komplette Szene von einer diffusen LQ (kein spot, point...)ausgeleuchtet wird.


Da will ich dir nicht wiedersprechen. Kann sein, daß der Treiber da irgendeinen Unsinn treibt. Worum es mir eigentlich ging war festzuhalten, daß T&L von Anfang an in OpenGL enthalten ist. Man kann in OpenGL keinen einzigen Strich malen, ohne durch die T&L-Stufe zu gehen. Ob das jetzt SW oder HW ist, das kann die Applikation gar nicht erkennen. Aber diese Unterscheidung wie bei DX6 (Applikation muß selber ran) contra DX7 (Aplikattion kann auf HW oder MS' Software-Emu zurückgreifen) hat es da nie gegeben.


Ja das weiss ich.
Daher wundert mich immer wieder die von vielen angestellte Behauptung, es gaebe kaum Applikationen, die HW T&L nutzen und deshalb waere HW T&L voellig sinnlos.

[Exxtreme]

Originally posted by ow

Ja das weiss ich.
Daher wundert mich immer wieder die von vielen angestellte Behauptung, es gaebe kaum Applikationen, die HW T&L nutzen und deshalb waere HW T&L voellig sinnlos.
Daß es viele Programme gibt, die HW-T&L nutzen, das hat niemand angezweifelt. Die Frage stellt sich, ob die Applikationen und der Nutzer davon überhaupt profitieren. Solange es überwiegend Games gibt, die durch HW-T&L nicht merklich schneller werden, sage ich NEIN. Die einzigen Games, die von HW-T&L tatsächlich profitieren, sind AFAIK Giants und Max Payne. Und dies nur auf die Transformation bezogen. Das Lighting wird AFAIK von keinen Spiel genutzt.

Gruß
Alex

[ow]

Und was ist mit der CPU Auslastung durch SW T&L?
Meinst du die CPU Zeit koennte man nicht sinnvoller nutzen als fuer T&L? Fuer KI zB.?

Auch wenn's nicht schneller wird, so ist der Vorteil der HW T&L doch IMMER vorhanden (sogar wenn HW T&L langsamer als SW T&L ist).

[Exxtreme]

Originally posted by ow
Und was ist mit der CPU Auslastung durch SW T&L?
Meinst du die CPU Zeit koennte man nicht sinnvoller nutzen als fuer T&L? Fuer KI zB.?
Man könnte. Es wird aber irgendwie nicht gemacht - warum auch immer. Also ich habe noch bei keinem Spiel richtig intelligente Gegner usw. gesehen.
Originally posted by ow

Auch wenn's nicht schneller wird, so ist der Vorteil der HW T&L doch IMMER vorhanden (sogar wenn HW T&L langsamer als SW T&L ist).
Hmm, AFAIK ist HW-T&L dazu gedacht gewesen hohe Polygonzahlen zu erzeugen ohne, daß der Prozessor belastet wird. Das ist bei den heutigen Games kaum der Fall. Deswegen ist dieser Vorteil eher ein theoretischer. In der Praxis spielt es z.Zt. keine Rolle ob mit oder ohne HW-T&L, zumindest bei Spielen.

Gruß
Alex

[ow]

Originally posted by Exxtreme


Hmm, AFAIK ist HW-T&L dazu gedacht gewesen hohe Polygonzahlen zu erzeugen ohne, daß der Prozessor belastet wird. Das ist bei den heutigen Games kaum der Fall. Deswegen ist dieser Vorteil eher ein theoretischer. In der Praxis spielt es z.Zt. keine Rolle ob mit oder ohne HW-T&L, zumindest bei Spielen.

Gruß
Alex [/B]


Nein, die Polygone werden immer noch von der CPU erzeugt.
T&L transformiert nur die von der CPU erzeugten Polygone. Und die damit verbundene erhebliche Entlastung der CPU durch HW T&L ist der eigentliche Vorteil gegenueber SW T&L.



/edit: KI ist ja nur ein Fall, wo man die eingesparte CPU Leistung gebrauchen kann. Man koennte auch die Physik der Engine verbessern (reale Flugbahnen von Geschossen,...). Moeglichkeiten gibt's da viele.

[Birdman]

Ob das jetzt SW oder HW ist, das kann die Applikation gar nicht erkennen.

hmm, wie funzt denn das bei Spielen wo man Hardware T&L ausschalten kann? z.B. Ssam ?
Irgendwie muss da die Applikation ja da die autodetect Funktion von OpenGL umschiffen um bei HW t&L fähigen Karten den Software Modus zu nutzen...

[Xmas]

Originally posted by Birdman
hmm, wie funzt denn das bei Spielen wo man Hardware T&L ausschalten kann? z.B. Ssam ?
Irgendwie muss da die Applikation ja da die autodetect Funktion von OpenGL umschiffen um bei HW t&L fähigen Karten den Software Modus zu nutzen...
Nein. Es gibt weder eine Autodetect Funktion noch einen Software-Modus. Aber wie ich schon geschrieben habe kann die Applikation die OpenGL-T&L umgehen und eigene Routinen verwenden.

[zeckensack]

Originally posted by Birdman
hmm, wie funzt denn das bei Spielen wo man Hardware T&L ausschalten kann? z.B. Ssam ?
Irgendwie muss da die Applikation ja da die autodetect Funktion von OpenGL umschiffen um bei HW t&L fähigen Karten den Software Modus zu nutzen...
Da muß ich Xmas zum Teil Recht geben, zum Teil widersprechen. ;)
Man kann die Transformationstufe in OpenGL nicht abschalten. Man kann lediglich eine Trivialmatrix laden, die die Vertices nicht verändert. Es liegt dann am Treiber zu erkennen, daß diese Berechnungsstufe überflüssig ist.

Bei den Optionen für T&L-Hardware in MDK2 oder Serious Sam tipp ich da eher auf andere Optimierung. Optimierungsstrategien für SW-T&L und HW-T&L sind nämlich in weiten Teilen gegensätzlich.

Unter SW-T&L sind Vertices ein teures Gut, man ist fast immer geometrielimitiert. Es lohnt sich hier, aggressiv Polygone vorzusortieren, ihre Sichtbarkeit vor dem Rendern zu überprüfen (Stichwort: Frustum culling) und wirklich nur das an die Graka zu schicken, was zu sichtbarer Veränderung auf dem Bildschirm führt. Das kostet eine Menge CPU-Zeit, lohnt sich aber, da Transformation überflüssiger Vertices noch mehr Zeit kosten würde.

Bei HW-T&L ist Geometrieleistung in rauhen Mengen vorhanden, man kommt hier zumeist erstmal ans Fill- bzw Bandbreitenlimit. Die schnellste Lösung ist hier, die Levelgeometrie nur grob zu unterteilen (zB Sektoren a 25k-100k Dreiecke!) und fahrlässig tonnenweise überflüssige Vertices in die Pipeline zu schmeißen. Culling und Clipping sorgen dann schon für den Rest und die CPU muß sich um diesen Dreck - akkurates Frustum culling - dann nicht mehr kümmern.

Genaue Zahlen hab ich leider im Moment (noch) nicht, aber ich würde grob schätzen, daß in Q3 jeder 'Leaf' im BSP-Baum (kleinste Einheit die gecullt werden kann) maximal zwischen 2500 und 5000 Dreiecke enthält. Letztlich ein Kompromiß zwischen akzeptabler Performance auf HW der TNT2-Klasse und netter Performance auf Geforce/Radeon. Bei aggressiver Optimierung auf HW-T&L sähe das schon ganz anders aus, und niemand würde mehr am Nutzen von HW-T&L zweifeln ;)

Was man mit T&L ala DX7/unerweitertes OpenGL1.0 natürlich nicht machen kann, sind Animationen, die über bloße Verschiebung/Rotation/Skalierung einzelner, getrennter Objekte hinausgehen. Die animierte Geometrie (Charaktere usw) muß hierbei immer noch von der CPU erzeugt werden, bevor sie an die Graka geht. Genau dafür (und für andere Spezialeffekte, die letztlich auch nur Animationstechniken sind) braucht man dann Vertex Shader.

[Xmas]

Originally posted by zeckensack
Da muß ich Xmas zum Teil Recht geben, zum Teil widersprechen. ;)
Man kann die Transformationstufe in OpenGL nicht abschalten. Man kann lediglich eine Trivialmatrix laden, die die Vertices nicht verändert. Es liegt dann am Treiber zu erkennen, daß diese Berechnungsstufe überflüssig ist.
"Erkennen" kann man das ja kaum noch nennen ;).
glLoadIdentity gibts ja schließlich nicht ohne Grund. Es gibt wohl keinen Treiber, der dann die entsprechende Berechnung nicht einfach überspringt.