Ati: Warum sind 8 Pipes nötig, um ein 256 Bit Interface auszunutzen?

[BlackArchon]

Warum können die 4-pipelinigen Radeons 9500 und 9800SE nur so einen geringen Nutzen aus ihrem 256 Bit Speicherinterface (sofern vorhanden) ziehen? Sprich warum setzen sie sich nur so wenig von ihren 128 Bit Brüdern ab? Die haben doch immerhin die doppelte Speicherbandbreite.

Kann mir das jemand verständlich erklären?

[LovesuckZ]

Von einem Menschen, der sich nicht auskennt: Weil es ihnen einfach an der nötigen Fillrate und damit Power fehlt?

[Demirug]

Die "kleinen" können maximal 4 Pixel/Takt erzeugen. Dabei wird in aller Regel der Farbwert höchstens überschrieben und der Z-Wert gelesen und vielleicht geschrieben.

Das sind also maximal 4*(32+32+32) Bit die dafür gebraucht werden. Der Z-Buffer lässt sich in der Regel gut komprimieren. Ein Faktor von 4 ist da nicht zu optimitisch. Dann sind wir bei 4*(32+8+8) = 192 Bit. Unser 256 Bit Interface kann maximal 512 Bit pro Speichertakt verarbeiten. Es bleiben also noch 320 Bit übrig. Damit müssen wir jetzt die 4 Texturfilter versorgen. Bei einem Bi-Filter geht man dabei üblicherweise davon aus das pro Sample durchschnittlich ein zusätzlicher Texturwert benötigt wird und der Rest aus dem Cache kommt. Das wären dann also 4*32 Bit = 128 Bit. Rechen wir die jetzt auch ab bleiben immer noch 192 Bit übrig. Da bei der 9800SE der Speichertakt nur bei etwa 90% des Chipstakts läuft müssen da nochmal 51 Bit abgezogen werden. Es bleiben aber immer noch 141 Bit übrig. Damit kann man dann locker noch ein paar Vertexdaten einladen. Schreibt dann der Chip nicht bei jedem Takt einen Pixel in den Speicher fallen die 192 Bit vom Anfang für diese takte auch weg.

Nimmt man jetzt einen vollen R3XX sieht die Rechung etwas anders aus.

8*(32+8+8) = 384
+8*32 = 256
+ 56 (Taktausgleich 9800XT)

= 696 Bit

Wir haben aber nur 512. Beim Singeltexturing wird der Chip also klar vom Speicherinterface gebremst. Selbst bei 2 Texturen pro Pixel reicht es rechnerisch gerade so. Dabei sind aber noch nicht die Bandbreite für den Verteshader und die Verluste durch Wartetakte beim Speicher berücksichtigt. Ergo bremst der Speicher immer noch.

Erhöht man jetzt durch Dinge wie zum Beispiel AA oder Alphablending die Bandbreitenaforderungen noch etwas müssen die Pixel noch aufwendiger in der Berechnung werden das die Bandbreite nicht zum Flaschenhals wird.

[Keel]

Original geschrieben von BlackArchon
Warum können die 4-pipelinigen Radeons 9500 und 9800SE nur so einen geringen Nutzen aus ihrem 256 Bit Speicherinterface (sofern vorhanden) ziehen? Sprich warum setzen sie sich nur so wenig von ihren 128 Bit Brüdern ab? Die haben doch immerhin die doppelte Speicherbandbreite.

Kann mir das jemand verständlich erklären?
Ich kenne mich mit den 9500er und 9800er SE-Karten nicht so aus, vermute aber mal folgendes: Was nützt einem Bandbreite, wenn es an Füllrate fehlt (und umgedreht)? Und nur doppelte Bandbreite heißt noch lange nicht doppelte Performance.

PS: Huch, da waren schon ein paar schneller. :D

[BlackArchon]

Original geschrieben von Demirug
...
Dann sind wir bei 4*(32+8+8) = 192 Bit. Unser 256 Bit Interface kann maximal 512 Bit pro Speichertakt verarbeiten. Es bleiben also noch 320 Bit übrig. Damit müssen wir jetzt die 4 Texturfilter versorgen. Bei einem Bi-Filter geht man dabei üblicherweise davon aus das pro Sample durchschnittlich ein zusätzlicher Texturwert benötigt wird und der Rest aus dem Cache kommt. Das wären dann also 4*32 Bit = 128 Bit. Rechen wir die jetzt auch ab bleiben immer noch 192 Bit übrig. Da bei der 9800SE der Speichertakt nur bei etwa 90% des Chipstakts läuft müssen da nochmal 51 Bit abgezogen werden.
...Hm, das heißt also jetzt, dass eine 4-pipelinige Karte einen 37,5% hören Chiptakt als den RAM-Takt bräuchte, um das 256 Bit Speicherinterface ausnutzen zu können?

[Demirug]

Original geschrieben von BlackArchon
Hm, das heißt also jetzt, dass eine 4-pipelinige Karte einen 37,5% hören Chiptakt als den RAM-Takt bräuchte, um das 256 Bit Speicherinterface ausnutzen zu können?

Das kann man so allgemein nicht sagen. Es gibt auch Situationen bei denen es mit der Bandbreite auch bei den "kleinen" eng wird. Der Flaschenhals bei einer Grafikkarte ist etwas fliessendes. Bei den "kleinen" wird es aber viel seltener die Bandbreite sein als bei den "grossen". Genauso gibt es auch Situationen bei denen den "grossen" die Bandbreite auch mehr als reicht. Zum Beispiel bei einem aufwendigen Shader der viel rechnet.

[BlackArchon]

Ok danke! Ich glaube jetzt versteh ich das besser. :)

[Monger]

Original geschrieben von Demirug
... Genauso gibt es auch Situationen bei denen den "grossen" die Bandbreite auch mehr als reicht. Zum Beispiel bei einem aufwendigen Shader der viel rechnet.

Könnte man das so deuten, dass man bei den großen Karten gewissermaßen die Shaderberechnungen "for free" kriegt, weil sie (im Gegensatz zu großen Texturen usw.) ohnehin nicht sonderlich auf die Bandbreite drücken?

Mir fällt dazu nur ein, dass mir noch kein Spiel übern Weg gelaufen ist, bei dem das abschalten von irgendwelchen Shadern deutlich Performance-Sprünge gebracht hötte.

[aths]

Original geschrieben von Monger
Könnte man das so deuten, dass man bei den großen Karten gewissermaßen die Shaderberechnungen "for free" kriegt, weil sie (im Gegensatz zu großen Texturen usw.) ohnehin nicht sonderlich auf die Bandbreite drücken?Für arithmetische Rechnungen sind ja auch Takte notwendig. Dann limitiert eben nicht die Bandbreite, sondern die "arithmetische Füllrate".

[Monger]

Original geschrieben von aths
Für arithmetische Rechnungen sind ja auch Takte notwendig. Dann limitiert eben nicht die Bandbreite, sondern die "arithmetische Füllrate".

Sorry, ich bin da leider nicht ganz so fit...

Mit arithmetischer Füllrate meinst du im Prinzip den GPU-Takt, bzw. wie schnell er den Shader abarbeiten kann?!?

Wie funktioniert denn der Austausch über die Bandbreite? Pausiert die Grafikkarte, wenn die Bandbreite überfüllt ist? Gibt es dann einen Puffer, der erst alles rausschreibt, bevor die Grafikkarte wieder die nächsten Informationen verarbeitet?


Wenn aber die Bandbreite ausgelastet ist, kann es nicht sein, dass die GPU an sich immer noch Reserven hat, sondern halt nur wegen Überlastung der Schnittstelle pausieren muss? Kann sie in dieser Zeit nicht ihre Shader weiterrechnen?

Wenn ich das richtig verstanden habe, ist doch wohl Bandbreite für die großen Grafikkarten durchaus ein Problem, oder?

[aths]

Original geschrieben von Monger
Sorry, ich bin da leider nicht ganz so fit...

Mit arithmetischer Füllrate meinst du im Prinzip den GPU-Takt, bzw. wie schnell er den Shader abarbeiten kann?!?Ja, ich meinte die arithmetische Rechenleistung. Es gibt zwei Shader-Operationstypen: Texture Ops samplen Texturen und arithmetische Operationen, die (meistens) nur Register verrechnen. Die Register sind dabei in der GPU. Das Register r0 wird am Ende des Shaders automatisch in den Framebuffer geschrieben (sofern der Z-Test "Sichtbarkeit" ergibt.)
Original geschrieben von Monger
Wie funktioniert denn der Austausch über die Bandbreite? Pausiert die Grafikkarte, wenn die Bandbreite überfüllt ist? Gibt es dann einen Puffer, der erst alles rausschreibt, bevor die Grafikkarte wieder die nächsten Informationen verarbeitet?Die GPU selbst arbeitet praktisch immer über einen Cache. Hat der Cache die Daten noch nicht, stockt die GPU, zumindest der Teil, der die Daten braucht. Das gleiche gilt für Schreib-Aufträge. Die Graka burstet immer ganze Cache-Lines, es gibt also auch "Verschitt" (Übertragung eigentlich nicht gebrauchter Daten.) Ein guter Cache hält einige Burstlines vor, die aber im Framebuffer keine Zeile, sondern ein Tile (eine Kachel) darstellen. (Das Lokalitätsprinzip verbessert die Hitrate im Cache.)

Original geschrieben von Monger
Wenn aber die Bandbreite ausgelastet ist, kann es nicht sein, dass die GPU an sich immer noch Reserven hat, sondern halt nur wegen Überlastung der Schnittstelle pausieren muss? Kann sie in dieser Zeit nicht ihre Shader weiterrechnen?Das hängt davon ab. Wenn eine Texture-Op neue Textur-Samples haben will, und die noch nicht im Cache sind, kann die Pipe nix machen. In der Realität sind mehrere Pixel in der Pipe, so dass in den Pausen, in denen für die einen Pixel die Daten geholt (bzw. geschrieben werden) andere Pixel berechnet werden. Ein Shader, der fast nur texturiert, und das noch mit AF, wird u. U. bandbreitenmäßig limitiert. Ein Shader, der sehr viel rechnet, unterfordert das Speicher-Interface dann wieder. (AF selbst geht nicht direkt auf die Bandbreite, sondern auf Texturing-Füllrate. Man muss also gucken, wie das Interface ggü. der Füllrate dimensioniert ist. AF belegt jedenfalls die TMUs für einige Zeit, 16x tri-AF heißt, dass eine TMU bis zu 32x loopen darf. Allerdings kommen die meisten Textur-Samples dann ohnehin aus dem Cache.)

Original geschrieben von Monger
Wenn ich das richtig verstanden habe, ist doch wohl Bandbreite für die großen Grafikkarten durchaus ein Problem, oder? Hängt vom konkreten Shader ab. Bandbreite hat man selten genug, MSAA haut da ja auch noch mal kräftig rein, auch wenn Z- und Color-Compression das teilweise kompensieren.

[BlackArchon]

Gerade habe ich wieder meine Radeon 9500 eingebaut. Da habe ich mal den ArchMark drüber laufen lassen. Der zeigt mir 11,5 GB/s phys. Bandbreite an. Real vorhanden sind aber 17,3 GB/s durch das 256 Bit Speicherinterface.
Das entspräche einer Effizienz von ca. 66%. Passt ziemlich gut zu den 37,5%, die ich weiter oben ausgerechnet habe, oder?

[ow]

.

[BlackArchon]

Jetzt wirds interessant, ich fasse die Ergebnisse zusammen:

Core RAM Archmark theor.
275 270 11,5 GB/s 17,3 GB/s
275 220 10,0 GB/s 14,1 GB/s
350 270 12,2 GB/s 17,3 GB/s
350 220 10,4 GB/s 14,1 GB/s