FSAA 4 FREE

[Master prof]

Bei FSAA ist es ja der fall das die grafik anders berechnet wird. Umso Treppeneffekte und ähnliches zu verringern.

Soweit doch richtig?

Ich hab mir jetzt einige gedanken gemacht, im Bereich von Veranstaltungen, Heimkino oder anderen Orten wo Projektionen
eingesetzt werden zum teil so genannte Linedoubler eingesetzt
diese berechnen das Video bild neu umso ein besseres Bild
zu erzeugen.

Es müsste doch möglich sein, dass das fertige Monitorsignal verdoppelt wird und übereinander gelegt wird umso ein besseres
Bild zubekommen.

[StefanV]

Originally posted by Master prof
Es müsste doch möglich sein, dass das fertige Monitorsignal verdoppelt wird und übereinander gelegt wird umso ein besseres
Bild zubekommen.

UARGH...
Sowas will ich nich sehen!

Das Resultat wäre ein Bild, das alles bisher dagewesene in den Schatten stellt...

Allerdings im Negativen Sinne :)

[Doomtrain]

Originally posted by Stefan Payne




Allerdings im Negativen Sinne :)

Völlig vermatscht!!

[ActionNews]

Da würde ich eher auf die FSAA4Free Technik von PowerVR setzen. In deren MBX-Chip wird zumindest FSAA4Free eingesetzt!

CU ActionNews

[ow]

Es gibt kein FSAA4Free.

[robbitop]

@OW
völlig richtig.

Nur könnte, wenn der Chip genug Power hat zB in nich so anspruchsvollen
3D Umgebungen sagen wir bei 1024x786 vieleicht (sagen wir mal der NV30 oder R300) 4xFSAA ohne Performanceeinbrüche schaffen.
Das is noch lang kein FSAA4Free, solang die Chipleistung ausreicht, trotz FSAA im gewünschten Spiel trotzdem noch andere Komponentnen (CPU/AGP) Limitieren zu lassen..natürlich gehört auch ne anständige Bandbreite dazu.

Schraubt man aber die Auflöung oder die Polygonzahl (Doom3) hoch, dann gibt es irgendwann IMMER Performanceeinbrüche, da Chipleistung niemals hoch genug bleiben um in allen 3D Anwendungen unter extremer Belastung noch die CPU als limitierenden Faktor da stehn zu lasssen.

Denn eines ist Fakt: FSAA zieht IMMER an der Bandbreite und Chipleistung, egal wie schnell der Chip oder wie hoch die BAndbreite und wie effizient das FSAA....es wird immer Anwendungen geben, die an das Max des Chips stossen, sobald dies errreicht ist, gibt es dann Performanceeinbrüchhe, bei allen sachen, die dazugeschaltet werden.

Gutes Bsp: GF4Ti4600 schafft in Games wie UT vieleicht nahezu FSAA 4Free, aber in neuen Games eben nicht mehr, ala Doom 3 ..dort wird es dann vieleicht mit neueren Grakas anderes aussehn, jedoch wird FSAA IMMER Performanceeinbrüche zeigen, solange nicht die CPU/AGP limiterend sind, denn es zieht IMMER an der Leistung...nur ist der Einbruch eben Abhängig von Anforderung und Effizienez des FSAA...

[StefanV]

Originally posted by ow
Es gibt kein FSAA4Free.

Kommt auf die Sichtweise an...


Sogesehen war FSAA bei der GF1/2 '4 free', da nur geringer aufwand für die Implementierung...

Wenn man jetzt einen Chip so designt, daß er bei 4xFSAA und 0x FSAA gleich schnell is, dann ist es auch wieder '4 free', aber aus einer anderen Perspiektieve (sollte wohl mal den Duden auf dem 2. Rechner installieren)...

[Exxtreme]

Originally posted by Stefan Payne
Wenn man jetzt einen Chip so designt, daß er bei 4xFSAA und 0x FSAA gleich schnell is, dann ist es auch wieder '4 free', aber aus einer anderen Perspiektieve (sollte wohl mal den Duden auf dem 2. Rechner installieren)...
Wird es kaum geben und wenn doch, dann läuft dieser Chip ohne FSAA entweder nicht mit voller Leistung oder ist stark CPU-limitiert.

Gruß
Alex

[egdusp]

AFAIK schafft der MBX sine FSAA4Free nur danke seiner geringen Auflösung (320x240 ?). Denn 640x480 bei vergleichsweise anspruchslosen 3d Anwendungen, dürfte auch für einen abgespeckten 3d Chip nicht schwer sein. Verlustleistung und Transistorenzahl ist wieder eine andere Frage.

Es wäre eigentlich ganz einfach einen FSAA4Free Chip zu designen. Man müsste nur einen Teil des Chips so designen, dass dieser die Renderingpipeline so enorm ausbremst, dass FSAA ohne Performanceeinbrüche möglich ist. Der MBX macht es ja ähnlich mit dem Display, auch wenn dieses nicht Bestandteil des Chips ist, so doch Bestandteil der MBX Spezifikationen AFAIK.
Bei einem "normalen" Grafikchip müsste man nur z.B. den ramdac oder das Triangel Setup beschneiden.
Mir ist schon bewußt, dass dies im Moment Schwachsinn ist, aber ich halte es nicht für unmöglich, dass in Zukunft bestimmte Operationen eines 3d Chips so langsam sind, dass genug Renderingpower für FSAA4Free übrig bleibt.
Z.b. könnte das von David Kirk "geliebte" perfekte Occulsion Culling so zeitaufwändig sein und den Overdraw so enorm reduzieren, dass man Füllrate und Bandbreite im Überfluss hat.
OK, das funktioniert auch mit Deffered Rendering.
Vielleicht wird ja irgendwann einmal der Ramdac so (relativ) langsam und die 3d Pipeline so schnell, dass die gelieferten 500-1000 fps nicht mehr ausgegeben werden können und man deswegen keinen Gewinn durch Abschaltung des FSAA hat.

Jedenfalls ist FSAA4Free ohne zusätzlichen Bandbreiten oder Füllratenbedarf IMHO nicht möglich.

[GloomY]

Originally posted by ow
Es gibt kein FSAA4Free. Bau einen Tiler mit OnChip Cache, der eine so große Füllrate hat, dass er deutlich speicherbandbreitenlimitiert (<- was für ein Wort ;) ) ist.
Dann bekommst du FSAA for free (d.h. ohne Leistungseinbruch).

Und Füllrate sollte doch kein Problem sein, wenn man einach mal die Anzahl der Renderpipes verzehnfacht...

btw: Wenn es keine Performance kostet, dann nimmt man natürlich Supersampling =) und nv kann sich weiter mit ihrem Multisampling rumschlagen.

[GloomY]

Originally posted by egdusp
Es wäre eigentlich ganz einfach einen FSAA4Free Chip zu designen. Man müsste nur einen Teil des Chips so designen, dass dieser die Renderingpipeline so enorm ausbremst, dass FSAA ohne Performanceeinbrüche möglich ist.Oder die Renderpipeline so schnell machen, dass der Rest im Gegensatz dazu sehr langsam wird. Und das erreicht man einfach, wenn man die Füllrate enorm erhöht.
Originally posted by egdusp
Jedenfalls ist FSAA4Free ohne zusätzlichen Bandbreiten oder Füllratenbedarf IMHO nicht möglich. Füllrate braucht man schon, aber keine zusätzliche Bandbreite (siehe ein Posting oberhalb).

[egdusp]

Originally posted by GloomY

Füllrate braucht man schon, aber keine zusätzliche Bandbreite (siehe ein Posting oberhalb).

Bist du sicher???
AFAIK braucht man beim Supersampling beides und beim Multisampling haupsächlich Bandbreite.
Wenn es so wäre wie bei dir angegeben, woher bitte sollen die Renderingpielines ihre Daten/Informationen nehmen?

mfg
egdusp

[StefanV]

Originally posted by Exxtreme

Wird es kaum geben und wenn doch, dann läuft dieser Chip ohne FSAA entweder nicht mit voller Leistung oder ist stark CPU-limitiert.

Gruß
Alex

Nunja, kommt drauf an, was sich die Chipdesigner einfallen lassen...

Man muß die Pipeline ja 'nur' so Konstruieren, daß sie bei 0x FSAA nicht alle Teile arbeiten.
Gleiches nochmal mit den 'Bandbreiten schonenden Features' und schon hat man FSAA 4 Free...

Nur glaub ich kaum, daß das jemand machen würe, zumindest momentan machts keinen Sinn...

[Eusti]

Originally posted by GloomY Und Füllrate sollte doch kein Problem sein, wenn man einach mal die Anzahl der Renderpipes verzehnfacht...Nee, ist dann auch kaum noch ein Problem. Genausowenig ist Bandbreite ein Problem, wenn man den Chip 2048bit breit anbindet und mit 256MB onChip Cache ausstattet.

Das einzigste was dann ein Problem ist, sind die potentiellen Käufer. Aber wenn man den Chip dann noch für unter 30€ verkauft, ist auch das kein Problem mehr.

[MadManniMan]

@gloomy: ss saugt fillrate und bandwidth, ms im grunde nur bandbreite

[Mave]

Originally posted by Stefan Payne


Nunja, kommt drauf an, was sich die Chipdesigner einfallen lassen...

Man muß die Pipeline ja 'nur' so Konstruieren, daß sie bei 0x FSAA nicht alle Teile arbeiten.
Gleiches nochmal mit den 'Bandbreiten schonenden Features' und schon hat man FSAA 4 Free...

Nur glaub ich kaum, daß das jemand machen würe, zumindest momentan machts keinen Sinn...

Das macht NIE Sinn!!!
Was ist denn daran bitteschön noch 4 Free ???

Du hast zusätzliche Transistoren die du nur für FSAA brauchst ... ergo nichts 4 Free.

Der MBX rendert eben immer mit FSAA darum hat man auch keinen Vergleich wie es ohne wäre. Also nicht FSAA 4 FREE sonder only FSAA

[askibo]

Hab ich zwar schon in einem anderen Thread gepostet aber hier passt es auch:

All ARM 3D graphics acceleration-enabled cores support full-scene anti-aliasing, providing smoother, more realistic graphics at mobile display resolutions. HX cores incorporate FSAA4Free TM technology which minimises the performance impact that anit-aliasing has on rendering


Ist also wie zu erwarten nicht 100% 4free.


Das Zitat stammt übrigens aus einem pdf-Flyer von ARM. ARM hat den MBX Kern lizenziert.

[ow]

Originally posted by MadManniMan
@gloomy: ss saugt fillrate und bandwidth, ms im grunde nur bandbreite

und ss auf der kyro nur fillrate.:D

[Demirug]

Originally posted by ow


und ss auf der kyro nur fillrate.:D

Und wo kommen die Daten für die zusätzlichen Textursamples her?

[ow]

Originally posted by Demirug


Und wo kommen die Daten für die zusätzlichen Textursamples her?


Textur-Cache?

[Demirug]

Originally posted by ow



Textur-Cache?

Zum Teil ja aber nicht alles.

[ow]

Wenn ich einen Frame hochskaliere, dann ändert sich doch an der Texturmenge nichts. Es werden doch nur die Texturen öfters benutzt. Und wenn die mal im Cache liegen, sollte das kaum was ausmachen für den Bandbreitenbedarf.

[Matrix316]

TV-Out = FSAA umsonst ;)

[Demirug]

ow,

ein Chip lädt eine Textur aber nie komplet in den Cache sondern nur was er braucht. Und wenn kein Platz mehr ist muss er wieder was rauswerfen. Wird ein Frame hochskaliere braucht man mehr Werte von der Textur die man mit dem normal skalierten Frame nicht bräuchte. Das passiert natürlich nur wenn die Textur hochauflösend genung ist. Aber sonst mach SS ja nicht so viel sinn.

[egdusp]

Originally posted by ow
Wenn ich einen Frame hochskaliere, dann ändert sich doch an der Texturmenge nichts. Es werden doch nur die Texturen öfters benutzt. Und wenn die mal im Cache liegen, sollte das kaum was ausmachen für den Bandbreitenbedarf.

Warum sollte das nur bei einem DR funktionieren? Ein IMR berechnet die einzelen Pixel (unabhängig von der Sichtbarkeitprüfung, die findett ja auf Dreiecksbasis statt) genauso wie ein DR, also müssten die Texturcaches genauso effizient sein.
Abgesehen davon bin ich Demirugs Meinung. Stell dir vor, du hast viele kleine Dreiecke (was durchaus typisch ist), die aber nur 10-20 Pixel (willkürlicher Wert) ausmachen, jedes dieser Dreiecke hat aber selbst auf der niedrigsten Mipmap Stufe 100 Pixel, dann würde das Laden der kompletten Textur 10x mehr Bandbreite brauchen, als das Auslesen der einzelen Texturwerte.
AFAIK liest der GF3/4 immer 64 bit Blöcke (128bit * 2 / 4xCBMC), kann also für jedes Pixel genau eine 32bit Farb und Z-Wert lesen. Das Laden der kompletten Textur bringt überhaupt nichts.

mfg
egdusp

[StefanV]

Originally posted by Mave


Das macht NIE Sinn!!!
Was ist denn daran bitteschön noch 4 Free ???

Du hast zusätzliche Transistoren die du nur für FSAA brauchst ... ergo nichts 4 Free.

Der MBX rendert eben immer mit FSAA darum hat man auch keinen Vergleich wie es ohne wäre. Also nicht FSAA 4 FREE sonder only FSAA

Naja, 4 free im Sinne von der Performance wäre es dann ja fast :)

Hab ja auch nicht behauptet, daß es sinn macht, wäre aber theoretisch möglich...

Tja, dann weißt du ja in etwa, wie ich es gemeint hab :)

Ein Chip, der explizit für FSAA Designt wurde, der aber auch ohne läuft, nur ist er dann genausoschnell...

[Mave]

Originally posted by Stefan Payne
Ein Chip, der explizit für FSAA Designt wurde, der aber auch ohne läuft, nur ist er dann genausoschnell...


Wenn du das so meintest dann kann ich dir zustimmen das es sogar Sinn machen würde *g*

[GloomY]

Originally posted by Eusti
Nee, ist dann auch kaum noch ein Problem. Genausowenig ist Bandbreite ein Problem, wenn man den Chip 2048bit breit anbindet und mit 256MB onChip Cache ausstattet.
:lol:
Träum weiter. So etwas ist nicht zu bezahlen.
256 MB Cache sind 2.147.483.648 Bit. Bei 6 Transistoren pro Bit (für SRAM Cache) sind das 12 Milliarden Transistoren allein für den Cache...
Originally posted by egdusp
Bist du sicher???
AFAIK braucht man beim Supersampling beides und beim Multisampling haupsächlich Bandbreite.
Wenn es so wäre wie bei dir angegeben, woher bitte sollen die Renderingpielines ihre Daten/Informationen nehmen?

mfg
egdusp
Originally posted by MadManniMan
@gloomy: ss saugt fillrate und bandwidth, ms im grunde nur bandbreite Diese Aussage gilt nur für einen IMR. (btw: Multisampling braucht hauptsächlich Füllrate und fast keine Speicherbandbreite)
Für einen Tiler mit onChip Cache (wie der Kyro) braucht man (fast)keinerlei zusätzliche Speicherbandbreite.

Wofür denn auch?
-Z-Buffer? Gibt's nicht.
-Framebuffer? Nur das entgültige (d.h. fertig anti-Aliased-Bild wird in den Framebuffer geschrieben, das braucht kein einziges Bit mehr als Schreiben des nicht-AA-Bildes)
-Texturzugriffe? Die Texturen brauch' ich genauso für das nicht-AA-Bild wie für das AA-Bild.

Eigentlich müsste man davon ausgehen, dass man hier sogar noch etwas spart, da das LOD-Bias beim AA-Bild kleiner ist (beim SS-AA) und somit weniger Mipmap-Level gebraucht werden.
Das sollte theoretisch die Speicherbandbreitenanforderung sogar noch (geringfügig) senken.

Die andere Frage ist natürlich, wie effizient der Texturecache ist:
Originally posted by Demirug
ow,

ein Chip lädt eine Textur aber nie komplet in den Cache sondern nur was er braucht. Und wenn kein Platz mehr ist muss er wieder was rauswerfen. Wird ein Frame hochskaliere braucht man mehr Werte von der Textur die man mit dem normal skalierten Frame nicht bräuchte. Das passiert natürlich nur wenn die Textur hochauflösend genung ist. Aber sonst mach SS ja nicht so viel sinn. Hmm, selbst wenn man also mehr Texturzugriffe bräuchte, ist das aber dank Texturekompression heutzutage nicht mehr all zu viel und im Verhältnis zu einem IM (der Z- und Framebufferzugriffe in Massen für AA braucht) doch ziemlich gering.

[Demirug]

@GloomY:

Mit Texturkompresion dürfte es wirklich sehr wenig sein. Würde PowerVr MS verwenden könnte sie wirklich FSAA4FREE realisieren mit SS ist es halt FSAA(sehr günstig). Das ist ja neben den Stencilops die zweite große Stärke von PowerVRChips.

[ow]

Originally posted by Demirug
@GloomY:

Mit Texturkompresion dürfte es wirklich sehr wenig sein. Würde PowerVr MS verwenden könnte sie wirklich FSAA4FREE realisieren mit SS ist es halt FSAA(sehr günstig). Das ist ja neben den Stencilops die zweite große Stärke von PowerVRChips.


Weiss einer, wieso PVR beim Kyro kein Multisampling unterstützt?
Immerhin unterstützt er unter OGL die "GL_ARB_multisample" extension. Oder brauchts da noch mehr? Oder muss die OGL App das unterstützen?

[Unregistered]

eigentlich müsste es doch recht "einfach" sein fsaa for free, wenn meine überlegungen richtig sind oder???


bei nvidia´s multisampling wird doch keine fillrate verbraucht, sondern nur bandbreite für die framebuffer...

man könnte aber bereits im chip die 4(oder mehr) subpixel "mischen" und dann nur den antialiased pixel in den buffer schreiben.

dann bräuchte man weder zusätzliche fillrate (da ms) und auch keine bandbreite da ja alles im chip stattfindet

[Xmas]

Leider lässt diese Überlegung noch drei Sachen außer acht die dafür sorgen dass es auch hier nicht "for free" ist:

1. AA -> mehrere Samples pro Pixel -> mehr Z-Checks nötig (auch das kann bei vielen Polygonen limitieren!)

2. AA -> mehrere Samples pro Pixel -> mehr Speicher pro Pixel im OnChip-Buffer benötigt -> kleinere Tiles -> mehr Aufwand beim Geometry Binning

3. AA -> für Kantenpixel müssen mehrere verschiedene Farbwerte berechnet werden -> erhöhter Füllratenbedarf

Und Punkt 3 trifft für alle AA-Verfahren zu! Deswegen kann es kein AA4Free geben. Wenn mehrere Farbwerte gemischt werden sollen, so müssen diese natürlich auch erst mal berechnet werden.

[MadManniMan]

öff, ists dann DOCH so, daß ms jedwelcher art eher(recht wenig) füllrate braucht? obwohl ich das weniger glaube... zumindest sagt das mir meine erfahrung...

moment, das müßte man doch per 4*ms/4*s vergleich mit meiner ti200 rauskriegen...(umtakten core/ram) :naughty:

[GloomY]

Originally posted by Unregistered
eigentlich müsste es doch recht "einfach" sein fsaa for free, wenn meine überlegungen richtig sind oder???


bei nvidia´s multisampling wird doch keine fillrate verbraucht, sondern nur bandbreite für die framebuffer...
Jedes AA-Verfahren rechnet intern mit einer höheren Auflösung und braucht so immer mehr Füllrate als ohne AA.
Multisampling braucht (im Gegensatz zu Supersampling) bei einem IMR kaum mehr Speicherbandbreite.
Originally posted by Unregistered
man könnte aber bereits im chip die 4(oder mehr) subpixel "mischen" und dann nur den antialiased pixel in den buffer schreiben.
Deine Vorgehensweise erfordert, dass man das AA praktisch blockweise ausführt (z.B. 2x2), was aber bei einem IMR leider daran scheitert, dass z.B. der Rasterizer feststellt, dass für einen Block nur ein Pixel des aktuell zu rendernden Dreiecks sichtbar ist und dass die anderen drei Pixel zu einem anderen Dreieck gehören, deren Farbwerte erst viel später berechnet werden.

Originally posted by Xmas
Leider lässt diese Überlegung noch drei Sachen außer acht die dafür sorgen dass es auch hier nicht "for free" ist:

1. AA -> mehrere Samples pro Pixel -> mehr Z-Checks nötig (auch das kann bei vielen Polygonen limitieren!)

2. AA -> mehrere Samples pro Pixel -> mehr Speicher pro Pixel im OnChip-Buffer benötigt -> kleinere Tiles -> mehr Aufwand beim Geometry Binning

3. AA -> für Kantenpixel müssen mehrere verschiedene Farbwerte berechnet werden -> erhöhter Füllratenbedarf

Und Punkt 3 trifft für alle AA-Verfahren zu! Deswegen kann es kein AA4Free geben. Wenn mehrere Farbwerte gemischt werden sollen, so müssen diese natürlich auch erst mal berechnet werden.
zu 1.) Bei einem Tiler dank fehlerndem Z-Buffer kein Problem.
Und die Sichtbarkeitsprüfung kann man imho hervorragend parallelisieren, so dass dort in Zukunft auch kein Flaschenhals entstehen dürfte.

zu 2.) Mehrere Samples pro Pixel müssen nicht zu einer kleineren Tile-Größe führen. Wie man beim Kyro sieht, kann man (auf Grund der geringen Tile Größe) den OnChip Cache auch für die 4-fache Größe (für 2x2 AA) auslegen, so dass das ebenfalls kein Problem darstellt.

zu 3.) Imho ist doch der Aufwand ein x-faches, da die interne Auflösung ja einfach ein x-faches der Ursprungsauflösung ist.
Das sollte doch unabhängig davon sein, ob eine Kante vorliegt, oder?

Oder meintest du beim runterrechnen? Da braucht man aber gar keine Füllrate mehr. Imho durchläuft das doch die Pixelpipeline gar nicht mehr sondern wird mit einer zusätzlichen Logikschaltung runtergerechnet.

[Xmas]

Originally posted by GloomY
Jedes AA-Verfahren rechnet intern mit einer höheren Auflösung und braucht so immer mehr Füllrate als ohne AA.
Multisampling braucht (im Gegensatz zu Supersampling) bei einem IMR kaum mehr Speicherbandbreite.
Das mit der Füllrate ist so eine Sache. Beim MS wird ja nicht die Pipeline x-mal durchlaufen, sondern es wird ein Farbwert für alle bedeckten Samples verwendet. Dieses Farbwert-Duplizieren ist praktisch geschenkt, nur braucht man natürlich auch die Z-Check-Einheiten und die Bandbreite dafür, weswegen NVidia bei 4 Samples die Grenze gezogen hat. Ohne Bandbreitenlimitierung wären noAA und MS (fast, s.u.) gleich schnell.

zu 1.) Bei einem Tiler dank fehlerndem Z-Buffer kein Problem.
Und die Sichtbarkeitsprüfung kann man imho hervorragend parallelisieren, so dass dort in Zukunft auch kein Flaschenhals entstehen dürfte.
Auch ein Tiler hat einen internen Z-Buffer. Klar sollte hier bei einem vernünftig aufgebauten Chip kein Flaschenhals entstehen.


zu 2.) Mehrere Samples pro Pixel müssen nicht zu einer kleineren Tile-Größe führen. Wie man beim Kyro sieht, kann man (auf Grund der geringen Tile Größe) den OnChip Cache auch für die 4-fache Größe (für 2x2 AA) auslegen, so dass das ebenfalls kein Problem darstellt.
Das ist dann IMHO verschenkte Leistung bei noAA. (Obwohl größere Tiles mehr Z-Checks benötigen, sonst sollten sie aber schneller sein)

zu 3.) Imho ist doch der Aufwand ein x-faches, da die interne Auflösung ja einfach ein x-faches der Ursprungsauflösung ist.
Das sollte doch unabhängig davon sein, ob eine Kante vorliegt, oder?
Beim MS ja eben nicht! Für einen Pixel innerhalb eines Polygons wird nur ein Farbwert berechnet. Bei einem Kantenpixel der von zwei oder mehreren Polygonen teilweise bedeckt wird braucht man aber logischerweise auch mehrere Farbwerte, von jedem Polygon einen.

[GloomY]

Sorry, dass ich so lange nichts geschreiben habe, aber ich hatte seit Mittwoch kein Internet mehr. :(

Ok, ich hatte das mit dem Multisampling und der Füllrate falsch verstanden.
Aber ich hab' nochmal 'ne Frage:
Weiss der Chip vom Rasterizer, welche Pixel an den Kanten sind? Wenn ich mich richtig erinnere, bestimmt der Rasterizer doch immer das erste und letzte sichtbare Pixel des Dreiecks in der aktuellen Zeile, oder?
Originally posted by Xmas
Auch ein Tiler hat einen internen Z-Buffer. Klar sollte hier bei einem vernünftig aufgebauten Chip kein Flaschenhals entstehen.Es ging in dem Zusammenhang ja um einen externen Z-Buffer im Graka-RAM (zumindest hatte ich das mit dem "Dank fehlendem Z-Buffer" so gemeint).
Mir ist die Tatsache des internen Z-Buffers durchaus bekannt und bewusst.
Originally posted by Xmas
Das ist dann IMHO verschenkte Leistung bei noAA. (Obwohl größere Tiles mehr Z-Checks benötigen, sonst sollten sie aber schneller sein)
Wieso sollen größere Tiles schneller sein?
Originally posted by Xmas
Beim MS ja eben nicht! Für einen Pixel innerhalb eines Polygons wird nur ein Farbwert berechnet. Bei einem Kantenpixel der von zwei oder mehreren Polygonen teilweise bedeckt wird braucht man aber logischerweise auch mehrere Farbwerte, von jedem Polygon einen. Wenn man an den Kanten von jedem Poligon einen Farbwert braucht, wie bekommt man den denn dann, wenn die einzelnen Dreiecke bei einem IMR nacheinander gerendert werden?
Ich kann doch nicht so lange warten, bis das Dreieck des anderen Poligons gerendert wird, weil ich den Farbwert doch direkt in den Framebuffer schreibe, oder?

[aths]

Originally posted by GloomY
Weiss der Chip vom Rasterizer, welche Pixel an den Kanten sind? Wenn ich mich richtig erinnere, bestimmt der Rasterizer doch immer das erste und letzte sichtbare Pixel des Dreiecks in der aktuellen Zeile, oder?Das ist der "Trick". Multisampling rendert zunächst mal /alles/ in erhöhter Auflösung. Bei 4x á la GeForce steigt die Auflösung um 2x2. Dabei wird pro Pixel nur ein Farbwert gelesen und pro Subpixel geschrieben. Da durch das modifizierte Triangle Setup die Kanten nun nicht in Pixel-Auflösung, sondern in erhöhter 2x2-Auflösung gerastert werden, sind sie nach dem Downfiltering geglättet.

Man könnte auch sagen, es wird normal IR gemacht, wobei Kanten, aber nicht Innenpolygonflächen höher aufgelöst werden. Weil beim Downfiltering der Filter Kernel genau 1 Pixel entspricht, ändert sich im Endeffekt an den Texturen ggü. "No AA" nichts.

[GloomY]

Originally posted by GloomY
Wenn man an den Kanten von jedem Poligon einen Farbwert braucht, wie bekommt man den denn dann, wenn die einzelnen Dreiecke bei einem IMR nacheinander gerendert werden?
Ich kann doch nicht so lange warten, bis das Dreieck des anderen Poligons gerendert wird, weil ich den Farbwert doch direkt in den Framebuffer schreibe, oder? :bonk:
Ist mir mittlerweile auch klar geworden.
Bei MS wird das Bild ja auch erst in größerer Auflösung im Graka-RAM gespeichert und dann runtergefiltert. Dann geht's natürlich =)

Originally posted by aths
Das ist der "Trick". Multisampling rendert zunächst mal /alles/ in erhöhter Auflösung. Bei 4x á la GeForce steigt die Auflösung um 2x2. Dabei wird pro Pixel nur ein Farbwert gelesen und pro Subpixel geschrieben. Da durch das modifizierte Triangle Setup die Kanten nun nicht in Pixel-Auflösung, sondern in erhöhter 2x2-Auflösung gerastert werden, sind sie nach dem Downfiltering geglättet.
Hehe, ist ja wirklich tricky ;)
Originally posted by aths
Man könnte auch sagen, es wird normal IR gemacht, wobei Kanten, aber nicht Innenpolygonflächen höher aufgelöst werden. Weil beim Downfiltering der Filter Kernel genau 1 Pixel entspricht, ändert sich im Endeffekt an den Texturen ggü. "No AA" nichts.
Ich nehme an, du meinst Bildschirmpixel, oder?
Also in dem Fall sind das 2x2-Pixel des vergrößerten Bildes...

[Xmas]

Originally posted by GloomY
Wieso sollen größere Tiles schneller sein?
Geringerer Aufwand beim Geometry Binning. Es kommen zwar auf ein Tile mehr Dreiecke, insgesamt sind es aber weniger "Dreiecksfragmente", was Bandbreite spart. Demgegenüber steht ein höherer Aufwand beim Z-Check, der sich aber leicht parallelisieren lässt.

[GloomY]

Originally posted by Xmas
Geringerer Aufwand beim Geometry Binning. Es kommen zwar auf ein Tile mehr Dreiecke, insgesamt sind es aber weniger "Dreiecksfragmente", was Bandbreite spart. Demgegenüber steht ein höherer Aufwand beim Z-Check, der sich aber leicht parallelisieren lässt.
All zu stark wirkt sich dieser Umstand aber nicht aus (würde ich mal behaupten).

Originally posted by aths
Das ist der "Trick". Multisampling rendert zunächst mal /alles/ in erhöhter Auflösung. Bei 4x á la GeForce steigt die Auflösung um 2x2. Dabei wird pro Pixel nur ein Farbwert gelesen und pro Subpixel geschrieben
Dazu habe ich jetzt aber noch mal ne Frage:
AA soll ja Texturflimmern reduzieren (zumindest SS tut das). Wie sieht das jetzt bei Multisampling aus?

Wenn ich einen Farbwert pro Pixel lese, pro Subpixel in den Zwischenspeicher schreibe und dann runterrechne, dann fließen in den Farbwert des Bilschirmpixels ja nur die Informationen des einen gelesenen Pixels mit ein.
Daher dürfte das Texturflimmern genau so stark (oder genau so wenig) sein, wie ohne AA, oder?

[aths]

Texturflimmert tritt bei vernünftigem MIP Map Bias auch ganz ohne Anti-Aliasing oder anisotrope Filterung nicht auf. Texturen sehen bei MSAA exakt so aus, als würden keine weiteren Maßnahmen ergriffen.

[GloomY]

Hmm, aber es gibt schon Spiele, in denen es massiv Texturflimmern gibt (z.B. GTA3, benutzt das Spiel überhaupt Mipmaps?). Da würde sich (SS-)AA zur Reduktion dieses Effektes durchaus anbieten...

Ich stimme dir allerdings zu, dass es in den meisten Spielen kaum Texturflimmern zu sehen ist.

[loewe]

Nur um noch einmal auf das FSAAforFREE zu sprechen zu kommen.

Es gibt schon Verfahren die zwar nicht was den Hardwareaufwand anbelangt, aber was Füllrate und Bandbreite auf deferred Renderern anbelangt for FREE sind:

Z3 Algorithmus
http://www.research.compaq.com/wrl/people/jouppi/Z3/Z3paper.pdf

Hier ein paar Aussagen von SA aus dem B3D Forum zu dem Thema:


1) The amount of AA work (both computations and memory bandwidth) on a pixel depends on the number of visible fragments in a pixel, rather than the number of samples per pixel (a very big advantage). Hence, it is "adaptive". That is, it spends more memory bandwidth and computation time on pixels with lots of visible fragments (that need more antialiasing), and less time or pixels with fewer fragments (and need little or no geometric AA. This allows a very large number of samples per pixel (say 16, 32, or more) with a relatively small amount of extra memory bandwidth and a bit wider AND computation. If the frame buffer were in on-chip memory, the AA would appear "free" regardless of the number of samples per pixel.

2) It uses much less memory and memory bandwidth for a given quality of AA than supersampling. The memory and memory bandwidth consumption should be small enough to allow the same number of samples per pixel [b]at all resolutions.

If the frame buffer were on chip, you could offer the same high quality AA at all resolutions (say 1600x1200 by 16x) for "free".

3) It can provide order independant transparency for "free".


Was meinen die Profis hier zu Z3?

[Demirug]

Originally posted by loewe
Nur um noch einmal auf das FSAAforFREE zu sprechen zu kommen.

Es gibt schon Verfahren die zwar nicht was den Hardwareaufwand anbelangt, aber was Füllrate und Bandbreite auf deferred Renderern anbelangt for FREE sind:

Z3 Algorithmus
http://www.research.compaq.com/wrl/people/jouppi/Z3/Z3paper.pdf



LOL: Dafür hab ich vor zwei tagen einen Thread aufgemacht:

http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=27872

Z3 ist aber auf keinen Fall for Free es frist immer noch bandbreite und auf einem deferred Renderern würde ich nie Z3 benutzen.

[loewe]

Originally posted by Demirug


LOL: Dafür hab ich vor zwei tagen einen Thread aufgemacht:

http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=27872

Z3 ist aber auf keinen Fall for Free es frist immer noch bandbreite und auf einem deferred Renderern würde ich nie Z3 benutzen.

Tja, war im Urlaub! ;(
Da habe ich noch nicht geschafft alles zu lesen was hier so jeden tag kommt.

Aber warum gerade nicht auf einem deferred Renderer?

[Unregistered]

Originally posted by Demirug

Z3 ist aber auf keinen Fall for Free es frist immer noch bandbreite und auf einem deferred Renderern würde ich nie Z3 benutzen.

Warum?

[Demirug]

Originally posted by loewe


Tja, war im Urlaub! ;(
Da habe ich noch nicht geschafft alles zu lesen was hier so jeden tag kommt.

Aber warum gerade nicht auf einem deferred Renderer?

Das Z3 Verfahren ist sehr interessant weil es zum Beispiel mit nur 2 gespeicherten Samples einen für einen großsteil der Pixel besseres Ergebinisse liefert als 4xMS (sogar 6xMS wird oft überboten). Dafür kann es aber bei anderen Pixel nicht ganz die Qualität erreichen. es ist also eine Kompromisslösung. Dier Kompromiss ist bei einem DR nicht notwendig da er das AA ja direkt beim rendern der Tile (bzw des Chunks) durchführen kann. Z3 ist ein MS Verfahren mit reduziertem Bandbreitenbedarf. Ein DR kann aber MS ohne zusätzliche Bandbreite realisieren. Darum Z3 nicht auf DR.