Citation:
Oui, il y a le rendu multipasse, mais quand le monopasse ne suffit pas c'est qu'on a plus de travail (et de lectures) à faire et au final le ratio reste à peu près le même, je pense.
Le GPU écrit dans le framebuffer (off-chip) au fur et à mesure de la rasterization en passant par les ROP. Donc oui le contrôleur va se retrouver avec des reads et des writes en même temps. Mais vu les latence tolérées, pour les reads et d'autant plus pour les writes, il peut faire passer alternativement des trains de read et write.
Pour le ratio Read/Write je n'ai pas trouve beaucoup d'infos. Je suis tombe sur des 1/8 a 1/32 pour le ratio calcul/load ce qui est tres superieur a ce qui se trouve dans les CPUs (plus proches de 1:1 a 1:4), mais de ce que Alice et toi dites le ratio est tres nettement superieur a 2/1, donc si on veut envoyer les writes en batch ca force a bufferiser beaucoup d'acces.
Citation:
Dans mon cas je lisais la même adresse exactement plusieurs fois.
Mais même en accès séquentiels dépendants avec stride de 128 à 1024 octets (1 à 8 requêtes), j'ai le même résultat de 315ns.
Quand je passe à un stride entre 2Ko et 32Ko :
- si je viens d'initialiser les données avant de lancer le shader -> 350ns
- sans les initialiser, ou en les initialisant longtemps avant et en faisant des mouvement mémoire entre temps -> 500ns
Du coup je vois une nouvelle hypothèses : ces GPU modernes, ça a de la mémoire virtuelle, donc des TLB... Si j'ai un TLB miss dans le dernier niveau, je dois faire 2 lectures mémoires dépendantes au lieu d'une, donc un passage de 315--350ns à 500--590ns.
Un page miss (ou TLB1 miss?) me coûterait 350-315 = 35ns, un TLB miss 150ns, et je sais pas quoi 90ns?
Je ne savais pas pour la memoire virtuelle, mais effectivement ton hypothese des TLB semble tout a fait raisonable au vu des resultats de ton experience.