Problème de rendu 16 bits float + MSAA

Version imprimable

31/07/2006, 21h11
gybe

Problème de rendu 16 bits float + MSAA

J'ai fait certains tests pour évaluer les performances du rendu 16 bits float avec MSAA et ça me semble être très couteux au niveau fillrate.

Voici un test app simple que j'ai écrit.

http://www.filecoast.com/?pg=file&c1...54&c2=5ULNTsFF

En gros je dessine un quad 400 fois sans depth test. Voici les résultats que j'obtient sur une X1800:

25 ms en 16 bits float + MSAA avec 400 quad
0.7 ms en 16 bits float + MSAA avec 1 quad -> ce n'est donc pas un problème de résolution de buffer avec MSAA
11.3 ms en 16 bits float sans MSAA avec 400 quad -> ce qui est acceptable

6.8 ms en 8 bits sans MSAA avec 400 quad
6.9 ms en 8 bits + MSAA avec 400 quad

Ce test ne fonctionne que sur les cartes qui supportent le 16 bits float + MSAA(La série ATI 1K). De plus il est important de désactiver le MSAA dans le control panel auparavant, car il semble y avoir un bug dans le driver lorsque le MSAA est activé sur le back bufffer par défaut.

Je fais du DirectX depuis quelques jours, je ne suis donc pas un pro. Est-ce que vous voyez des raisons qui expliqueraient pourquoi le rendu en 16 bits float est aussi lent?
31/07/2006, 22h26
funkydata

Oui, les render target en fp sont trés gourmandes en fillrate... et cela ne date pas d'hier :? Du fait de leur structure la mémoire qu'occupe ce genre de surface est beaucoup plus grande que les surface en entier.
Par exemple une surface fp16 de 1024x768 prend à peu prêt 13 Mo de ram vidéo... Sans compter que les calculs de rendus sont compliqués par les flottants. Pas étonnant donc que tes perfs chutent autant.
Il existe néanmoins quelques techniques pour optimiser ces calculs tu trouveras trés certainement des infos la dessus en cherchant un peu sur le net.
Avec des techniques de rendu moins récentes que ton test (HDR par exemple) utilisant également des RT en FP on se rend compte trés rapidement que l'on perds environ + de 60% des FPS comparé à une scène utilisant des surfaces standard...

PS : je peux pas tester ton appli j'ai pas une carte suffisamment récente :?
31/07/2006, 23h12
gybe

Je comprends qu'il y a plus de donnée à transférer donc c'est plus lent, mais je suis plus de 3 fois plus lent en MSAA. Je voulais seulement être certain qu'il n'y avait pas de problème d'implémentation.
31/07/2006, 23h36
funkydata

Citation:

Envoyé par gybe

Je comprends qu'il y a plus de donnée à transférer donc c'est plus lent, mais je suis plus de 3 fois plus lent en MSAA. Je voulais seulement être certain qu'il n'y avait pas de problème d'implémentation.

Euuuh... en FP16 tu veux dire non ?
01/08/2006, 00h00
gybe

FP16 + MSAA, les deux ensembles.

Juste FP16 sans MSAA donne des performances acceptables (11.3 ms)

RGBA8 + MSAA donne la même chose que RGBA8 sans MSAA dans mon test app. (Soit environ 6.9 ms) Je m'attendrais à ce que le FP16 réagisse comme le RGBA8, mais ce n'est pas le cas.
01/08/2006, 00h10
funkydata

Citation:

Envoyé par gybe

FP16 + MSAA, les deux ensembles.

Juste FP16 sans MSAA donne des performances acceptables (11.3 ms)

RGBA8 + MSAA donne la même chose que RGBA8 sans MSAA dans mon test app. (Soit environ 6.9 ms) Je m'attendrais à ce que le FP16 réagisse comme le RGBA8, mais ce n'est pas le cas.

Un calcul d'antialiasing sur une surface FP prends beaucoup plus de temps que sur une surface en entier. C'est, en fait, trés compliqué à gérer (apparemment) pour le GPU (Une histoire de difficulté à gérer ces calculs du aux algorithmes de compression des données de ce que j'en sais). C'est d'ailleurs pour ca que l'antialiasing n'est pas possible sur la majorité des cartes lorsque les scènes rendus utilise des rt en fp... le msaa est la pour corriger ce problème.
Aprés niveau perf je n'ai aucun point de comparaison n'ayant jamais mis en place cette technique. Néanmoins les résultats que tu obtiens ne me surprennent pas... Je jeterais un coup d'oeil sur ton code si tu veux voir si quelque chose m'interpelle....
01/08/2006, 00h26
gybe

Si tu trouves quelque chose se serait bien.
Je ne connais pas tellement DirectX.
J'ai appris DirectX rapidement la semaine passée pour évaluer les performances du rendu 16 bits avec MSAA étant donné que ce n'est pas encore disponible en OpenGL
08/08/2006, 21h31
LeGreg

Citation:

Envoyé par gybe

Je comprends qu'il y a plus de donnée à transférer donc c'est plus lent, mais je suis plus de 3 fois plus lent en MSAA. Je voulais seulement être certain qu'il n'y avait pas de problème d'implémentation.

Tout dépend où se situe ton goulot d'étranglement.
SI tu es bandwidth limited (limité en bande passante), si ton application doit transferer quatre fois plus de pixels en mémoire alors ton application tournera quatre fois plus lentement. Si tu es shader limited (limité par la puissance de calcul dans le pixel shader) ou CPU limited, alors l'activation de l'AA peut passer inaperçu. C'est pour ça que les tests synthétiques sont sympas, on peut en tirer des données utile, mais il faut aussi surtout faire des tests sur ton application complète pour savoir où optimiser.

Aussi une chose à se rappeler est que les cartes modernes compressent leurs backbuffer pour tenir compte de la cohérence spatiale apportée par le multisampling. Mais il est tout à fait possible que cette compression ne soit activée qu'en mode 32 bits par pixels et pas en 64 bits pour des raisons d'architecture.

LeGreg
08/08/2006, 22h29
gybe

Le mode 16 bits float devrait seulement avoir un impact sur le bandwidth, donc j'ai fait un test de bandwidth. En théorie il ne devrait pas y avoir de différence de performance au niveau pixel shader et au niveau CPU.

Il est possible que ce soit un problème de compression de backbuffer. Dans ce cas là je ne peux rien y faire. J'ai présenté mon code pour m'assurer que ce ne soit pas un problème avec mon application et donc que les performances que j'obtiens correspondent vraiment à ce que le GPU est capable de faire.
10/08/2006, 00h26
LeGreg

Citation:

Envoyé par gybe

Il est possible que ce soit un problème de compression de backbuffer. Dans ce cas là je ne peux rien y faire. J'ai présenté mon code pour m'assurer que ce ne soit pas un problème avec mon application et donc que les performances que j'obtiens correspondent vraiment à ce que le GPU est capable de faire.

Essaie de calculer la bande passante maximum théorique sans texturing, ou lecture de vertex buffer :
frequence memoire * multiplicateur ddr * nombre de bits sur l'interface / nombre de bits par pixels. (attention parfois le multiplicateur ddr est déjà compté dans la fréquence des specs).
Ça te donnera le nombre de pixel maximum que tu pourras écrire par seconde sans compression. Avec AA sans compression tu dois diviser ce nombre par quatre (pour de l'AA 4x). Avec AA avec compression, le nombre de pixels par seconde maximum reste le même que sans AA (grosso modo).

Mais ça ne dit pas tout, parce qu'ensuite tu es limité par le nombre de ROP.
Chaque rop traite un pixel par cycle en général. Donc multiplie le nombre de ROP par la fréquence du GPU. Ensuite il y a des limitations, par exemple utiliser le blending diminue l'efficacité effective du ROP par deux. Et c'est probable que écrire 64 bits per pixels au lieu de 32 diminue également la capacité du ROP par deux (et plus encore avec blending).

Prends le minimum entre le nombre calculé avec la bande passante et le nombre calculé avec les ROPs et ça te donnera le pic maximal théorique pour un format de pixel donné.

Ensuite à ce nombre il faut soustraire un certain nombre de choses puisque tu n'es jamais efficace à 100% pour une variété de raisons.

Déjà regarde si ce nombre estime à peu près ton frame rate actuel ou pas et dans ce cas c'est bon. Sinon, soit ton application fait des choses supplémentaires par frames, soit tu as atteint une autre limite lié à l'implémentation hardware, mais dans ce cas difficile de dire sans connaitre comment fonctionne le chip.

LeGreg
10/08/2006, 16h24
gybe

merci de ta réponse.