PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Unterschied von Multisampling und Supersampling?


Madkiller
2002-10-11, 16:58:22
Hallo.

Könnte mir bitte jemand erklären oder nen Link geben, was der genaue Unterschied zwischen Multisampling und Supersampling ist?

Hab zwar schon ein bisschen rumgesucht, habe aber keine eindeutige Erklärung finden können...

MfG Madkiller

LovesuckZ
2002-10-11, 17:03:16
http://www.3dcenter.de/artikel/anti-aliasing/

Madkiller
2002-10-11, 19:45:28
Ah, vielen Dank....

Also:
R8500
2xFSAA ist 2xMS
4xFSAA ist 4xMS

NV20
2xFSAA ist SS
4xFSAA ist 2xMS

NV25
2xFSAA ist 2xMS
4xFSAA ist 2xMS

Ist das so richtig? Wenn nicht, lasst mich bitte nicht dumm sterben...
Der Artikel hat ziemlich viel Stoff, ich hoffe ich habe da nichts falsch verstanden...

Exxtreme
2002-10-11, 19:48:50
Stimmt nicht ganz. Die R8500 kann nur SSAA. Die NV2x-Reihe kann eigentlich nur MSAA, ausser der 4xS-Modus. Der 4xS-Modus ist ein Hybride aus MSAA + SSAA.

Gruß
Alex

Madkiller
2002-10-11, 19:51:13
Mist... doch falsch verstanden.. habs befürchtet :-(
Kann mir dann bitte jemand mit eigenen Worten kurz und bündig erklären wo der Unterschied zwischen SS und MS ist?

Börk
2002-10-11, 20:05:15
Kurz und knapp. Bei SSAA wird das bild in ner höheren auflösung gerendert und dann runterskaliert.
Vorteil: Texturen werden "mit-verschärft" Nachteil: Langsam

Bei MSAA werden mehrere Bilder gerendert, die dann miteinander vermischt werden.
Vorteil: Höhere Geschwindigkeit Nachteil: Keine verbesserung der Texturen

Das SSAA verfahren wird von der Radeon 8500 verwendet, sowie von allen GeForce Karten vor der GeForce3.
MSAA findet bei GF4/3 und der Radeon 9700 verwendung.

Demirug
2002-10-11, 20:05:38
Madkiller,

also AA funktioniert bei Grafikchips dadurch das für jeden Pixel der später auf dem Monitor erscheint mehrere AA-Samples (min. 2) erzeugt werden.

Beim SS wird nur jedes dieser Sample komplett berechnet. Es durchläuft also die komplette Pixelpiepline. Darum ist SS auch sehr belastend für die Fillrate des Chips.

Bei MS-Verfahren wird nun nicht mehr für jedes AA-Sample die komplette Pipeline durchlaufen. Alle Samples eines Pixels die zum gleichen Dreieck gehören werden zusammengefasst und es wird nur ein Farbwert für alle berechnet. Die GF berechnet aber für jedes Sample noch den Z-Wert aus und speichert auch pro Sample einen eigenen Z-Wert. Dadurch lassen sich auch Kanten die durch Überschneidungen von Dreiecken entstehen glätten. Das FAA Verfahren von Matrox das auch eine Form von MS ist beherscht dies nicht.

P.S. Nach Technologie verschoben

Börk
2002-10-11, 20:08:47
Originally posted by Demirug
Madkiller,

also AA funktioniert bei Grafikchips dadurch das für jeden Pixel der später auf dem Monitor erscheint mehrere AA-Samples (min. 2) erzeugt werden.

Beim SS wird nur jedes dieser Sample komplett berechnet. Es durchläuft also die komplette Pixelpiepline. Darum ist SS auch sehr belastend für die Fillrate des Chips.

Bei MS-Verfahren wird nun nicht mehr für jedes AA-Sample die komplette Pipeline durchlaufen. Alle Samples eines Pixels die zum gleichen Dreieck gehören werden zusammengefasst und es wird nur ein Farbwert für alle berechnet. Die GF berechnet aber für jedes Sample noch den Z-Wert aus und speichert auch pro Sample einen eigenen Z-Wert. Dadurch lassen sich auch Kanten die durch Überschneidungen von Dreiecken entstehen glätten. Das FAA Verfahren von Matrox das auch eine Form von MS ist beherscht dies nicht.

P.S. Nach Technologie verschoben
Ist warscheinlich zu Complicated für nen noob, dafür aber wesentlich genauer als mein geschreibsel.

Madkiller
2002-10-11, 20:09:28
Danke @Demirug @burk23,

habs komplizierter gesehen, wies in Wirklichkeit ist. Jetzt ist alles klar.

MfG Madkiller

aths
2002-10-11, 20:11:22
Originally posted by burk23
Kurz und knapp. Bei SSAA wird das bild in ner höheren auflösung gerendert und dann runterskaliert.

Bei MSAA werden mehrere Bilder gerendert, die dann miteinander vermischt werden.Man kann durch das mehrfache Rendern der Bilder ebensogut Supersampling machen, siehe Voodoo.

Börk
2002-10-11, 20:17:45
Originally posted by aths
Man kann durch das mehrfache Rendern der Bilder ebensogut Supersampling machen, siehe Voodoo.
Ich weiss, ich weiss. Aber da ichs nicht zu kompliziert machen wollte habe ich eben das SS verfahren erklärt, das heute am meisten benutzt wird.

Exxtreme
2002-10-11, 20:19:05
Also SSAA berechnet das gesamte Bild in einer höheren Auflösung und dann wird es in die gewünschte Auflösung wieder runtergerechnet. Zieht verdammt viel Bandbreite und Füllrate einer GraKa. Vorteil dieser Massnahme ist, daß diese keine dedizierte HW dazu braucht. Dieses Verfahren ist prinzipiell mit jeder GraKa möglich. Der Nachteil ist, daß nur OrderedGrid Supersampling möglich ist.

Man kann SSAA auch mittels Multisample-Buffer durchführen. Dabei werden mehrere Bilder mit leicht verschobener Geometrie miteinander kombiniert. Vorteil ist, daß man jetzt auch RotatedGrid SuperSampling machen kann, welches bessere Glättungsqualität bei fast geraden Winkeln bringt, da diese meist am meisten stören.

Beim MSAA wirden auch erstmal mehrere Bilder mit verschobener Geometrie genommen. Dann wird aber geprüft ob die AA-Samples an einer Polygonkante liegen. Wenn ja, dann werden diese komplett berechnet. Wenn nein, dann bekommen sie einen einzigen Farbwert zugewiesen. Dieses Verfahren spart enorm Füllrate, da nur die Kanten berücksichtigt werden. Auch Bandbreite wird gespart, da man weniger Speicherzugriffe braucht. Der Nachteil ist, daß Texturen nicht geglättet werden, was sich je nach Spiel mehr oder weniger negativ auf die Bildqualität auswirkt - im Vergleich zum SuperSampling natürlich.

Gruß
Alex

Madkiller
2002-10-11, 20:51:08
Originally posted by Exxtreme
Stimmt nicht ganz. Die R8500 kann nur SSAA. Die NV2x-Reihe kann eigentlich nur MSAA, ausser der 4xS-Modus. Der 4xS-Modus ist ein Hybride aus MSAA + SSAA.


Beim MSAA wirden auch erstmal mehrere Bilder mit verschobener Geometrie genommen. Dann wird aber geprüft ob die AA-Samples an einer Polygonkante liegen. Wenn ja, dann werden diese komplett berechnet. Wenn nein, dann bekommen sie einen einzigen Farbwert zugewiesen. Dieses Verfahren spart enorm Füllrate, da nur die Kanten berücksichtigt werden. Auch Bandbreite wird gespart, da man weniger Speicherzugriffe braucht. Der Nachteil ist, daß Texturen nicht geglättet werden, was sich je nach Spiel mehr oder weniger negativ auf die Bildqualität auswirkt - im Vergleich zum SuperSampling natürlich.

Gruß
Alex

Dann hat also die neue Matrox Graka mit ihrem FAA MS, oder?
Aber es müsste doch auch MS bei FSAA und nicht nur bei FAA geben, oder? Denn mit deinem 2. Absatz, beschreibst du ja nur FAA!

Exxtreme
2002-10-11, 20:55:57
Also MSAA und FAA ähneln sich sehr stark was das Ergebnis angeht. Leider kann FAA keine Schnittkanten von Polygonen glätten, da die Erkennung AFAIK über den Vertexshader läuft während die Erkennung bei NV AFAIK über die Z-Check-Einheiten, welche normalerweise für's HSR zuständig sind, läuft. Auch Stencil-Schatten können per FAA nicht geglättet werden, per NV/ATi-MSAA aber schon.

Gruß
Alex

Madkiller
2002-10-11, 21:01:31
Klar... hab die ganze Zeit gedacht, Polygonkante = Objektkante...
naja... ein Objekt hat ja mehrere Polygone und auch -kanten..

Ist schon faszinierend, wie sich doch AA unterscheidet. Der eine Nutzt SS oder MS. Dann gibts FragmentesAA Full SceneAA und ein AA was nur alle Polygonkanten glättet... NV 20, NV25 und R250 haben unterschiedliche AA-Grids usw.... hab bis vor ein paar Stunden nur was von OGAA oder RGAA gewusst, hätte nie gedacht, daß das Thema so komplex ist!
:O

Demirug
2002-10-11, 21:09:23
Exxtreme,

das FAA von Matrox kann keine Schnittkanten und Stencil glätten. Das liegt aber nicht am FAA sondern an der Art wie es Matrox implementiert hat.

Eine Kantenerkennung kann niemals im VS gemacht werden da die Kanten erst im Triangle Setup entstehen. In der Praxsis sieht das so aus das für jedes zu berechnete Fragment vom Trisetup eine Maske mit durchgereicht wird in welche Sample Buffer das ergebniss der FragmentPipeline (PS) auch wirklich geschrieben werden soll. Liegt der Pixel nicht auf einer Dreiecks-Kante werden natürlich alle Buffer beschrieben. Das ATI/NVIDIA MS erzeugt nun noch zusätzlich eine 2 Maske die angibt welche der AA-Samples den Z, Stencil und Alpha Test überlebt haben.
Diese beiden Masken werden nun verundet und bestimmen welche Buffer beschrieben werden. Unter Umständen gibt es noch eine 3 von Programm vorgegebene Maske die ebenfalls noch verundet werden muss. Xmas hat damit mal rumgespielt.

Das genaue Zusammenspiel von HSR und AA bei den GeForce Karten haben wir bisher noch nicht genau ausgetüftelt.

Exxtreme
2002-10-11, 21:16:57
Wo findet die Erkennung dann statt bei Matrox??

Gruß
Alex

Demirug
2002-10-11, 21:37:36
Originally posted by Exxtreme
Wo findet die Erkennung dann statt bei Matrox??

Gruß
Alex

Sehr wahrscheinlich im Trisetup. Dort ist es am einfachstens zu machen da alle benötigten Daten sowieso dort vorliegen. Es wird dann eben durch jede Pipe noch eine 16 bit Maske mit durchgereicht die angibt welche Samplepositionen relevant sind. Sind alle Bits der Maske gesetzt wird kein AA für diesen Pixel durchgeführt. Es gibt natürlich auch andere Lösungen aber IMO ist das die effektivste.

Quasar
2002-10-11, 21:55:12
Originally posted by Demirug
Das genaue Zusammenspiel von HSR und AA bei den GeForce Karten haben wir bisher noch nicht genau ausgetüftelt.

Hast du dir schon zu den GL_Extreme-Werten Gedanken gemacht?

Demirug
2002-10-11, 21:59:42
Quasar,

ja hab ich ich werden aber ehrlich nicht so richtig schlau daraus. Hast du zufällig die Berechnungsvorschrift von GL_Extreme für diesen Test zur hand?

Ich würde ja einen eigenen Test schreiben mit dem man die HSR effektivität beim AA ausmessen könnte. Hab aber im Moment nur ein DX9 SDK auf dem Rechner.

Quasar
2002-10-11, 22:39:41
Machen wir da (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=34776&perpage=25&pagenumber=3) weiter? Hier ist es n bissel OT.

(Und nein, leider habe ich keine Sources für GL_extreme. Vielleicht weiss Zecki da näheres...)

zeckensack
2002-10-12, 00:08:46
Nope.

Humus' Seite ist im Moment auch unten.

Ich habe das Teil aber noch als Executable hier rumfliegen, und kann euch das auch mailen, wenn's gewünscht wird.

Quasar
2002-10-12, 00:14:38
Danke, die Echse hab ich auch ;) Kannste die nicht n bißchen dekompilieren?

zeckensack
2002-10-12, 00:18:15
Originally posted by Quasar
Danke, die Echse hab ich auch ;) Kannste die nicht n bißchen dekompilieren? Nein, das eher nicht ;)

EXE -> C Decompiler kenne ich leider keine brauchbaren :D

Aber worum geht's denn überhaupt? Sooo schwer zu deuten sind die ausgespuckten Zahlen ja nun auch wieder nicht.

Und nachproggen sollte eigentlich auch flott von der Hand gehen :naughty:

Quasar
2002-10-12, 00:34:21
Es geht um diese Sache von neulich: Z-Test Einheiten der GeForce (was hier reichlich OT ist....Link zum Thread hab ich oben versteckt...).

Demi meint, er wird so ohne Berechnungsgrundlage nicht schlau aus den Zahlen (und ich sowieso nicht...).

Demirug
2002-10-12, 09:17:11
zeckensack,

einen relativen Bezug kann man mit den zahlen schon festlegen, es ging aber um die Frage wie weit das HSR der GF4 durch AA beinflusst wird und dafür müsste man zum Beispiel die Zahlen aus dem Test in was Greifbareres wie die Fillrate umrechnen.

ja ich könnte so einen Test schnell nachproggen. Hab allerdings nur das DX9 Beta SDK auf dem Rechner hier und dem traue ich im Bezug auf das erstellen von DX8 Apps noch nicht zu 100%. Ich werde es aber doch mal angehen. Brauche dann aber ein paar Testpersonen.

MeLLe
2002-10-12, 11:00:39
Originally posted by Demirug
Ich werde es aber doch mal angehen. Brauche dann aber ein paar Testpersonen.
Count me in ;)

Quasar
2002-10-12, 15:12:45
Demirug,

Du kannst zu den Overdraw-Werten auch die entsprechenden Füllraten haben, die spuckt GL_Extreme mit aus, allerdings weiss ich nicht, inwieweit dabei das HSR zum Tragen kommt, sprich, ob dafür ein separater Test durchlaufen wird (sieht eigetnlich nicht so aus) oder ob das aus den ersten sechs Overdraw-Tests errechnet wird.

Demirug
2002-10-12, 15:49:07
Quasar,

Ein eigener Test wird da sicher nicht durchlaufen weil das HSR ja für die API nicht erkenntlich ist.

Ich habe aber inzwischen mein DX9 überredet auch DX8 Apps zu compilieren. Der Test ohne Texturen (nur Vertexfarbe) ist schon fast fertig. Ich werde jetzt noch den Texturesupport einbauen. Da ich aber noch etwas anderes fertig machen muss wird es wohl bis Montag dauern.

Quasar
2002-10-12, 16:00:27
Prima :)

Ich fürchte, was den "eigenen Test" angeht, habe ich mich etwas missverständlich ausgedrückt ;), was ich meinte war: Es wird kein eigener Test nur zur Bestimmung der Füllrate gemacht (zumindest keiner, der mir optisch auffäll, sprich, es ist nichts zu sehen), insofern wird die Füllrate wohl aus den zuvor gewonnenen Werten errechnet.

Ich freue micht dann schonmal auf Montag, wäre schön, wenn du mir dein Programm mailen könntest.