Benchmarks AGP 4x vs. 8x?

Original erstellt von DjDino

Ich überlege nämlich auch grade das die Radoen9700 ja DirectX9 kann und somit eine Shader bis zu 1024 Befehle anstatt nur 128(DirectX8) ausführen kann. Jetzt brauchen die dafür notwenigen Shader-Programmcodes bei DirectX9-Nutzung rechnerisch ~ 8mal mehr Datenaufwand (?)

der Programmcode wird einmal in den Speicher der Grafikkarte geladen, macht bei 1024Befehlen (selbst wenn pro Befehl 512Bit anfallen sollten) nur 64KByte - das kratzt den AGP-Bus nicht.
Ausgeführt wird der Code ja auf der Grafikkarte selbst und belastet dadurch den AGP-Bus überhaupt nicht, sondern nur interne Bandbreite.


Steigt mit DirectX9 dann der "Vertexstrom" aufgrund höherbittig angefordeter Texturdaten?

solange die Anzahl der Polygone gleichbleibt

Was aber dramatisch ansteigen dürfte ist der Platzbedarf der Texturdaten. Sollte tatsächlich ein Programmierer auf die Idee kommen die Grafikkarte mit 64Bit-Texturen zu füttern werden die 256MB Grafikspeicher schnell voll werden, aber auch die sind theoretisch mit 8xAGP (2GB/s) in 1/8 Sekunde (125ms) gefüttert.
Sollten dann die Texturen noch durch die Engine veränderbar sein oder oft neu geladen werden, könnte 8xAGP durchaus wieder Sinn machen. Aber davon sind wir noch weit entfernt. Solche Spiele müssen erst noch geschrieben werden. Derartige Anwendungsfälle gibt es derzeit nur im professionellen CAD Bereich, aber dort schreit man ja schon ewig nach 8xAGP :)

Der Gamer wird definitiv in den nächsten Jahren nich von 8xAGP profitieren. Momentan bietet der Haupspeicher und die Prozessoren nicht genügend Bandbreite um die 2GB/s für den AGP-Bus so mal nebenbei abzuarbeiten. Und wenn es in vielleicht 1 Jahr soweit sein sollte, dann vergehen mit Sicherheit nochmal 1-2 Jahre bis die Spiele fertig entwickelt sind.
Bis dahin kräht keiner mehr nach 8xAGP, dann ist das ein alter Hut und 32xAGP oder noch ganz was besseres steht dann vor der Tür.
 
Das der Code auf der Grafikkarte selbst ausgeführt wird (da Bestandteil der internen DX8/9-Pipeline) und somit den AGP-Bus überhaupt nicht belastet ist mir klar und das die höheren Farbtiefen unter DirectX9 mehr Ram zum Auslagern brauchen hab ich schon in einem vorigen Thread bedacht, da aber auch hier (da unabhängig davon) der Bedarf an "Vertexströmen" nicht bedenklich steigt... wie es in der Summe scheint ist dann also theoretisch AGP8x ohne nutzen wie du schon sagtest.

Selbst wenn von Nutzen wäre der Arbeitsspeicher der Flaschenhals. Über die Northbridge ist der AGP mit dem Arbeitsspeicher verbunden.

Selbst DDR400-Speicher bietet "nur" ~ 3.2Gbyte/sec. Bandbreite
Lasten unterm Spielen viele Scripte auf der CPU fordert diese um die 50-60% deren Bandbreite.(Hauptsächlich fordert nochimmer die CPU den Arbeitsspeicher primär)
Blieben also sagen wir 40% von 3.2Gbyte/sec. = ~1.3Gbyte/sec.

Für den AGP-Bus stehen damit nur noch 1.3Gbyte/sec. bei nem Board mit DDR400-Speicher.

Wie sollen dann die 2Gbyte/sec. welche AGP8x ermöglicht zum Port gelangen...cool das du das verstehst weil so mancher glotzt leider immer noch nur auf die ach so tollen Zahlen und kauft dann z.b. eine Xabre weil auf der Packung das with AGP8x Now! trohnt :D ...hm...trauriges Marketing.
 
Wenn ich mich nochmal kurz einmischen dürfte:

Mehr als 32bittig werden bei DX9 nur die internen Berechnungen im Floating-Point Format ablaufen, so daß Rundungsfehler bei multiplen Renderingpasses kaum noch ins Gewicht fallen dürften und Color-Banding wahrscheinlich erstmal der Vergangenheit angehört.
Der Framebuffer bleibt weiterhin bei 32Bit, also machen auch Texturen in einem höheren Format (von denen ich mir momentan nicht sicher bin, ob sie überhaupt vorgesehen sind) keinen wirklich Sinn.

Außerdem gibt es bereits einen DDR-Chipsatz, der im spezifizierten Betrieb 4,2GB/s erreicht: nForce.
Und mit dem nForce2, der angeblich ja DDR400 unterstützen soll, steigt das ganze nochmals kräftig an. Selbst wenn neuere Athlons auf einen 166MHz-FSB umschwenken, bleibt noch reichlich Bandbreite für AGP-Transfers übrig.....

So, weitermachen! ;)
 
Heisst also weniger Rundungsfehler durch bitstärkere interne Berechnung per Alpha-Kanal (Blend-Operation : Transparenz,Vermischung,...) bei aber gleichbleibender 24Bit/Truecolor-Farbtiefe(RGB) :)

Mehr als Truecolor geht ja nicht mehr also musste man dessen Berechnung per Blend-Operationen optimieren (?)
 
Zurück
Oben