Il y a déjà quelques semaines, THFR nous proposait un premier dossier sur Larrabee, en nous expliquant dans le détail de son architecture Hardware. Aujourd'hui, c'est la partie software de Larrabee qui intéresse notre confrère, pour cette dernière et ultime partie consacré au futur presque GPU d'Intel. A lire sur la source.
"Comme nous l’avons vu dans la première partie de notre dossier, Larrabee n’est pas vraiment un GPU. Par conséquent son mode de fonctionnement est assez particulier notamment au niveau de son driver. Le driver d’un GPU traditionnel est en général séparé en deux modules, un module de haut niveau qui communique avec l’API 3D (Direct3D ou OpenGL) et un module de bas niveau commun aux diverses API qui se charge de réaliser la programmation de la puce à proprement parler. En général on retrouve un mapping quasiment 1:1 entre les fonctions de l’API et les fonctions offertes par la puce, la programmation de cette dernière consiste donc à positionner les registres correspondants aux appels d’API aux bonnes valeurs. En soit ça n’est pas très compliqué mais toute la difficulté de faire un bon driver réside dans le fait d’optimiser au mieux le code pour éviter les changements redondants des valeurs de ces registres car cela reste une opération coûteuse, le tout bien sûr sans introduire de bugs ce qui n’est pas une mince affaire quand on voit la tonne d’états différents qui contrôlent le rendu."
"Comme nous l’avons vu dans la première partie de notre dossier, Larrabee n’est pas vraiment un GPU. Par conséquent son mode de fonctionnement est assez particulier notamment au niveau de son driver. Le driver d’un GPU traditionnel est en général séparé en deux modules, un module de haut niveau qui communique avec l’API 3D (Direct3D ou OpenGL) et un module de bas niveau commun aux diverses API qui se charge de réaliser la programmation de la puce à proprement parler. En général on retrouve un mapping quasiment 1:1 entre les fonctions de l’API et les fonctions offertes par la puce, la programmation de cette dernière consiste donc à positionner les registres correspondants aux appels d’API aux bonnes valeurs. En soit ça n’est pas très compliqué mais toute la difficulté de faire un bon driver réside dans le fait d’optimiser au mieux le code pour éviter les changements redondants des valeurs de ces registres car cela reste une opération coûteuse, le tout bien sûr sans introduire de bugs ce qui n’est pas une mince affaire quand on voit la tonne d’états différents qui contrôlent le rendu."
source : THFR
Partagez :
Posté le 31 Mars 2009 à 12:17 par Aurélien Lagny
