PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SSAA-Modi für SLI/CF


boxleitnerb
2010-10-16, 10:24:41
Wenn ich das richtig verstanden habe, gibt es die Möglichkeit, die Sampleberechnungen für SSAA auf mehrere Karten aufzuteilen und die Mikroruckler auf diese Weise praktisch zu eliminieren.

Ist das richtig? Wäre es auch denkbar, einen speziellen globalen SSAA-Profilmodus einzuführen, so dass man profilunabhängig immer annähernd 100% Skalierung und perfekte Bildqualität hat?

Gerade weil SLI/CF ja DIE Prestigeobjekte sind, wieso wird nicht daran gearbeitet, sie dem Kunden so noch schmackhafter zu machen?

AnarchX
2010-10-16, 10:35:28
Wenn ich das richtig verstanden habe, gibt es die Möglichkeit, die Sampleberechnungen für SSAA auf mehrere Karten aufzuteilen und die Mikroruckler auf diese Weise praktisch zu eliminieren.

Ist das richtig?
Vollkommen richtig.
Bei AMD gibt es mit zwei Karten perfekt verteiltes 16x SGSSAA:http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7573174#post7573174 (alles darunter ist Single-Card SGSSAA)

Bei Nvidia kann man diese Ansätze leider vergessen, da die Sample nur minimal vom Ursprungsort entfernt sind und BQ-Gewinn nahezu nicht existiert bei den SLI-SS-Modi.


Wäre es auch denkbar, einen speziellen globalen SSAA-Profilmodus einzuführen, so dass man profilunabhängig immer annähernd 100% Skalierung und perfekte Bildqualität hat?
Man ist immer den Beschränkungen unterlegen, die auch für normale AA-Modi gelten.
Weiterhin ist imo das Problem, dass richtiges SGSSAA auf D3D11-HW günstiger ist, als der Faktor des Modi. Also 2x SGSSAA muss nicht die halbe Leistung kosten. Da ist ein Ansatz mit z.B. 4 Karten die 8x SGSSAA zusammenrechnen, eine sehr ineffiziente Sache.


Gerade weil SLI/CF ja DIE Prestigeobjekte sind, wieso wird nicht daran gearbeitet, sie dem Kunden so noch schmackhafter zu machen?
SLI und CF sind zwar Prestige, aber hier ist man stark auf Kostenreduktion aus. Mehr als Spielekompatibiltät gibt es nicht.
Bei AMD gibt es trotz 320 TMUs bei CF kein vernünftiges AF und bei Nvidia werden die SLI-AA-Modi auch eher stievmütterlich behandelt.

boxleitnerb
2010-10-16, 10:42:24
Man ist immer den Beschränkungen unterlegen, die auch für normale AA-Modi gelten.
Weiterhin ist imo das Problem, dass richtiges SGSSAA auf D3D11-HW günstiger ist, als der Faktor des Modi. Also 2x SGSSAA muss nicht die halbe Leistung kosten. Da ist ein Ansatz mit z.B. 4 Karten die 8x SGSSAA zusammenrechnen, eine sehr ineffiziente Sache.

Was ist da der technische Hintergrund? Ist also eine fast 100%-ige Performancesteigerung bei z.B. 8x SGSSAA bei zwei Karten im Vergleich zu einer nicht drin? Ich würde sagen, 8x SGSSAA ist meistens mehr als ausreichend. Ziel sollte hier sein, es schneller zu machen und nicht zusätzliche Samples draufzuhauen.

AnarchX
2010-10-16, 14:47:52
Meines Wissens nach wäre es teurer auf 4 GPUs 2xSGSSAA zu rechnen, als wenn man 4 GPUs 8x SGSSAA mit angenommener perfekter AFR-Skalierung rechnen lässt.
Das Subsampling bei SGSSAA und der HW-Support für Shader Frequency bei D311(bzw. D3D10.1), erlaubt hier eine effizientere Berechnung als bei Oversampling (wie OGSSAA oder Downsampling).

Natürlich kann man jetzt hier argumentieren, dass AFR bei 4 GPUs teilweise nicht richtig skaliert und zumal man bei kombiniertem SGSSAA auch mehr als 4 GPUs arbeiten könnten, z.B. 8 GPUs an 16x SGSSAA, wo AFR nicht verwendbar ist.

Aber wie schon gesagt, die Realität ist wohl leider eben die, dass Multi-GPU primär zur Generierung des längsten Balken dient.

Spasstiger
2010-10-17, 14:09:58
Lässt man vier GPUs an unterschiedlichen Samples im gleichen Bild werkeln, muss man die komplette Geometrie für das eine Bild durch alle vier GPUs schicken. Arbeiten die GPUs an verschiedenen Bildern, entfällt dieser Overhead, weil dann die Geometrie für jedes Bild nur durch eine GPU geschleust wird.
Bei 16xSGSSAA @ 2 Karten (jeweils 8 Samples pro GPU) ist der Anteil dieses Overhead noch gering, weil die Pixelberechnungen (Ermittlung der Farbwerte) die meiste Rechenzeit in Anspruch nehmen. Bei 4xSGSSAA @ 4 GPUs (jeweils ein Sample pro GPU) wäre der Anteil des Overhead aber schon ziemlich groß und die Skalierung sehr schlecht.