1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intel: Anti-Aliasing per CPU mit…

da ist doch was faul...

Das Wochenende ist fast schon da. Zeit für Quatsch!
  1. Thema

Neues Thema Ansicht wechseln


  1. da ist doch was faul...

    Autor: DerBlup 25.07.11 - 13:21

    ...oder?

    Das normale FSAA funktioniert doch als Supersampling. Die GPU rendert in einen größeren Buffer als den gesetzten Videomode und downsamples dann das gesamte Bild auf die gesetzte resolution. Sozusagen ein bilinearer Filter auf ein Bild mit höherer Auflösung.
    Wie kann dann die Rechenzeit mit der Szenenkomplexität steigen? Das habe ich hier zum ersten mal gelesen. Die Rechenzeit beim FSAA steigt mit der Resolution, nicht mit der Szenenkomplexität.
    Es sei denn, die lassen die Szene mehrmals rendern, was ja beim FSAA NICHT passiert.

    Ich hab nix über das Intel-Verfahren gelesen, aber im Prinzip handelt es sich doch wohl um ein Verfahren, das lediglich einen Filter über das fertige Bild jagt, es also weichzeichnet, so wie das sowieso schon viele Games in einem Postprocessing nur mit der GPU tun.

    Weiss jemand da mehr?

  2. Re: da ist doch was faul...

    Autor: The Sen 25.07.11 - 14:17

    Beim Supersampling werden mehr Fragmente/Pixel berechnet als nötig. Die Komplexität für das Rendern eines Pixels ist von der Szene und anderen Faktoren abhängig. Dann werden die mehreren Pixel zu einem zusammengerechnet.

    Das Filtern passiert am fertigen Bild. Der Aufwand ist konstant pro Pixel. Für jedes Pixel wird die Nachbarschaft angeschaut und der Farbwert des Pixels angepasst.

    Hilft das? :)

  3. Re: da ist doch was faul...

    Autor: nate 25.07.11 - 15:07

    > Das normale FSAA funktioniert doch als Supersampling.

    Ja und nein.

    Ja, denn FSAA ist Supersampling der gesamten Szene, so wie du es beschrieben hast, und nicht von der Szenenkomplexität abhängig.

    Nein, denn FSAA ist nicht "normal", sondern eher die Ausnahme. Typischerweise wird nicht FSAA ("Full Screen Anti-Aliasing"), sondern MSAA ("Multisample Anti-Aliasing") benutzt, was vereinfacht(!) gesagt nur an Dreieckskanten mehrere Samples generiert. Bei steigender Szenenkomplexität werden aber die Dreiecke zunehmend kleiner, der Anteil der Pixel, der Kanten enthält, steigt, und MSAA wird ineffizienter. Daher steigt die benötigte Rechenzeit (nicht in den Shader-Cores, wohl aber in den MSAA-Resolvern in den Rasterendstufen) mit steigender Szenenkomplexität an.

    > Ich hab nix über das Intel-Verfahren gelesen, aber im Prinzip handelt es
    > sich doch wohl um ein Verfahren, das lediglich einen Filter über das
    > fertige Bild jagt, es also weichzeichnet

    Naja, MLAA ("Morphological Anti-Aliasing") und FXAA ("Fast Approximate Anti-Aliasing") sind schon deutlich mehr als nur Weichzeichner. Da werden Kanten detektiert und es wird versucht, diese möglichst gut zu rekonstruieren.

    > so wie das sowieso schon viele
    > Games in einem Postprocessing nur mit der GPU tun.

    Sooo viele Spiele, die MLAA/FXAA benutzen, gibt es meines Wissens noch nicht -- diese Technologien sind sozusagen der neuste Schrei, seit gerade mal einem halben Jahr oder so.

  4. Re: da ist doch was faul...

    Autor: /mecki78 25.07.11 - 15:43

    DerBlup schrieb:
    --------------------------------------------------------------------------------
    > Das normale FSAA funktioniert doch als Supersampling.

    FSAA wird im ganzen Artikel überhaupt nicht erwähnt. FSAA ist überhaupt kein "echtes" Verfahren. FSAA heißt nur, dass die ganze Szene Anti-Aliased wird, aber wie das faktisch geschieht sagt FSAA nicht. Im Artikel ist lediglich die Rede von MSAA.

    MSAA bedeutet, die ganze Szene wird mit ihrer finalen Auflösung gerendert, aber jeder finale Bildpunkt wird dadurch gebildet, dass mehrfach "gesampled" wird mit leicht unterschiedlichen Koordinaten und dann ein Durchschnittswert ermittelt wird. Wobei hier in der Regel die Textur nur *einmal* gesampled wird, lediglich die "depth" und "stencil" Werte werden mehrfach gesampled. Das führt dazu, dass *Kanten* zwar "weicher" werden, aber eben *nur* Kanten; innerhalb großer Flächen passiert kaum etwas und die Texturen bleiben knackig scharf. Das kann auch ein Nachteil sein, denn wenn Texturen "hochskaliert" werden mussten, dann können jetzt innerhalb der Texturmuster Alias Effekte entstehen.

    Was du meinst, heißt SSAA, Super Sampling Antia-Aliasing. Das lässt sich auf zwei Arten machen: Entweder man macht MSAA und sampled aber auch die Textur mehrfach oder man zeichnet das Bild mit einer höheren Auflösung (wodurch alles, Textur, Stencil und Depth automatisch mehrfach gesampled wird, man muss ja mehr Bildpunkte mit Farbe füllen) und skaliert das ganze dann "weich" herunter. Kommt beides auf ziemlich das gleiche raus und kostet auch beides gleich viel Rechenzeit, allerdings ersteres braucht nur Framebuffer in der finalen Auflösung, letzteres aber in einer 2-, 4- oder 8-fachen Auflösung und der Speicherverbrauch eines Framebuffers wächst "quadratisch" mit der Auflösung. Daher kann man bei ersteren Verfahren auch 32-faches AA machen (kostet zwar Rechenzeit ohne Ende, aber ist theoretisch machbar), aber 32-faches SSAA nach letzterem Verfahren ist unmöglich, der Framebuffer würde bei keiner aktuellen Grafikkarte in den Speicher passen.

    > Wie kann dann die Rechenzeit mit der Szenenkomplexität steigen?

    Das, was am Ende ein Punkt ist, kann sich aus einer Texture und einem Polygon (d.h. einem Depth und einem Stencil Wert) errechnet haben; oder es hat sich aus 32 Texturen und 32 Polygonen (mit 32 Depth und Stencil Werten) errechnet. Und du fragst ernsthaft, warum letzteres teurer zu berechnen ist als ersteres? Und wenn du jetzt 4-faches SSAA machst, dann muss das alles 4-fach berechnet werden. Entweder 4-fach eine Textur und ein Polygon, oder 4-fach 32 Texturen und 32 Polygone.

    Machst du hingegen das AA am Ende auf das fertige Bild, das nicht mehrfach gesampled wurde (weder pro Pixel noch durch Zeichnen bei einer höheren Auflösung), dann hängt der Aufwand maßgeblich nur von der Auflösung ab. Wobei, so ganz wahr ist das nicht. Intel's Algorithmus sucht nach "Kanten" und zeichnet diese dann weich. Je mehr Kanten er findet, desto mehr muss er weich zeichnen, d.h. auch der hängt von der Komplexität ab; nur kostet das Weichzeichnen weniger Rechenzeit als das Finden der Kanten und das Finden wiederum hängt maßgeblich davon ab, wie viele Daten "durchsucht" werden müssen, was wohl maßgeblich von der Auflösung abhängt, würde ich jetzt einfach mal behaupten.

    /Mecki

  5. Re: da ist doch was faul...

    Autor: /mecki78 25.07.11 - 15:47

    nate schrieb:
    --------------------------------------------------------------------------------
    > Ja, denn FSAA ist Supersampling der gesamten Szene, so wie du es
    > beschrieben hast, und nicht von der Szenenkomplexität abhängig.

    Das zweifele ich aber stark an. SSAA (FSAA ist kein konkretes Verfahren, sondern nur ein Oberbegriff) heißt, dass du für jeden finalen Pixel am Schirm intern 4 oder 8 Pixel hast errechnen müssen. D.h. die Zeit, die ein Pixel braucht wird vervierfacht oder verachtfacht und jetzt stell dich bitte noch mal hin und sag mir, das die Zeit einen Pixel zu berechnen nicht von der Komplexität der Szene abhängt.

    Bei Intels verfahren hingegen, wird weder Multisampling betrieben noch SSAA, es wird ganz normal, bei der normalen Auflösung gezeichnet ganz ohne AA (d.h. die Zeit, die man so oder so gebraucht hätte für das Frame) und erst ganz am Ende werden Kannten gesucht und weich gezeichnet.

    /Mecki

  6. Re: da ist doch was faul...

    Autor: nate 25.07.11 - 16:17

    > Das zweifele ich aber stark an. SSAA (FSAA ist kein konkretes Verfahren,
    > sondern nur ein Oberbegriff) heißt, dass du für jeden finalen Pixel am
    > Schirm intern 4 oder 8 Pixel hast errechnen müssen.

    ... oder weniger. Bei hoher Szenenkomplexität, also mehr und dafür kleineren Dreiecken, tendenziell eher weniger.

    > D.h. die Zeit, die ein
    > Pixel braucht wird vervierfacht oder verachtfacht

    Eben nicht. Das ist bei MSAA der Fall, denn sobald auch nur ein Subpixel eines Pixels (genauer: eines Quads aus 2x2 Pixeln, was die Sache noch schlimmer macht) sichtbarer Teil des Dreiecks ist, wird der komplette Pixelshader durchgerechnet.

  7. Re: da ist doch was faul...

    Autor: DerBlup 26.07.11 - 14:39

    [quote]
    Bei Intels verfahren hingegen, wird weder Multisampling betrieben noch SSAA, es wird ganz normal, bei der normalen Auflösung gezeichnet ganz ohne AA (d.h. die Zeit, die man so oder so gebraucht hätte für das Frame) und erst ganz am Ende werden Kannten gesucht und weich gezeichnet.
    [/quote]

    Kanten suchen und dann postprocessen kann man doch ganz gut auf der GPU machen. Ich habe mal für einen Comic-Shader damit experimentiert. Wenn man das selber machen will, müssen halt alle in einen custom ZBuffer rendern und der postprocess liest diese Daten dann aus und entscheidet, ob der Pixel in einer Kante liegt. Funktioniert nicht fehlerfrei, für sowas wie Antialiasing aber dicke ausreichend.
    Allerdings muss man ein paar Annahmen über die Szene machen, um weniger Fehler zu haben.
    Sowas hat ganz gute Ergebnisse (ausprobiert):
    [code]

    sampler zBufferTexture= //ungefilterter ZBuffer im Screenspace
    sampler_state
    {
    Texture = <tex_zbuffer>;

    MipFilter = POINT;
    MinFilter = POINT;
    MagFilter = POINT;

    AddressU = Clamp;
    AddressV = Clamp;
    };


    sampler zBufferTextureFiltered= //gefilterter ZBuffer, diesselbe Textur, anderer Filter
    sampler_state
    {
    Texture = <tex_zbuffer>;
    MinFilter = Linear;
    MagFilter = Linear;
    MipFilter = Linear;

    AddressU = Clamp;
    AddressV = Clamp;
    };


    float4 PostProcessPS(float2 Tex : TEXCOORD0 ) : COLOR0
    {
    float z= tex2D(zBufferTexture, Tex).r; // ungefilterter ZBuffer
    float zf= tex2D(zBufferTextureFiltered, Tex).r; // gefilterter zB

    float4 ret;

    if (abs(z-zf) > 0.3f) // ist ne Kante, 0.3 enthält eine Annahme über die Größenverhältnisse in der Szene
    {
    ret= color; // Kantenfarbe
    }
    else ret= tex2D(BBCopy, Tex); // return normale BB-Color

    return ret;
    }
    [/code]

    Würde mich mal interessieren, ob die GPU-Firmen mittlerweile sowas verwenden.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Metabowerke GmbH, Nürtingen
  2. RENK AG, Augsburg
  3. Universitätsklinikum Münster, Münster
  4. Stadt Hildesheim, Hildesheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Unternehmen: Die richtige Software für ein Projekt finden
IT-Unternehmen
Die richtige Software für ein Projekt finden

Am Beginn vieler Projekte steht die Auswahl der passenden Softwarelösung. Das kann man intuitiv machen oder mit endlosen Pro-und-Contra-Listen, optimal ist beides nicht. Ein Praxisbeispiel mit einem Ticketsystem.
Von Markus Kammermeier

  1. Anzeige Was ITler tun können, wenn sich jobmäßig nichts (mehr) tut
  2. IT-Jobs Lohnt sich ein Master in Informatik überhaupt?
  3. Quereinsteiger Mit dem Master in die IT

Verschlüsselung: Auch das BKA nutzt Staatstrojaner nur ganz selten
Verschlüsselung
Auch das BKA nutzt Staatstrojaner nur ganz selten

Die neue Zitis-Behörde soll bei Staatstrojanern eine wichtige Rolle spielen. Quantennetzwerke zum eigenen Schutz lehnt die Regierung ab.
Ein Bericht von Friedhelm Greis

  1. Staatstrojaner-Statistik Aus 368 werden 3
  2. Untersuchungsbericht Mehrere Fehler führten zu falscher Staatstrojaner-Statistik
  3. Staatstrojaner Ermittler hacken jährlich Hunderte Endgeräte

Wissen für ITler: 11 tolle Tech-Podcasts
Wissen für ITler
11 tolle Tech-Podcasts

Die Menge an Tech-Podcasts ist schier unüberschaubar. Wir haben ein paar Empfehlungen, die die Zeit wert sind.
Von Dennis Kogel