|
[[File:SIMD2.svg|centre|vignette|Unités de calculs SIMD.]]
===La hiérarchie mémoire===
La hiérarchie mémoire des GPUs est assez particulière, que ce soit au niveau des caches ou de la mémoire, parfois des registres. On y trouve souvent des caches dédiés aux textures ou aux vertices, et les GPUs récents contiennent aussi des caches L1 et L2 de faible taille.
[[File:Memory.svg|centre|vignette|upright=2.0|Hiérarchie mémoire typique d'un GPU récent.]]
====Les caches====
Les cartes graphiques sont censées avoir peu de caches. Les premières cartes graphiques n'avaient qu'un cache de texture et éventuellement un cache de vertices, avec un cache d’instruction. Cette situation a perduré durant très longtemps, l'usage de caches plus complexe n'étant pas vraiment utile sur les cartes graphiques. Ce n'est que par la suite, quand les GPU commencèrent à être utilisés pour du calcul généraliste (scientifique, notamment), que la situation changea. Les GPU utilisèrent alors de plus en plus de caches généralistes. La hiérarchie mémoire des GPU ressemblent de plus en plus à celle des CPU, du moins pour les caches. On y trouve toute une hiérarchie de caches, avec des caches L1, L2, L3, etc.
====Les Local Store====
En plus d'utiliser des caches, les processeurs de flux utilisent des local stores, des mémoires RAM intermédiaires entre la RAM principale et les caches/registres. Typiquement, chaque processeur de flux possède sa propre mémoire locale. Ces local stores peuvent être vus comme des caches, mais que le programmeur doit gérer manuellement. La faible capacité de ces mémoires, tout du moins comparé à la grande taille de la mémoire vidéo, les rend utile pour stocker temporairement des résultats de calcul "peu imposants". L'utilité principale est donc de réduire le trafic avec la mémoire centrale, les écritures de résultats temporaires étant redirigés vers les local stores.
[[File:Cuda5.png|centre|vignette|upright=2.0|Local stores d'un GPU.]]
====Processeurs de flux====
Beaucoup de processeurs graphiques actuels sont des '''processeurs de flux''', aussi appelés ''stream processors''. Ce sont des processeurs SIMD qui utilisent une hiérarchie de registres. Voici à quoi ressemble l'architecture d'un Stream Processor :
[[File:Stream processor.png|centre|vignette|upright=2.0|''Stream processor'']]
Les Streams Processors ont plusieurs bancs de registres. On trouve d'abord quelques '''Local Register File''', directement connectés aux unités de calcul. Plus bas, ces Local Register Files sont reliés à un Register File plus gros, le '''Global Register File''', lui-même relié à la mémoire. Ce Global Register File sert d'intermédiaire entre la mémoire RAM et le Local Register File. La différence entre ce Global Register File et un cache vient du fait que les caches sont souvent gérés par le matériel, tandis que ces Register Files sont gérés via des instructions machines. Le processeur dispose ainsi d'instructions pour transférer des données entre les Register Files ou entre ceux-ci et la mémoire. Leur gestion peut donc être déléguée au logiciel, qui saura les utiliser au mieux. Outre son rôle d'intermédiaire, le Global Register File sert à transférer des données entre les Local Register Files, où à stocker des données globales utilisées par des Clusters d'ALU différents. Les transferts de données entre la mémoire et le Global Register File ressemblent fortement à ceux qu'on trouve sur les processeurs vectoriels. Un Stream Processor possède quelques instructions capables de transférer des données entre ce Global Register File et la mémoire RAM. Et on trouve des instructions capables de travailler sur un grand nombre de données simultanées, des accès mémoires en Stride, en Scatter-Gather, etc.
[[File:Stream processor registers.png|centre|vignette|upright=2.0|Registres d'un ''Stream processor''.]]
On peut se demander pourquoi utiliser plusieurs couches de registres ? Le fait est que les Streams Processors disposent d'une grande quantité d'unités de calcul. Et cela peut facilement aller à plus d'une centaine ou d'un millier d'ALU ! Si on devait relier toutes cas unités de calcul à un gros Register File, celui-ci serait énorme, lent, et qui chaufferait beaucoup trop. Pour garder un Register Files rapide et pratique, on est obligé de limiter le nombre d'unités de calcul connectées dessus, ainsi que le nombre de registres contenus dans le Register File. La solution est donc de casser notre gros Register File en plusieurs plus petits, reliés à un Register File plus gros, capable de communiquer avec la mémoire. Ainsi, nos unités de calcul vont aller lire ou écrire dans un Local Register File très rapide.
===Mitigation de la latence mémoire===
| 