Reprise du message précédent :
Un super buffer de 3200*2400...... MDR !
 
faudrait peut-être que tu te décide à comprendre ce qu'il y a dans ton "super buffer de 3200*2400".
 
Tout sauf une bête image en 3200*2400.......
 
Dans ton super buffer en 3200*2400, tu as chaque pixel représenté 4x mais pour reprénsenter une image en 3200*2400... (le tout avec triple ou double buffering).
 
Mais, ce n'est ni généré comme une bête résolution de 3200*2400, ni stocké comme... Ce dont tu nous parle, c'est le vieux multisampling des GF1-2 et Radeon < 9500.

 
C'est marrant mais j'ai affiché ce buffer pas plus tard qu'hier
et il ressemblait drolement a une image en 3200x2400
(sauf que je n'en avais qu'un quart a l'ecran mais bon..)
 
LeGreg

 
Cette "erreur" est typique du supersampling....  

Si ça fonctionne vraiment ainsi, comment ça se fait que les chips de dernières génération (GFFX et R9500 et +) obtiennent des performances similaires en 1600*1200 qu'en 1024*768+FSAA4x+Aniso8x ?
Les perfs en 1600*1200 devraient être largement supérieur vu qu'il n'y a pas d'aniso et que la "résolution équivalente" du 1024 FSAA 4x serait du 2048*1536.

Et le PDF qu'iol 'a sorti traite du smoothvision 1 des R8500 et co....  

 
Il faut que tu te nettoies la tete de toutes tes croyances.
 
En gros le multisampling de nvidia = supersampling de nvidia sauf qu'il n'y a qu'un seul texel lu par pixel a la place d'y en avoir autant que de fragments de pixels. C'est la seule difference entre le Geforce 2 et le Geforce 3, avec le mode quincunx. Il necessite un buffer de taille n fois superieure (n valant 4 pour le HRAA 4x).
 
Le quincunx necessite un buffer de taille deux fois superieure
et utilises 5 fragments par pixels (mais en moyenne ca ne fait qu'un surcout par deux puisqu'il y a redondance des fragments utilises). Si tu as fait de l'analyse d'image tu sais que ce filtre est un filtre qui rajoute du flou alors que le precedent rajoute des artefacts et augmente le risque d'interferences.
 
A+
LeGreg

Euh, c'est pas le flou qui amène des artéfacts par rapport à la réalité de l'image ?    
 
La majorité s'accorde à dire que le Quincunx est flou et s'éloigne d'un vrai FSAA avec plus de samples....  
 
Enfin, si on te suit, il ne devrait pas y avoir de différence de perfs entre un mode supersampling et un mode multisampling.
 
Or, je vais prendre un exemple.
 
Le R3x0 est capable des deus. ATI n'a pas inclu la gestion du supersampling uniquement parce que cette technique ne vaut plus le coût en regard des performances. Et ce n'est pas un pb d'optimisation, puisqu'en fait il s'agit du support du vieux Supersampling (alias Smoothvision 1.0) des R2x0.
 
La demande d'inclusion du supersampling a été faîte à plusieurs reprise par des gens jouant à de très vieux jeux. Et ça a été expliqué concrètement sur le forum de RageD par le responsable de l'équipe de développement des pilotes.
 
==> différence de perfs qui ne vaut pas le coût.
 
Alors, si ce sont les même techniques, pourquoi chez nVIDIA Supersampling et Multisampling se comporteraient areil ?
 
La seule différence entre les deux multisampling, c'est l'agencement des samples (OGMS chez nVIDIA, RGMS chez ATI).

 
Tu n'as pas lu les posts precedents sinon tu aurais la reponse.
Le multisampling de nvidia ne lit qu'un seul texel par pixel.
Et c'est la seule difference entre le supersampling AA et le multisampling AA de nvidia.
 
(je me repete)
 
LeGreg

 
D'où gros manque de précision ? Il faut bien lire les valeurs de chaque sample pour arriver au pixel final ? Sinon, à quoi bon faire un FSAA ?
 
Il faut au moins avoir deux valeur par pixel ! Ou alors, il ne lit qu'une fois et compare au pixel voisin ? Hmmm, bizarre.....
 
ça ferait une image floutée, mais pas antialiasée....

 
Aaaar... gh
je fatigue la..
 
Y'a pas quelqu'un pour prendre la releve ?
 
Bon je vais te donner un cours du traitement du signal en accelere:
Tu as un signal parfait (l'image virtuelle parfaite) que tu echantillones a pas constant (une image en 1600x1200 sans AA).
Seul probleme cette image du fait de sa construction  
a des defauts qui sont des effets d'escaliers sur les bords ainsi que des problemes d'aliasing aussi appelés interferences.
 
Pour eliminer les effets d'escaliers et limiter les interferences, tu devrais appliquer ce que l'on appelle un filtre passe bas sur l'image parfaite avant d'echantillonner. En pratique tu ne peux pas appliquer de filtre passe-bas sur cette image parfaite parce que tu ne peux pas la calculer (sinon on calculerait plutot cette image parfaite plutot que l'image imparfaite). On va donc appliquer le filtre passe-bas sur une "super image" qui se rapproche un peu plus de l'image parfaite parce qu'on a poussé la resolution (en 3200x2400).
Et l'on va reechantilloner (downsampler) en resolution inferieure cette "super image".
Le resultat c'est qu'on aura radouci les bords et repoussé les interférences a des frequences moins visibles. Le cout qu'on a payé c'est le calcul d'une image dans une resolution et a un degre de detail superieur qu'on n'affichera jamais.
 
Ce qui differencie quincunx, skewed et grille droite c'est le filtre qu'on applique a la "super image" avant de downsampler.
La methode de supersampling 4x utilise un simple box filter dont le noyau ne deborde pas du pixel. Il rajoute donc peu de flou supplementaire mais il y a un risque accru d'interferences.
La methode de supersampling quincunx utilise un filtrage triangulaire de biais mais qui deborde legerement du pixel.
Il rajoute donc du flou mais en contrepartie comme le noyau est plus etendu il limite les interferences.
 
Pourquoi on n'affiche pas plutot la super image plutot que l'image downsamplee?  
Comme les gens l'ont constate, le flou apporté par les methodes de filtrage sont plus agreables a l'oeil que les bords en escalier meme a une resolution superieure.
 

 
Ou tu as vu que j'ai dit qu'il n'y avait pas de difference?
Il y en a une et je l'ai citée a 10 reprises.
(je fatigue..)
 
LeGreg

Tres interressant ce petit cours sur le FSAA  

 
Tu as ce que l'on appelle en 3D du mipmapping
c'est a dire que l'on a prefiltres les textures (par niveau en puissance de deux) et qu'on applique la texture en fonction de la distance et de l'angle de vue pour supprimer les interferences. Donc depuis la Voodoo, l'antialiasing a l'interieur des polygones est une realite.
 
Reste le probleme des BORDS des polygones qui eux ne peuvent pas subir de prefiltrage puisque l'on ne sait pas a l'avance comment on va les afficher a l'ecran.
 
Les methodes de supersampling, full scene antialiasing et autres concernent donc essentiellement les bords des polygones mais les methodes style edge antialiasing basé sur de la semi-transparence sont difficiles a mettre en oeuvre donc on utilise plutot du full scene antialiasing.
 
Ceci dit on n'a pas besoin du meme niveau de detail a l'interieur du polygone et sur les bords puisque l'interieur est deja antialiase (enfin pas tout a fait vrai mais on y reviendra).
Donc on peut se satisfaire (temporairement) de ne lire qu'une seule information de texture par pixel plutot que quatre.
Comme les methodes ne sont pas orthogonales on voit parfois des differences legeres (flou supplementaire) et parfois ca pose des problemes plus visibles (pixels shaders, alpha test).
 
LeGreg

Legreg > ton explication est TOUJOURS celle du SuperSampling......
 
En plus, ta façon d'exposer les choses, si l'on considère que tu parle de multisampling, fait croire que le multisampling est le mieux représenté par le Quicunx.
 
Mais avant de parler de Quincunx, parle d'un cas général. Le Quincunx n'est qu'un multisampling + flou
 
Le Quincunx est un AA 2x avec un des sample placé au centre du pixel et avec un filtre qui permet de "recréer" avec plus ou moins de résultat les samples qu'on s'économise. Ok, mais c'est du Quincunx, un multisampling + flou. Pas un multisampling "brut".
 
En 4x, tu as bien génération de 4 samples, chez ATI, comme chez nVIDIA, qui sont blendés pour obtenir le pixel final. (quand ils sont blendés, ça dépend des archis, des méthodes, d'où sûrement les tailles de framebuffer ahurissantes rapportées par nVIDIA).
 
 
 
Il y a une autre méthode, que certains classent dans le supersampling, que d'autres classent dans le multisampling, c'est la méthode 3dfx qui consistait à calculer 4 images légèrement décalées niveau géométrie par rapport au centre du pixel.
 
Ces 4 images étaient blendées. Et il fallait assurément un frame buffer énorme en amont. (Le blending étant effectué au niveau du DAC il me semble).
 
Après, tu as une redondance des samples dans certaines techniques (OGMS) car la grille d'échantillonnage étant droite, il y a beaucoup de répétition d'information, d'où des économies réalisables, en en calculant moins. (si les samples sont aux "coins" des pixels). C'est de là que vient la notion "lecture d'un seul texel par pixel".
 
En fait, tu en lis 4, mais il n'y en a pas tant que cela de calculés. Grâce à la redondance.
 
Dans le cas d'un RGMS, il n'y a pas cette redondance (les samples étant décalés, deux samples adjacents de pixels adjacents ont plus de différences).
 
C'est pour cela qu'une image de RGMS est plus antialiase, sans être floutée comme avec un Quincunx.
 
La dernière étape, insttuée par les nouveaux chips (R3x0 et nV3x, c'est la correction gamma des samples : grâce à cette étape supplémentaire, tu garde les propriétés lissantes de ton FSAA, maisil devient plus franc, moins flou, les lignes semblent plus nettes (sans faire réapparaître d'effets d'escalier).
 
Maintenant, il ne reste plus qu'à savoir, pour chaque archi quand sont blendés chaque sample d'un pixel. Il y a de fortes chances pour que toutes les cartes les blendent après un passage dans le frame buffer. D'où, toujours cette histoire d'"Uber-Buffer".
 
Petite anecdote pour parler de ta capture de framebuffer qui prenait seulement un quart de l'image. C'est une trace du supersampling.
 
Sur Voodoo5, parfois, certains jeux, rares, buggaient avec le FSAA 4x. Et quand ça arrivait, tu avais 1/4 de l'écran avec une image, le reste était noir. Et dans ce quard d'écran, ton image n'était pas antialiasée, et tu voyais uniquement la portion d'image qui était dans ce quart. (je sais pas si je suis clair).
 
Admettons que ton image est divisée en :
 
12
34
 
et ton écran aussi.
 
Tu ne voyais que la portion 1 de l'image, non antialiasée, dans la portion 1 de l'écran.
 
ce bug, je l'ai eu avec Quake 2.
 
Là, on peut dire qu'il y a eu un sacré mélange dans le framebuffer.
 
Reste que c'est intéressant de montrer que le framebuffer, c'est très très sensible comme petite bête. (surtout sous V5 où il était paratgé par deux chips....)
 
 
 
Enfin, bref, stop, faut arrêter de confondre supersampling et multisampling. Markettinguement, on voit surtout le gain de perfs en disant qu'il y a moins d'opérations, mais derrière, elles y sont bien, elles sont organisées différemment et optimisées. Car si tu n'as pas les opérations de génération d'information, tu ne peu pas augmenter l'info apportée par ton pixel. Et ça ne passe pas par une image en xxxxxx*yyyyy !
 
J'ai même un réel doute sur l'utilisation d'un Uber Buffer de cette taille....
 
Sinon, imagine un FSAA 6x sur Radeon 9700 Pro en 1600*1200......... ça ferait 90Mo au bas mot, 90Mo !
 
Explique moi comment je peux jouer détails à fond à Vice City dans cette configuration (j'aurais pu dire Q3, mais il est vieux).
 
UT 2003 tourne honnêtement dans ces règlages (et pas comme si il manquait constamment de mémoire parce que c'est suicidaire de faire tenir les textures en haute qualité dans 30Mo......
 
Bref...... Holà !  

 
Petite question : tu as déjà fait tourner de l'aniso 16x ? En 1024 sans FSAA ça pixellise un peu (pixel popping bonjour). + FSAA 4x ? ça pixel poppise plus. Bizarre......
 
c'est lecture d'une information de texture / sample. Sinon, ça continuerait à pixel popper de la même façon.
 
Les textures dont le canal alpha est > 1bit sont bien antialiasées. (cf UT2033, Serious Sam 2....).
 
Ce sont celles avec 1 bit d'alpha qui posent problème. (pour les raisons que tu avais indiquées).
 
Mais il y a bien gestoin des textures dans le tas.
 
Sinon, ça reviendrait à faire du FAA comme chez Matrox, qui n'antialiase que les fragments avec des bords de polygones.
 
Dans tous les cas, y'a des économies de calcul par rapport à une image de résolution supérieure. Mais les économies ne se font pas si drastiquement. Sinon, on aurait le même style de pertes de perfs que sur Parhelia niveau passage en FSAA : c'est à dire, pertes de perfs basses.

 
j'ai l'impression que ton explication est la même que celle de legreg : seul le filtrage change
 

 
j'aurais plutôt dit l'accumulation buffer (ou T-buffer), le DAC n'étant qu'un composant qui génére le signal VGA à partir du framebuffer final
 

 
 
J'imagine sans problème GTA3 tourner avec 38Mo pour les textures  déjà qu'il se contente de 4Mo de VRAM sur PS2
 
même pour UT2003.. 38Mo pour des textures compressées haute résolution c'est pas mal non?

Pour Vice City, ouais, il doit pas les atteindre...
 
Mais UT 2003, si.
 
En haute résolution il le peut. Tu sais, le répertoire textures, c'est déjà compressé les textures dedans.
 
Et il me semble qu'il peut allouer jusqu'à 160Mo pour les textures dans certaines maps. Et j'imagine mal l'AGP texturing s'occupper de 120 Mo de textures sur ces maps avec seulement 38Mo en mémoire locale.......
 
Pour la V5 : j'avais un doute pour savoir si le blending final était effectué par un des deux VSA-100 ou au niveau du DAC (j'ai pas dit par le DAC).
 
Et nos explications ne sont pas les même.... Ou alors tu as mis au grand jour un gros probème entre Legreg et moi : on ne parlerai pas la même langue.
 
Non, plus sérieusement, je reste convaincu que son explication ne met pas assez en lumière la différence entre SS et MS. A croire que tous les FSAA consistent à faire une résolution n fois plus grande et à downsampler....    

 
c'est le problème qu'on a aussi sur voodoo5 avec un LOD négatif sans fsaa
ou sur n'importe quelle carte en désactivant le mip-mapping
 
 
relis ça:
 

 
ça ne dis pas que les textures sont laissées telle quelles...

Si tu lis UNE information de texture au lieu de 4, ça revient au mê à ne calculer QU'UNE info de texture au lieu de 4.
 
ça revien au même que de ne pas antialiaser cette texture.

 
 
c peut-être le cas d'ailleurs, qui sait

C'est bien pour ça que je l'ai mentionné....  

 
bon ben puisque tu m'as contrer magistralement , je te ressors ça:
 
"Comme les methodes ne sont pas orthogonales on voit parfois des differences legeres (flou supplementaire) "

t'as pas compris toi. Si tu ne lis qu'une information de texture par pixel, ça revient à avoir un bête pixel aliasé. ça ne veut pas dire que c'est le même pixel. Mais le flou implique que tu mélange des infos.
 
Or le DES a son importance. Tu mélange pas une info avec elle même, ça donne la même info.
 
Alors admettons que tu ne tombe pas sur le même texel que celui qu'aurait eu le pixel non antialiasé, tu n'as pas les infos de plusieurs texels quand même, et au final, tu as toujours ton moiré. Il a juste une forme différente. CQFD.

En ce qui me concerne, d'après ce que j'ai compris du fonctionnement des divers FSAA je suis d'accord avec legreg : supersampling ou multisampling implique tous les deux un backbuffer d'une résolution supèrieure. Tous les sous pixels il faut bien les stocker quelque part à un moment ou un autre. La différence c'est que le super sampling calcule l'image a une résolution supèrieure de façon standard, alors que lors du multisampling les sous pixels sont générés "en parallèle". C'est d'ailleurs de là que vient la principale limitation du multisampling par rapport au supersampling : une seule information de texture est partagée par tous les sous échantillons. Le multisampling nécessite un support hardware (chaque sous échantillon dispose d'une valeur Z qu'il faut tester : chaque pixel pipe dispose donc de plusieurs Depth Test Unit) pas le supersampling.
 
Je peux me tromper mais c'est ce que j'ai toujours compris sans vraiment trop me pencher sur la question.
 
legreg : fragment != sous pixel, un fragment dans la terminologie OpenGL c'est l'équivalent d'un pixel dans le pipeline, le pixel n'existant pour sa part qu'au niveau du frame buffer.

 
J'avoue que la terminologie dans ce cadre la est assez flou.
J'ai pris comme definition d'un fragment (pas forcement celle d'opengl), une information coloree qui regroupee avec d'autres fragments participe a la couleur finale du pixel ecran.
(et non pas celui du frame buffer puisqu'il peut y avoir un filter on scan.)
 
LeGreg