David Kanter de real world technologies nous a indiqué ce matin avoir publié une analyse intéressante concernant les GPU Maxwell et Pascal de Nvidia. Un test ...
Lire la suite ...

...Dingue! Quand on a connus une vielle neogeo ou un CPS1 qui bossaient avec des tiles de 8x8 et palette approprié pour faciliter les opérations de décalages sur les LSI/Blitters custom de l'époque.
Comme quoi!
 

Maxwell 1 est concerné aussi?

C'est le principe même d'une optimisation : cerner quelles primitives sont le plus utilisées / utiles, les optimiser du mieux possible, puis essayer de que les cas généraux puissent se simplifier au maximum vers ces primitives. Un gros triangle, gourmand en mémoire et en calcul, qui ne sera pas forcement utile ? Il "suffit" de le diviser en plus petits triangles pour calculer réellement la partie affichée.

AMD a t'il recours a des optimisations équivalentes ou s'en rapprochant sur ses Radeons ?

Forcément , Si c'est maitre Kanter qui le dit , ça mérite analyse    

Encore un article de grande qualité. Merci pour l'analyse Damien

C'est fou quand même qu'on ne découvre ça que maintenant à propos de Maxwell.

on peut aussi faire des optimisations sur radeon mais faut le coder  
 
ci dessous un post d'un dev sebbbi (https://forum.beyond3d.com/threads/tile-based-rasterization-in-nvidia-gpus.58296/#post-1934106)
 
"Some years ago I did ROP cache experiments with AMD GCN (7970) in order to optimize particle rendering. GCN has dedicated ROP caches (16 KB color, 4 KB depth). In my experiment I split the rendering to 64x64 tiles (= 16 KB). This resulted in huge memory bandwidth savings (and over 100% performance increase), especially when the overdraw was large (lots of full screen alpha blended particles close to the camera). You can certainly get big bandwidth advantages also on AMD hardware, as long as you sort your workload (by screen locality) before submitting it."

Je me demande si ça n'expliquerait pas certains bugs d'affichage spécifiques aux séries 9x0 et 10x0 dans quelques jeux précis, p.ex The Secret World:
 https://pbs.twimg.com/media/CAQMhHcWoAA7ksN.jpg
 
S'il faut gérer ça en driver/software, il y a peut-être un certain nombre de vieux titres affectés...

Salut Damien,
 
Je suis l'autheur du programme utilisé dans l'article que David à écrit. J'ai voulu tester ton hypothèse que les tiles viennent de la rastérisation des gros triangles. J'ai appliqué le même test en affichant la scène Sponza, et j'ai trouvé que les tiles se trouvent même sur les objets composés de petit triangles, comme les feuilles qui enveloppent les piliers.
 
Voici des images de ce test: http://imgur.com/a/6pPha
 
L'image du centre est la plus intéressante. Elle démontre la rastérisation de quelques feuilles, et on peut voir que ça se passe toujours en bloc de tiles.

Serait-ce les avancées sur les Tegra, notamment le K1 puis X, qui les ont poussés à utiliser cela sur tout leur GPU?

Test effectuer sur GCN : https://www.youtube.com/watch?v=w5EWxVwSKI0
 

Je me demande si nVidia profite de ses facilités de "rejouer" la géométrie plusieurs fois et la router vers différents viewports (viewport multicast). Et est-ce que ça marche si les triangles sont rendus dans des draw calls différents ?

 
Mmmm intéressant et étrange ! Sujet à creuser, j'ai toujours tendance à penser que c'est une optimisation opportuniste sur des cas spécifiques et que du tiled-based rendering généralisé n'est pas possible.

Ce thread est intéressant : http://www.neogaf.com/forum/showthread.php?t=1256067
 
On y apprends que ce secret était connu de la concurrence depuis un certain temps déjà, et que les Maxwell/Pascal sont capable de mettre en cache un certain nombre de triangles (dépend du poids des sommets) et même de les réordonner. Au delà de quelques milliers de triangles le tampon est plein et le GPU repasse en mode immédiat classique. Ça expliquerait pourquoi nVidia a subitement mis de gros caches (et un paquet de ROP ?) dans ses GPU...
 
Votre test de tessellation est peut-être influencé par cette capacité, même si le manque d'efficacité des GPU AMD peut s'expliquer de différentes manières .

Je crois que le plus simple est de demander à Nvidia ^^

 
si ils répondent aussi clairement qu'a propos de la compatibilité dx12 de leur gpu ça risque d'être compliqué

oui c'est ce que je me disais en écrivant ma phrase ^^

Tu m'étonnes

D'après certains commentaires du site realworldtech, prenant en exemple les GPU Maxwell, pour chaque tile, il bufferisent les triangles transformés dans un tampon jusqu'à atteindre 64 ko de données. Ensuite, ces 64 ko de géométrie sont rasterisés grosse tile par grosse tile (une grosse tile représentant toujours 512 ko de données (couleur + Z)), et une fois le framebuffer complètement traité, le GPU calcule et met en cache les 64 ko de géométrie suivants, etc.
 
Fondamentalement ça ne change pas grand chose d'un point de vue extérieur au GPU, la rastérisation se fait dans un ordre un peu différent de ce qu'on voit d'habitude mais l'ordre des triangles est bien conservé, et la portion du framebuffer correspondant à une grosse tile est traitée dans le GPU au lieu d'être fait directement en mémoire. D'où les économies importantes de bande passante mémoire en cas d'overdraw.
 
Cette approche ne semble nécessiter que de petites modifications sur les rasterizers et sur les ROP, principalement pour être capable de travailler avec le cache L2, or nVidia avait justement dépoussiéré leurs rasterizers avec Maxwell (conservative rasterization, MSAA très flexible, ...), et ça explique la grosse augmentation de la taille du cache L2, ainsi que les ROP en surnombre s'ils devaient tous écrire directement en mémoire (on sait maintenant que ça n'est pas le cas).

Cool ! Je vais ressortir ma Kyro 2

Apparemment amd va faire pareil avec vega.