R300: FSAA and Alpha

[Quasar]

SMOOTHVISION 2.0 employs another new feature that addresses the multi-sample quality issue with alpha blended (i.e. transparent and translucent) textures. Existing multi-sample implementations can only assign one of two values to each sample – 1 (Foreground) or 0 (Background). Samples falling on alpha blended areas of a texture are always assigned a value of 1, and therefore these parts of the image don’t get anti-aliased. SMOOTHVISION 2.0 has the unique ability to store any value between 0 and 1 for each sample, so it can store alpha values sampled at multiple locations within a pixel along with color values. The alpha values are then blended along with the color values, providing anti-aliasing within alpha blended textures as well as on polygon edges.

What's this? Anti-Aliasing on alpha-edges within a texture? If so, then why does it not work (i.e. the hand-rails in Max Payne)?

[Iceman346]

Wenn sie das ans laufen kriegen lohnt sich SSAA nicht mehr ;)

Frag mich allerdings auch wos bleibt.

[Exxtreme]

SSAA lohnt sich IMHO immer.

[Börk]

Originally posted by Exxtreme
SSAA lohnt sich IMHO immer.
Bei ensprechender Roh leistung ja. Aber leider liefert keiner der heutigen Karten genug davon.

[Demirug]

Quasar, die Erklärung ist irgendwie so schwamig das man damit gar nichts anfangen kann.

Mit MSAA kann man nun mal keine Alphakanten gläten. Denn der Pixelshader erzeugt für alle AA-Samples immer nur ein Alphawert. Dieser kann kann vor oder hinter der Testgrenze liegen. Als Folge werden aber immer entweder alle oder gar keine AA-Samples geschrieben. Das gleiche Problem haben übrigens auch Z-Kanten wenn der Z-Wert im Pixelshader verändert wird. Für alle Sampels nur ein Z-Wert.

Beide Probleme lassen sich nur auf zwei Arten lösen:

1. Wenn der Chip/Treiber erkennt das man mit Alphatests arbeitet muss über das Trisetup ein SS-Anteil hinzugefügt werden. Das heist dann zum Beispiel anstat 1*4 MS zu erzeugen sollte das Trisetup 2*2 MS rauswerfen.


Kein AlphaTest:

11
11

Mit AlphaTest:

12
21


2. Der Chip/Treiber wird so aufgebaut das er beim aktiviertem AA und Alphatest die Pixelfarbe einmal für alle Samples berechnet den Alphawert aber pro AA-Sample bestimmt. Das ist der bessere aber auch viel aufwendigere weg.

[Xmas]

Originally posted by Demirug
2. Der Chip/Treiber wird so aufgebaut das er beim aktiviertem AA und Alphatest die Pixelfarbe einmal für alle Samples berechnet den Alphawert aber pro AA-Sample bestimmt. Das ist der bessere aber auch viel aufwendigere weg.
Dann kann man ja gleich Supersampling machen. Nur den Alpha-Anteil zu berechnen lässt zwar die RGB-Vektor-ALU frei (solange man kein Swizzle macht), aber nur Alpha aus Texturen zu lesen kostet genauso viel wie RGBA.


Ansonsten ist die Erklärung Blödsinn, "providing anti-aliasing within alpha blended textures". Alpha Blending glättet selbst schon optimal. Und jede andere Möglichkeit, mit einem einzigen Alpha-Wert pro Pixel Alpha-Test-Kanten zu glätten bedeutet prinzipiel, den vom Programmierer gewünschten Alpha-Test zu übergehen. Auch keine gute Idee.

[aths]

Originally posted by Exxtreme
SSAA lohnt sich IMHO immer. Vom Aspekt "Qualität pro Leistung" her lohnts sich imo nicht immer.

[Demirug]

Originally posted by Xmas

Dann kann man ja gleich Supersampling machen. Nur den Alpha-Anteil zu berechnen lässt zwar die RGB-Vektor-ALU frei (solange man kein Swizzle macht), aber nur Alpha aus Texturen zu lesen kostet genauso viel wie RGBA.



Xmas, das ist schon richtig. aber man könnte ja zum Beispiel die TMUs so erweitern das sie 4 Alphawerte auf einmal samplen können. Und mit ein paar optimierungen an der Pipeline läst sich im vergleich zum reinen SS auch noch was rausholen. Die frage ist halt nur ob sich der ganze Aufwand nur für Alphakanten lohnt.