R6xx - MSAA-Performance aufgeklärt!? - nur 2xMSAA pro Takt

[AnarchX]

Diesen Link bekam ich gerade, als ich meine Zweifel im B3D-Forum äußerte an der Behauptung, dass die aktuellen R6xx-Chips kein Single-Cycle-4xMSAA können (also die ROPs dafür nur einen Takt benötigen, wie es bei GF8 der Fall ist):


Anyway, no need to respond. You're right in that we should keep it all technical here.

Okay.

What about with colour and Z both enabled? Or is that limited by Z, like previous generations? I was kind of hoping that with a 512-bit bus you'd try to maintain 16 pixels per clock with 4xAA, especially with NVidia pushing 96 samples per clock, but I guess I was just dreaming.

The Z is 32 frags per cycle, regardless of AA mode. That's 2x before in non-AA. I don't disagree that I would of liked to have 4xAA for free, but it's 2xAA for "free".

The last ROP question I have is whether you allow AA with 32-bit per channel rendering. It may be excessive for HDR, but it's nice for variance shadow mapping.
Yes.
http://forum.beyond3d.com/showpost.php?p=1021537&postcount=155

sireric = Eric Demers = Chef Architekt beim R600-Projekt

Kombiniert mit dem Shader-Resolve, der wohl teilweise auch noch etwas suboptimal ist, ist die Leistung die R6xx hier abliefert wohl nicht wirklich verwunderlich...

[Gast]

Warum gehts unter Opengl schnell und gut?

[Coda]

Kann es eigentlich nicht erklären. Auch R5xx schafft nur 2 Cycles pro Takt. Sobald der Shader 4 Takte braucht mit Textur-Filtering (2xTri-AF würde schon reichen) ist das kein Bottleneck mehr.

Warum gehts unter Opengl schnell und gut?
Ich bin da sehr skeptisch. Ich sehe keinen Grund, warum die Hardware dort schneller sein sollte. Imho liegt das eher an dem was die Spiele machen und nicht an OpenGL.

[AnarchX]

Laut robbitop (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5848878#post5848878) scheint wohl zudem auch noch die Farbkompression defekt bzw. nicht vorhanden zu sein.

[Gast]

Komisch wenn alles so schlecht Funktioniert oder Defekt ist, das der R600 so schnell wie der "kleine" G80 ist, oder überhaupt Bilder macht :rolleyes:

[BlackBirdSR]

Komisch wenn alles so schlecht Funktioniert oder Defekt ist, das der R600 so schnell wie der "kleine" G80 ist, oder überhaupt Bilder macht :rolleyes:

Findest du? Überhaupt Bilder macht er deswegen, weil ATI diese Probleme gelöst hat, wenn sie da waren. Sind ja sicherlich die schlimmsten ;)

Und so schnell wie eine GTS ist er deswegen meist, weil ATI den Takt extra so hoch angelegt hat, wie man musste. Ich bin sicher, ATI wäre gerne noch höher gegangen um eine GTX direkt anzugreifen. Aber war leider nicht möglich.

[Gast]

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5293146#post5293146

Was jetzt den Rest der Einheiten betrifft, die ROPs hatten ein "Wehwehchen" das beseitigt wurde, aber es fehlt ihnen ein klein bisschen etwas an Flexibilitaet und deshalb begrenzt man sich auch auf nur 2 loops. Es wird wohl auch kein Schwein merken bei der Bandbreite, aber zu was jede ROP genau faehig ist behalte ich lieber fuer nach dem Launch da es wohl keiner so leicht sagen wird.

Seit Herbst hieß es, dass der R600s ROPs Probleme machen würden, erst mit der letzten Version bekam man in "Griff" (Anführungszeichen beachten!).

Aber es hieß auch, dass es eine weitere Version des R600 geben wird: A15.

[robbitop]

Laut robbitop (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5848878#post5848878) scheint wohl zudem auch noch die Farbkompression defekt bzw. nicht vorhanden zu sein.
Laut Carsten Spille. ;)

[AnarchX]

Warum gehts unter Opengl schnell und gut?
http://www.firingsquad.com/hardware/enemy_territory_quake_wars_performance/page5.asp (Die 1GB XT hat ja sogar 128GB/s)

OGL FurBench - "Shader-Resolving wirklich so unproblematisch?" (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5785018#post5785018)

Komisch wenn alles so schlecht Funktioniert oder Defekt ist, das der R600 so schnell wie der "kleine" G80 ist, oder überhaupt Bilder macht :rolleyes:

Aber auf dem Niveau des kleinen G80 zu sein wäre eher beschämend, wenn es 4x SC-MSAA gewesen wäre zusammen mit den ~100GB/s und angenomen das Resolving im Shader ist wirklich so unproblematisch, wie es in der Theorie sein soll.

Da es nun wirklich nur 2x SC-MSAA sind, erklärt das einiges und gibt eine gewisse Vorrausschau, was mit kommenden Treibern noch möglich ist.

Laut Carsten Spille. ;)
Kann man das eigentlich messen? ArchMark?

[Gast]

Kann man das eigentlich messen? ArchMark?
Das kannst du mit allem messen, was gut komprimierbar wäre. Beispielsweise einem Füllratentest mit einem einfarbigen Full-Screen-Quad. Könnte sein, dass der Archmark das auch macht, ich habe damals ein anderes Programm genommen.


PCGH_Carsten

[robbitop]

Das Problem ist, dass der Output der Z-Tester mit AA ebenso limitieren kann.

[Gast]

BTW, ich glaube, Eric meinte eher, dass nur 2xMSAA hinsichtlich der Z-Tests umsonst sind - nicht aber im globalen Rahmen.

[Gast]

Das Problem ist, dass der Output der Z-Tester mit AA ebenso limitieren kann.
Sollte er laut Eric aber im 2x-Modus nicht.

[Mr. Lolman]

Dementsprechend dürfte theoretisch ein 4xS Modus vgl mit 4xMSAA performancemässig garnicht so ungünstig sein, oder?

[Gast]

Was wird eigentlich unter "for free" verstanden? Auch beim G80 ist 4xAA nicht "for free", selbst 2xAA kostet noch sehr viel Leistung. Es gibt Anwendungsfälle, wo der Leistungsverlust von 2x -> 4x im Bereich der Messtoleranz liegt, genauso gut kann aber 4xAA auch deutlich leistungsfressender sein als 2xAA.
Hat hier jemand schonmal den Verlust von 2xAA -> 4xAA beim r600 in mehreren Anwendungen getestet?

Dementsprechend dürfte theoretisch ein 4xS Modus vgl mit 4xMSAA performancemässig garnicht so ungünstig sein, oder?

Bei der vulminaten Texturleistung der 2900XT? Ich glaube nicht, Jimmy.

LovesuckZ

[Gast]

Was wird eigentlich unter "for free" verstanden? Auch beim G80 ist 4xAA nicht "for free", selbst 2xAA kostet noch sehr viel Leistung. Es gibt Anwendungsfälle, wo der Leistungsverlust von 2x -> 4x im Bereich der Messtoleranz liegt, genauso gut kann aber 4xAA auch deutlich leistungsfressender sein als 2xAA.
Hat hier jemand schonmal den Verlust von 2xAA -> 4xAA beim r600 in mehreren Anwendungen getestet?

LovesuckZ

"For free" natürlich nur im dem Sinne, dass die ROPs diese in einem Takt berechnen können. Damit es wirklich for free wäre, bräuchte man noch verdammt viel Speicherbandbreite.

reunion

[Mr. Lolman]

Bei der vulminaten Texturleistung der 2900XT? Ich glaube nicht, Jimmy.

LovesuckZ

4xS ist doch einfach downgesampeltes 2xAA in ner doppelt so hohen Auflösung. So wenig wie der R600 in hohen Auflösungen verliert und so viel 4xAA tw. kostet kann ich mir denken, dass das ein guter Kompromiss sein dürfte.

[Gast]

Aber auf dem Niveau des kleinen G80 zu sein wäre eher beschämend, wenn es 4x SC-MSAA gewesen wäre zusammen mit den ~100GB/s und angenomen das Resolving im Shader ist wirklich so unproblematisch, wie es in der Theorie sein soll.

Da es nun wirklich nur 2x SC-MSAA sind, erklärt das einiges und gibt eine gewisse Vorrausschau, was mit kommenden Treibern noch möglich ist.


Nein, das erklärt gar nichts. Selbst wenn es so wäre liegt der Bottleck wohl in 95% der Fälle ganz wo anders. Auch ein R5xx schafft nur 2xMSAA "for free" und bricht trotzdem bei weitem nicht so stark ein. Zudem scheint sich Eric Demers hier wie der gast schon anmerkte auf die Z-Tests zu beziehen.

reunion

[Gast]

Und so schnell wie eine GTS ist er deswegen meist, weil ATI den Takt extra so hoch angelegt hat, wie man musste. Ich bin sicher, ATI wäre gerne noch höher gegangen um eine GTX direkt anzugreifen. Aber war leider nicht möglich.

Eine 8800GTX taktet mit 575Mhz bzw. 1350Mhz. Nimmst du da den Durchschnitt, oder wo legst du den Takt des G80 an?

reunion

[robbitop]

Sollte er laut Eric aber im 2x-Modus nicht.
Wenn die Dinger nicht anderweitig beschaeftigt sind, stimmt das. (seit R300 sogar schon)

[robbitop]

Dementsprechend dürfte theoretisch ein 4xS Modus vgl mit 4xMSAA performancemässig garnicht so ungünstig sein, oder?
Das kommt drauf an, was du als unguenstig bezeichnest. 4x MS Samples braeuchten halt einen extra Takt. 2xSS hingegen braeuchte, je nach Game, mal eben hundert Takte mehr.
So stark duerften die ROPs nicht limitieren, sonst wuerde R600 bei 4xMS immerhin noch 8 Pixel pro Takt in Spielen raushauen. Und das tut keine GPU bisher.

Eine 8800GTX taktet mit 575Mhz bzw. 1350Mhz. Nimmst du da den Durchschnitt, oder wo legst du den Takt des G80 an?

reunion

Ausser den ALUs laeuft der gesamte G80 mit 575 MHz. Die ALUs scheinen derzeit keinen Flaschenhals darzustellen.

[Gast]

Ausser den ALUs laeuft der gesamte G80 mit 575 MHz. Die ALUs scheinen derzeit keinen Flaschenhals darzustellen.


Außer den ALUs ist gut. Die ALUs dürften wenn nicht der Großteil dann doch zumindest einen großen Teil des Chips ausmachen. Der hohe ALU-Takt spart einiges an Transistoren, und macht den niedrigen Takt der anderen Einheiten erst möglich. Ich sehe also nicht ein warum ein R600 höher taktet als ein G80. Ganz im Gengenteil.

[Coda]

Takt ist doch völlig irrelevant. Es kommt auf die Verlustleistung an die man für eine gewisse Leistung benötigt, und die ist bei R6xx wohl eindeutig höher - und das trotz feinerer Strukturen. So gesehen ist R600 hoch getaktet.

Zudem sind es ausschließlich die ALUs die double-pumped laufen. Sämtliche Kontrolllogik drumherum und der Rest des Chips laufen auf den 575Mhz. Die ALUs sind zudem custom designs und somit nochmal deutlich kleiner als kompilierte Logik. Ich denke nicht, dass das einen so großen Teil des Chips ausmacht was wirklich den hohen Takt verträgt.

[robbitop]

Außer den ALUs ist gut. Die ALUs dürften wenn nicht der Großteil dann doch zumindest einen großen Teil des Chips ausmachen. Der hohe ALU-Takt spart einiges an Transistoren, und macht den niedrigen Takt der anderen Einheiten erst möglich. Ich sehe also nicht ein warum ein R600 höher taktet als ein G80. Ganz im Gengenteil.
Der groesste Teil mit sicherheit nicht. Die Steuerlogik der ALUs und das Dispatching sind um einiges groesser. Hinzu kommt natuerlich noch der andere Kram (Rasterizer, Front-End, Back-End, Cache, TMUs ect pp)

[Xmas]

Das kannst du mit allem messen, was gut komprimierbar wäre. Beispielsweise einem Füllratentest mit einem einfarbigen Full-Screen-Quad. Könnte sein, dass der Archmark das auch macht, ich habe damals ein anderes Programm genommen.

PCGH_Carsten
Und wie genau willst du so messen dass die Farbkompression nicht funktioniert?

[robbitop]

Wenn die Farbkompression funktioniert, sollte der Einbruch (vorausgesetzt die Z-Tester limitieren nicht) gering sein. Ist aber IMO damit nur sehr vage zu erahnen.

[Gast]

Und wie genau willst du so messen dass die Farbkompression nicht funktioniert?
Indem man die erreichten Füllraten vergleicht kann man das abschätzen.

Erreicht man ohne FSAA eine Füllrate nahe dem effektiven Maximum und mit (verschiedenen Stufen von) FSAA nur noch verschiedene Bruchteile dieses Maximums, liegt der Schluss nahe. Zudem kann man das mit dem Verhalten anderer Chips und dem variieren der Taktfrequenzen von GPU und RAM gegenchecken.

Beweisen kann man es nicht, daher auch die Formulierung "scheint die Farbkompression" in der PCGH.


PCGH_Carsten

[Gast]

Außer den ALUs ist gut. Die ALUs dürften wenn nicht der Großteil dann doch zumindest einen großen Teil des Chips ausmachen.


wohl kaum, die G80-ALUs wurden so designt um möglichst wenig platz zu brauchen und damit ua. die brachiale TMU-leistung zu ermöglichen

[deekey777]

http://forum.beyond3d.com/showpost.php?p=1072729&postcount=354
MSAA color compression geht laut Dave.

[robbitop]

Haette mich auch gewundert, wenn sowas banales nicht funktionieren wuerde und es sogar in den Featurelisten saemtlicher Hersteller steht.

[Gast]

Schön zu hören, am Problem ändert es aber leider nichts - nur an der Ursache.
So scheint es dann mittlerweile die schwache Z-Performance zu sein.


Q

[AnarchX]

Aber diese ist immernoch mehr als doppelt so hoch wie auf R580, hinter welchen R600 zum Teil zurückfällt.

Imo ist das Shader-Resolving wohl auch nicht so unproblematisch, wie es in der Theorie sein sollte bzw. gibt es hier Problem bei der HW-Implementierung.

Wohlmöglich sehen wir hier bei RV670 eine Verbesserung, immerhin wurden hier Änderungen wie das Upgrade auf D3D10.1 und DP vorgenommen, sodass die Wahrscheinlichkeit gut steht, dass man das mögliche Problem gleich mit in Angriff genommen hat (dazu gab es auch eine Andeutung bei Chiphell).

[robbitop]

Ich denke, das AA-Problem kann man wohl schwerlich einem Flaschenhals zuordnen, den man in einem Blockschaltbild findet. Die Z-Leistung ist immerhin nicht schwaecher als die des R580.

[Gast]

Am Besten ab hier: http://forum.beyond3d.com/showthread.php?p=1005246#post1005246
bzw. ab hier http://forum.beyond3d.com/showthread.php?p=1005253#post1005253
Hardware resolve is actually done in the ROP on R600, but only for fully compressed tiles. I write that in the article. So I don't need to state that it was the plan to use the ROP for downsampling, because that's actually what's happening (unless you argue that reading just one value doesn't count, because there was no math involved to weight other samples) for one case.

And I also say that I lean towards the case that the hardware is broken because they have to downsample on the shader core for non fully compressed tiles, even if they can pass the decompressed samples back with a fast path.

So Damien and I say pretty much the exact same thing, just with different language.