AGP8x & Doom III

[DjDino]

Ein Polygon besteht ja aus aneinander b.z.w. umeinander sich schliessenden Dreicken und diese Drieecke haben immer 3 Eckpunte. Damit der Grafikchip weis wo er ein Poylgon umsetzen soll braucht er eben diese 3D-(Eck)-Koordinaten, definiert durch : X,Y,Z (4Byte pro Koordinate)- um nur EINEN solchen Eckpunkt zu bestimmen braucht man also in der Regel 4x3 = 12 Byte.
Hinzu kommt jetzt aber noch die "Normale" des Eckpunktes welche als "Konstante" deren genauere Positionsbestimmung erleichtert,
hierfür braucht es normal nochmal 12Byte.
-----------------------------
Ergo : Gesammte Geometrie-Bestimmung eines Eckpunktes : 24Byte.
-----------------------------
( Jetzt wäre schon ein nacktes "Drahtgittermodell" (Wireframe) einer Spielfigur fertig und hierfür 24Byte pro Eckpunkt Datenflus.
nötig b.z.w. ~ 72Byte pro Dreieck.)

Sieht aber nicht schön aus, auf diese "Dreiecksflächen" kommen jetzt noch Texturen.(Ebenfalls Eckunkt-definiert)
Eine Textur braucht Farbwerte : RGBA (R=rot,G=Grün,B=Blau,A = Alpha-Wert, z.b. transparenz,halbdurchsichtige Texturen...)
Das sind dann also jeweils 1 Byte für R,G,B und A nötig, zusammen : 4Byte, kommen aber noch etwas mehr Alpha-Definitionen hinzu kann es auch bis 8Bit hinaufgehen.
-----------------------------------------------
Farbe : 4-8 Byte. (mehr bei viel Alpha-Einsatz)
-----------------------------------------------
Es müssen jetzt aber noch die Farben korrekt auf die jeweiligen Dreiecke plaziert werden, dazu braucht es Texturkoordinaten wodurch sich der Datenaufwand dann doch auf 4-32Byte erhöht.

Diese Datenmenge hängt insgesammt jetzt also davon ab wie grosse(detailierte) Texturen später den Dreiecken auferlegt werden sollen.

In einem Spiel wie z.b. UT2003 mit seinen grösseren,Detail-Texturen von 1024x1024 fallen so für die Texturkoordinaten um die 16Byte an, noch schönere und grössere Texturen mit 2048x2048 oder mehr fordern dann bis 32Byte an Texturkoordinaten.
---------------------------------------------------------------------------------
Texturkoordinaten : 16-32 Byte. (mehr bei grösseren also detailierteren Texturen)
---------------------------------------------------------------------------------

ALL DAS ZUSAMMEN ERGIBT ZWISCHEN ~ 40 - 70 BYTES FÜR EINEN VOLLSTÄNDIGEN ECKPUNT.

Hinzu kommen jetzt aber noch für ein vollständiges Dreieck einige "AGP-Steuerdaten" welche aber anscheinend eine Art Geheimnis der Chipdesigner sind - diese Daten sollen aber in der Regel um die 10% des gesammten "Dreieckdatenflusses" ausmachen.

EIN DREIECK BESTEHT AUS 3 ECKPUNKTEN - MACHT ALSO FÜR EIN DREIECK + STEUERDATEN
(40x3+Steuerdaten) = ca.130 Bytes bis (70x3+Steuerdaten) = ca. 230Bytes.

-------------------------------------------------------------------------------

Wirklich nur über den Dauem gerechnet ;

Wenn man jetzt also z.b. von einem Spiel wie Doom III weis das es insgesammt
(Szenerie + Modelle) um die 100.000 Polygone einsetzt und vorwiegend mit
2048x2048 grossen Texturen arbeitet sowie auch Mutlitexturing und Alpha-Effekte
einsetzt ergibt sich hierbei ein "INSGESAMMT NÖTIGER AGP-DATENFLUSS" von grob gerechnet :

Fertige (Vertex)-Positionsbestimmung : ~ 24Byte

plus :

Farbe : 8bytes

plus :

Texturkoordinaten : 16Byte

plus :

Steuerdaten : 10%
------------------
= zusammen rund 57 "Eckpunkt-Bytes"
mal 3(für ein vollständiges Dreieck) = 171Bytes
-----------------.
Jetzt der Datenaufwand pro Dreieck noch mal Anzahl der Polygone
(Gemeinsamme Eckpunkt-Nutzung geschätzt) im Spiel :

100000 x 171Bytes = 1,71 Gybte/sec.

Doom III grob geschätzt : 1,71Gbyte/sec. Anforderungen an den AGP-Bus.

AGP4x ermöglicht maximal ~ 1Gbyte/sec.
AGP8x ermöglicht maximal ~ 2Gbyte/sec.

Meine Frage nun : Habe ich hier einige Parameter falsch gesetzt, missverstanden oder etwas ausgelassen ?

[c.p.d.]

Es ist zu beachten, dass mehrere Polygone einen gleichen Eckpunkt haben können. Daraus folgt, dass es zwar im Extremfall 3*byteproecke*anz-polygone bytes geben kann. Im Normalfall dürfte der Wert aber um einiges tiefer liegen (schätzungsweise um ein Drittel).

[Pitchfork]

- Ein Vertex (Eckpunkt eines Dreiecks) hat in der Regel 32 Byte oder mehr: Position (X,Y,Z), Texturekoordinaten (U,V), Normale (X,Y,Z), Farbe (RGBA). Fürs BumpMapping kann sich da einiges ändern, aber die Größenordnung 32 Byte bleibt.

- Statische Meshes werdem im Grafikspeicher abgelegt. Dazu gehört alles, was nicht animiert ist oder sonstwie auf der CPU berechnet wird.

- Auf nVidia GPUs müssen also für statische Meshes nur die Indexdaten (welches Dreieck braucht welchen Vertex) über den Bus, das sind gerade mal 6 Byte pro Dreieck.

- ATI GPUs können auch die Indizes im Grafikspeicher halten.

- Btw, ein gut modellierter Mesh brauch nur einen neuen Vertex pro Dreieck.

- Doom3 benutzt dynamische Meshes für Animationen und für die Schattenvolumes. Levelgeometrie, Waffen etc. sind statisch.

- Mit Vertex Shader Hardware kann man Vertices gut komprimieren, aus den 32-40 Byte können ohne sichtbaren Qualitätsverlust auch mal 12-24 Byte werden (wer brauch denn schon 12 Byte für die Normale, paßt doch auch in 4, das gleiche für TexCoords).

Insgesamt reduziert sich so die Busbelastung um einiges (was ich jetzt aber nicht in Zahlen ausdrücke *g*).

Ausserdem schiebt Doom3 100000 Polys pro Frame und nicht 100000 pro Sekunde, das macht also 6 Mio Polys pro Sekunde.



Pitchfork

[Demirug]

DjDino, habs mir jetzt noch nicht so genau angesehen aber am ende ist ein Rechenfehler:

100000 x 171Bytes sind nur etwas mehr als 16 MB.

Das ganze 60 mal pro Sekunde wären etwas weniger als 1 GB/s. Wobei deine Zahlen irgendwo nicht ganz stimmen können. Ich werde mir das später noch etwas genauer ansehen

[MeLLe]

Habe mir Deine Werte nicht genau angeschaut, aber ich hätte trotzdem ein paar Anmerkungen:

1) Texturen hast Du ganz vergessen, oder? Es werden ja nicht nur Textur-Koordinaten über den AGP geschoben. Auch die Texturen an sich. Die machen das Kraut fett! ;)

2) Was bedeutet in Deiner Rechnung "Farbe"?

3) Wie meine Vorredner schon schreiben:
Die meisten 3D-Engines zeichnen IMHO nicht Dreieck für Dreieck, sondern benutzen Triangle-Strips/-Fans. Damit werden nur für das erste Dreieck eines Strips/Fans drei Vertices benötigt. Jedes weitere Dreieck wird durch EINEN weiteren Vertex definiert, weil es eine Kante bzw. zwei Vertices des vorhergehenden Dreiecks mitbenutzt. Dadurch reduziert sich das Datenaufkommen für Geometriedaten schon gewaltig.

[Demirug]

MeLLe,

Texturen werden aber nicht für jeden Frame neu übertragen :)

[DjDino]

"Ein Vertex (Eckpunkt eines Dreiecks) hat in der Regel 32 Byte oder mehr: Position (X,Y,Z), Texturekoordinaten (U,V), Normale (X,Y,Z), Farbe (RGBA). Fürs BumpMapping kann sich da einiges ändern, aber die Größenordnung 32 Byte bleibt....auf nVidia GPUs müssen also für statische Meshes nur die Indexdaten (welches Dreieck braucht welchen Vertex) über den Bus, das sind gerade mal 6 Byte pro Dreieck."

Größenordnung 32 Byte bleibt also in der Regel gleich, Rennt der Index nur in eine Richtung über den BUS und dann mit wieviel Prozent ?

[MeLLe]

Originally posted by Demirug
MeLLe,
Texturen werden aber nicht für jeden Frame neu übertragen :)
Gut, das stimmt wohl :) Verdämmt... :D

[Pitchfork]

Originally posted by DjDino
Größenordnung 32 Byte bleibt also in der Regel gleich, Rennt der Index nur in eine Richtung über den BUS und dann mit wieviel Prozent ?

Nur in eine Richtung? Versteh nicht ganz, was du meinst.
Prinzipiell ist das so: der Treiber erzeugt einen Command Stream im DMA/AGP fähigen Speicher, wo alle Renderbefehle für einen oder sogar mehrere Frames reingeschrieben wird, also z.B.

- verwende Textur XY
- schalte trilineares Filtern ein
- setze BlendModes auf ONE_ZERO
- setze Vertex Buffer Z
- zeichne 50000 Dreiecke mit folgende Indizes
- Index 0
...
- Index 150000
- swappe front- und backbuffer

Das ist der Basis Bustransfer. Der geht in genau eine Richtung, von der CPU (bzw. Hauptspeicher) in die GPU.

Dazwischen stecken natürlich noch Befehle wie Lade Textur Z, lade VertexBuffer D, etc.pp. die ebenfalls den AGP Bus belasten.

Aber z.B. bei 300 Mio Polys/s kommen schonmal nur für die Indizes 1,7 Gigabyte/s an Traffic bei rum. Deshalb kann die R300 eigentlich nur ausgelastet werden, wenn die Indizes von vorherein im Grafikspeicher stecken (was sie auch tun bei der R300).

Pitchfork

[zeckensack]

@DjDino

Das Datenaufkommen für die Texturkoordinaten ist nicht von der Größe (oder anders gesagt dem Detailgrad) der Texturen abhängig.

Mit 2 floats (ergibt dann 8 Bytes pro Vertex) kann man die Chip-interne Texturaddressierung idR präzisionsmäßig bereits voll auslasten bzw überfordern. Mehr braucht man für eine Textur also nie. Wenn man ein bisschen trickst (Vertex Shader) oder mit Rundungsfehlern leben kann, reichen auch 16bit Integer-Texturkoordinaten, womit man auf 4 Bytes pro Vertex runtergehen kann.

Für Multitexturing erhöht sich der Bedarf an Texturkoordinaten, dann muß man mehrere Sätze pro Vertex übertragen, aber wie gesagt, mit der Texturauflösung hat das nicht viel zu tun :)

[DjDino]

@zeckensack

Vielen Dank und auch allen anderen, dann sind es doch mehr Fehler als ich dachte - was das betrifft muss ich noch viel lernen bis ich sagen kann "He Alter ich hab die Buses und Pipelines voll im Griff :D"

Hat jemand von euch einen guten Buchtip für mich was genau diese Sachen betrifft ? Wenn mögliche keine 1000-Seiten Studienausgaben ála Freud :D aber trotzdem ausführlich genug ?