Ti 4200/4400/4600/MX 460/R8500
Tuan le 12 juin 2002 (14 782 lectures)
Le lightspeed memory Architecture : économisons la bande passante !
Commençons par ce qui est devenu par la force des choses le point le plus important dans le design d'une carte graphique haut de gamme : la bande passante mémoire offerte au GPU pour qu'il puisse travailler. C'est un peu le même goulot qui réfrène nos CPU avec la bande passante mémoire offerte par les différents types de ram disponibles. Sauf que ici ce problème est bien plus ennuyeux car les applications ludiques sollicitent très fortement la mémoire embarquée. Ainsi on voit apparaître différentes techniques pour, soit augmenter cette fameuse bande passante, soit en diminuer les besoins… Dans cette nouvelle bataille certains comme Imagination Technologies avec leur fameux processeur Kyro 1&2 (bientôt le 3 ?) ont opté pour la diminution au maximum de ce besoin. Il en résulte des besoins en bande passante réduits à leur minimum. Mais ceci est un cas d'optimisation extrême.
Pour palier à ce retard de la technologie des mémoires vives on peut aussi augmenter les fréquences de fonctionnement de la dite RAM, ou augmenter la largeur de bus (comme l'a annoncé récemment Matrox avec le Parhelia 512). Mais dans l'immédiat le plus simple que l'on puisse faire est d'accroître la fréquence car augmenter la largeur de bus est très coûteux. C'est donc d'une part dans cette voie que nVidia s'est lancé en dotant ses nouvelles cartes de mémoires ultra rapides (type DDR SDRAM bien entendu). Mais ce n'est pas là que le plus intéressant se situe. Ce paramètre dépendant essentiellement du talent des producteurs de ram et non pas des prouesses des ingénieurs de nVidia. Ce qui nous intéresse ici plus particulièrement est ce que nVidia appelle LightSpeed Memory Architecture 2 (LMA2). Derrière ce nom qui fleure bon le marketing nous trouvons l'évolution du LMA1 dont le but est d'optimiser au mieux la bande passante offerte au GPU.
Alors pourquoi tout le monde parle autant de cette bande passante mémoire ? Pourquoi nVidia va jusqu'à mettre au point une technologie compliquée pour traiter au mieux la gestion de cette dernière. Tout simplement car le travail répétitif d'une carte graphique est de manipuler sans arrêt des données pour pouvoir les traiter. C'est ce que l'on appelle un traitement de type dynamic media App. En gros cela est révélateur du type d'application dont il s'agit… On oppose à ce type de fonctionnement le static app. La différence réside dans le fait que la static app travaille sur un lot de données relativement fixe. L'exemple type serait une application bureautique, elle traite le texte qu'on lui soumet mais surtout elle effectue sur ce texte différentes opérations telles que la mise en page, le formatage de la fonte, la vérification d'orthographe, etc. C'est donc typiquement un type d'application qui n'engendre pas tant un gros flux de données qu'un gros flux d'instructions. A contrario les dynamic media app. sont des applications qui font des opérations très répétitives et qui par conséquent nécessitent peu d'instructions comparativement aux static app. Par contre le fait que tout cela soit répétitif nous permet d'exécuter tout cela plus rapidement. C'est donc à un véritable défilé de données que l'on assiste pour un set d'instructions relativement pauvre.
Il est clair que ce type d'applications est largement plus exigeant en trafic mémoire que les static app. La bande passante se trouve donc être très importante. Le type classique de dynamic media app est le jeu ! Les données défilent et leur traitement se résume en gros à transformer les coordonnées des polygones, les éclairer et les texturer mais ce gros du trafic est accaparé par le flux de données et les nombreux accès au Z buffer pour comparer les valeurs. C'est pourquoi on a tant besoin de bande passante dans les jeux et donc dans les cartes graphiques haut de gamme (et de plus en plus dans toutes les applications dites multimédia…). Ce problème a d'ailleurs été abordé par Intel dans l'architecture de son Pentium 4 avec la RD RAM mais aussi de manière encore plus radicale sur la Playstation 2 de Sony où l'architecture de la console est largement conçue pour le défilement des données avec des mémoires et des caches à très très haut débit et une parallèlisation extrême des tâches.
Bref pour remédier à ce type de besoin, nVidia propose différentes optimisations. Commençons par parler du contrôleur mémoire appelé Cross Bar Memory. Le problème que l'on rencontre parfois lors de traitements de scènes complexes est la relative simplicité de certains éléments liée à leur taille réduite. Car une scène complexe comporte une multitude d'objet qui font les détails. Ces objets " occupent " peu de place mais sont très nombreux. Or la mémoire est interfacée en 128 bits sur des puces mémoire de type DDR donc en un cycle les données arrivent au GPU sous forme de blocs de 256 bits. Or cela est trop pour certains petits objets qui occupent bien moins de place et qui occupent tout de même 256 bits ! Il y a donc un gâchis évident de " place ".
Pour illustrer cela j'aurais recourt à l'image de l'autoroute qui dessert une usine. L'usine étant le GPU qui a besoin de " matériel " pour faire son travail à savoir les employés. Ceux-ci arrivent en voiture de format normal (des voitures de taille 256 bits :D) mais ils arrivent seuls dans leur voiture, ce qui a tendance à encombrer l'autoroute qui dessert l'usine mais qui n'augmente pas pour autant le nombre d'employés qui arrive à l'usine et surtout ralenti la cadence de leur arrivée ! Certains arriveront en retard ce qui plombera la rentabilité de l'usine et donc l'efficacité du GPU même si théoriquement l'usine bénéficie de machines performantes mais qui sont inactivent du fait de l'absence des employés. L'idée du Crossbar Memory Controller est analogue au covoiturage. Il s'agit de non pas augmenter la taille de la route (largeur du bus de donnée) mais d'augmenter le nombre d'information arrivant par " fournée " de données de 256 bits. Ainsi les petites données seront codées sur 64 bits ce qui permettra de faire circuler 4 fois plus de données sur une " fournée de 256 bits " ainsi les employés de l'usine n'occupent plus seuls la voiture avec laquelle ils arrivent mais viennent avec des collègues. Cela empêche les embouteillages car cela réduit le nombre de véhicules nécessaires pour acheminer le même nombre d'employés ! Et en plus les employés arrivent plus rapidement car ils arrivent par 4 ! C'est donc le principe du Crossbar Memory mais comme le covoiturage nécessite plus d'organisation entre les employés (untel doit attendre untel et passer chez l'autre) il en va de même pour les transferts mémoire qui sont plus compliqués. Ainsi nVidia incorpore dans son GPU 4 contrôleurs mémoire qui peuvent à eux 4 assurer le convoiement de petites informations sans perte de place ou même une grosse information à laquelle tous les contrôleurs participent. Voilà les bienfaits du covoiturage appliqué aux cartes graphiques…
Autre " truc " pour améliorer les performances : le Quad Cache. Il s'agit de petites mémoires caches au nombre de 4 qui offrent une très grande bande passante et qui sont optimisées pour le type de données qu'elles traitent (les primitives, les vertex, les textures et les pixels). Elles sont, suivant leur rôle, disséminées à travers la structure du GPU. Bien que la plupart de nos lecteurs soient largement au fait de ce qu'est un cache, je vais tout de même m'aventurer à rappeler à quoi ça sert… En fait comme tout cache ceux-ci sont essentiellement dédiés à la lecture, écriture et recherche d'informations rapides qui ont souvent été utilisées lors des précédents calculs et qui ont par conséquent pas mal de chance de réintervenir (surtout dans le cas d'une dynamic app). Leur présence est donc là pour assurer moins d'accès à la mémoire principale de la carte (à savoir les 128 Mo des GF 4 ti) et donc économiser la bande passante. Par la même occasion cela permet de trouver plus vite les informations dont à besoin le GPU. Cependant nVidia ne communique pas plus sur ses caches ce qui nous contraint à en rester là… (avis aux programmeurs pro qui ont affaire avec les GF4ti s'ils peuvent m'aider en m'en disant plus pourquoi pas :D)
Le lossless Z compression porte quant à lui très bien son nom ! C'est une méthode de compression des données du z buffer qui peut permettre une compression de ratio 4:1 le tout en temps réel et de manière transparente car il est implémenté (intégré) au niveau matériel. Qui dit compression dit moins de volume de données à faire transiter, mais pas moins de données car la compression est non destructive ! Du coup il y a économie de bande passante. Il est intéressant de voir que nVidia incorpore une technologie qui est déjà utilisée dans les cartes Radeon de ATI depuis plus d'un an !
Vient ensuite le Z occlusion culling qui est basé sur le principe suivant : le GPU ne calcule pas les pixels qui ne seront pas affichés sur le frame finale. C'est une version bien entendu moins performante que celle utilisée par les Kyro 1&2 mais qui est censée porter ses fruits, et ce dès une complexité z de 2.
Une autre fonction du LMA2 (LightSpeed Memory Architecture 2) est l'auto précharge qui correspond schématiquement au prefetch du CPU (voir article sur le Pentium IV). Cela permet au GPU de demander lui-même à la mémoire de charger automatiquement les données avant qu'il ait à les demander en transfert… cela fait gagner de précieux cycles et permet d'exploiter la bande passante à son maximum.
Et enfin il y a le fast Z clear, qui permet le rafraîchissement rapide du buffer car celui-ci doit être totalement vidé et rempli par des 0 pour que à nouveau il puisse être utilisé. Ainsi on gagne encore un peu de bande passante et de temps !
Ceci clos donc les fonctionnalités du LMA2 qui attirent notre attention. Mais il est à noter qu'à part le Crossbar Memory Controller et le Quad Cache, le reste est un ensemble qui a déjà été utilisé par ATI pour sa première génération de Radeon…
Commençons par ce qui est devenu par la force des choses le point le plus important dans le design d'une carte graphique haut de gamme : la bande passante mémoire offerte au GPU pour qu'il puisse travailler. C'est un peu le même goulot qui réfrène nos CPU avec la bande passante mémoire offerte par les différents types de ram disponibles. Sauf que ici ce problème est bien plus ennuyeux car les applications ludiques sollicitent très fortement la mémoire embarquée. Ainsi on voit apparaître différentes techniques pour, soit augmenter cette fameuse bande passante, soit en diminuer les besoins… Dans cette nouvelle bataille certains comme Imagination Technologies avec leur fameux processeur Kyro 1&2 (bientôt le 3 ?) ont opté pour la diminution au maximum de ce besoin. Il en résulte des besoins en bande passante réduits à leur minimum. Mais ceci est un cas d'optimisation extrême.
Pour palier à ce retard de la technologie des mémoires vives on peut aussi augmenter les fréquences de fonctionnement de la dite RAM, ou augmenter la largeur de bus (comme l'a annoncé récemment Matrox avec le Parhelia 512). Mais dans l'immédiat le plus simple que l'on puisse faire est d'accroître la fréquence car augmenter la largeur de bus est très coûteux. C'est donc d'une part dans cette voie que nVidia s'est lancé en dotant ses nouvelles cartes de mémoires ultra rapides (type DDR SDRAM bien entendu). Mais ce n'est pas là que le plus intéressant se situe. Ce paramètre dépendant essentiellement du talent des producteurs de ram et non pas des prouesses des ingénieurs de nVidia. Ce qui nous intéresse ici plus particulièrement est ce que nVidia appelle LightSpeed Memory Architecture 2 (LMA2). Derrière ce nom qui fleure bon le marketing nous trouvons l'évolution du LMA1 dont le but est d'optimiser au mieux la bande passante offerte au GPU.
Alors pourquoi tout le monde parle autant de cette bande passante mémoire ? Pourquoi nVidia va jusqu'à mettre au point une technologie compliquée pour traiter au mieux la gestion de cette dernière. Tout simplement car le travail répétitif d'une carte graphique est de manipuler sans arrêt des données pour pouvoir les traiter. C'est ce que l'on appelle un traitement de type dynamic media App. En gros cela est révélateur du type d'application dont il s'agit… On oppose à ce type de fonctionnement le static app. La différence réside dans le fait que la static app travaille sur un lot de données relativement fixe. L'exemple type serait une application bureautique, elle traite le texte qu'on lui soumet mais surtout elle effectue sur ce texte différentes opérations telles que la mise en page, le formatage de la fonte, la vérification d'orthographe, etc. C'est donc typiquement un type d'application qui n'engendre pas tant un gros flux de données qu'un gros flux d'instructions. A contrario les dynamic media app. sont des applications qui font des opérations très répétitives et qui par conséquent nécessitent peu d'instructions comparativement aux static app. Par contre le fait que tout cela soit répétitif nous permet d'exécuter tout cela plus rapidement. C'est donc à un véritable défilé de données que l'on assiste pour un set d'instructions relativement pauvre.
Il est clair que ce type d'applications est largement plus exigeant en trafic mémoire que les static app. La bande passante se trouve donc être très importante. Le type classique de dynamic media app est le jeu ! Les données défilent et leur traitement se résume en gros à transformer les coordonnées des polygones, les éclairer et les texturer mais ce gros du trafic est accaparé par le flux de données et les nombreux accès au Z buffer pour comparer les valeurs. C'est pourquoi on a tant besoin de bande passante dans les jeux et donc dans les cartes graphiques haut de gamme (et de plus en plus dans toutes les applications dites multimédia…). Ce problème a d'ailleurs été abordé par Intel dans l'architecture de son Pentium 4 avec la RD RAM mais aussi de manière encore plus radicale sur la Playstation 2 de Sony où l'architecture de la console est largement conçue pour le défilement des données avec des mémoires et des caches à très très haut débit et une parallèlisation extrême des tâches.
Bref pour remédier à ce type de besoin, nVidia propose différentes optimisations. Commençons par parler du contrôleur mémoire appelé Cross Bar Memory. Le problème que l'on rencontre parfois lors de traitements de scènes complexes est la relative simplicité de certains éléments liée à leur taille réduite. Car une scène complexe comporte une multitude d'objet qui font les détails. Ces objets " occupent " peu de place mais sont très nombreux. Or la mémoire est interfacée en 128 bits sur des puces mémoire de type DDR donc en un cycle les données arrivent au GPU sous forme de blocs de 256 bits. Or cela est trop pour certains petits objets qui occupent bien moins de place et qui occupent tout de même 256 bits ! Il y a donc un gâchis évident de " place ".
Pour illustrer cela j'aurais recourt à l'image de l'autoroute qui dessert une usine. L'usine étant le GPU qui a besoin de " matériel " pour faire son travail à savoir les employés. Ceux-ci arrivent en voiture de format normal (des voitures de taille 256 bits :D) mais ils arrivent seuls dans leur voiture, ce qui a tendance à encombrer l'autoroute qui dessert l'usine mais qui n'augmente pas pour autant le nombre d'employés qui arrive à l'usine et surtout ralenti la cadence de leur arrivée ! Certains arriveront en retard ce qui plombera la rentabilité de l'usine et donc l'efficacité du GPU même si théoriquement l'usine bénéficie de machines performantes mais qui sont inactivent du fait de l'absence des employés. L'idée du Crossbar Memory Controller est analogue au covoiturage. Il s'agit de non pas augmenter la taille de la route (largeur du bus de donnée) mais d'augmenter le nombre d'information arrivant par " fournée " de données de 256 bits. Ainsi les petites données seront codées sur 64 bits ce qui permettra de faire circuler 4 fois plus de données sur une " fournée de 256 bits " ainsi les employés de l'usine n'occupent plus seuls la voiture avec laquelle ils arrivent mais viennent avec des collègues. Cela empêche les embouteillages car cela réduit le nombre de véhicules nécessaires pour acheminer le même nombre d'employés ! Et en plus les employés arrivent plus rapidement car ils arrivent par 4 ! C'est donc le principe du Crossbar Memory mais comme le covoiturage nécessite plus d'organisation entre les employés (untel doit attendre untel et passer chez l'autre) il en va de même pour les transferts mémoire qui sont plus compliqués. Ainsi nVidia incorpore dans son GPU 4 contrôleurs mémoire qui peuvent à eux 4 assurer le convoiement de petites informations sans perte de place ou même une grosse information à laquelle tous les contrôleurs participent. Voilà les bienfaits du covoiturage appliqué aux cartes graphiques…
Autre " truc " pour améliorer les performances : le Quad Cache. Il s'agit de petites mémoires caches au nombre de 4 qui offrent une très grande bande passante et qui sont optimisées pour le type de données qu'elles traitent (les primitives, les vertex, les textures et les pixels). Elles sont, suivant leur rôle, disséminées à travers la structure du GPU. Bien que la plupart de nos lecteurs soient largement au fait de ce qu'est un cache, je vais tout de même m'aventurer à rappeler à quoi ça sert… En fait comme tout cache ceux-ci sont essentiellement dédiés à la lecture, écriture et recherche d'informations rapides qui ont souvent été utilisées lors des précédents calculs et qui ont par conséquent pas mal de chance de réintervenir (surtout dans le cas d'une dynamic app). Leur présence est donc là pour assurer moins d'accès à la mémoire principale de la carte (à savoir les 128 Mo des GF 4 ti) et donc économiser la bande passante. Par la même occasion cela permet de trouver plus vite les informations dont à besoin le GPU. Cependant nVidia ne communique pas plus sur ses caches ce qui nous contraint à en rester là… (avis aux programmeurs pro qui ont affaire avec les GF4ti s'ils peuvent m'aider en m'en disant plus pourquoi pas :D)
Le lossless Z compression porte quant à lui très bien son nom ! C'est une méthode de compression des données du z buffer qui peut permettre une compression de ratio 4:1 le tout en temps réel et de manière transparente car il est implémenté (intégré) au niveau matériel. Qui dit compression dit moins de volume de données à faire transiter, mais pas moins de données car la compression est non destructive ! Du coup il y a économie de bande passante. Il est intéressant de voir que nVidia incorpore une technologie qui est déjà utilisée dans les cartes Radeon de ATI depuis plus d'un an !
Vient ensuite le Z occlusion culling qui est basé sur le principe suivant : le GPU ne calcule pas les pixels qui ne seront pas affichés sur le frame finale. C'est une version bien entendu moins performante que celle utilisée par les Kyro 1&2 mais qui est censée porter ses fruits, et ce dès une complexité z de 2.
Une autre fonction du LMA2 (LightSpeed Memory Architecture 2) est l'auto précharge qui correspond schématiquement au prefetch du CPU (voir article sur le Pentium IV). Cela permet au GPU de demander lui-même à la mémoire de charger automatiquement les données avant qu'il ait à les demander en transfert… cela fait gagner de précieux cycles et permet d'exploiter la bande passante à son maximum.
Et enfin il y a le fast Z clear, qui permet le rafraîchissement rapide du buffer car celui-ci doit être totalement vidé et rempli par des 0 pour que à nouveau il puisse être utilisé. Ainsi on gagne encore un peu de bande passante et de temps !
Ceci clos donc les fonctionnalités du LMA2 qui attirent notre attention. Mais il est à noter qu'à part le Crossbar Memory Controller et le Quad Cache, le reste est un ensemble qui a déjà été utilisé par ATI pour sa première génération de Radeon…
Sommaire
- 1. Introduction
- 2. Technologie 1
- 3. Technologie 2
- 4. Quake 3 / Dronez
- 5. 3D Mark 2001 SE
- 6. Remarques
- 7. Overclocking / Benchs
- 8. Conclusion
