Interview d'ATI software

Publié le 13/10/2004 par
Imprimer
L´année dernière, votre concurrent a éprouvé quelques problèmes d´efficacité avec une architecture complexe en partie parce qu´ils ont sous-estimé l´importance d´un compilateur de shaders efficace. Avez-vous déjà commencé à vous préparer pour éviter que cela se produise avec votre prochaine génération de GPU ?
ATI est conscient de la nécessité d´un compilateur de shaders sophistiqué pour parvenir à extraire les meilleures performances possibles hors de ses architectures depuis un long moment et a investi les ressources nécessaires dans une équipe consacrée au compilateur au sein de son processus de développement. Notez que même les premiers compilateurs et optimiseurs de shader que nous avons sortis avec l´architecture de R3XX ont été très performants grâce au travail placé dans leur développement avant même que les premières puces sortent des fonderies. Il y a une impression générale que nos architectures sont simples à programmer et n´ont pas besoin d´un compilateur sophistiqué. Bien qu´il y ait une part de vérité là-dedans, un compilateur sophistiqué est nécessaire pour extraire les meilleures performances même hors d´une architecture simple à programmer comme la nôtre.

Le traitement des pixel shaders en 4 phases et le nombre de lectures de texture dépendantes est une limitation de vos GPU DX9 actuels. C´était un très bon compromis pour la génération R300 étant donné qu´il permet de simplifier l´implémentation hardware et de vous aider à conserver une très bonne efficacité. Pensez-vous que ce compromis est toujours aussi bon avec les GPU de génération R400 qu´il l´était avec la génération R300 ? Est-ce que ça ne risque pas de devenir une limitation significative avec les moteurs 3D de la prochaine génération ?
Avant de prendre les décisions autour du R400, nous avons rencontré de nombreux développeurs pour leur demander quelles limites de la génération R300 ils voyaient comme problématiques pour leurs jeux de prochaine génération. Nous n´avons entendu aucun développeur se plaindre de cette limite et indiquer qu´elle serait un frein à la pleine utilisation des possibilités de DX9. En fait, une des plaintes les plus courantes que nous avons entendues était le besoin d´une meilleure solution de compression des normal maps, qui est l´une des choses nous avons essayé d´améliorer avec le 3Dc de la série R400.

Les développeurs travaillent maintenant la plupart du temps en HLSL. Le compilateur HLSL ne semblent pas aussi futé qu´il pourrait l´être quand il doit prendre en compte des limitations matérielles telles que le nombre de lectures de texture dépendantes. En HLSL c´est facile pour un développeur d´oublier les particularités du matériel et de se retrouver dans l´impossibilité de trouver un profil de compilation pour vos GPU actuels. Les instruisez-vous encore pour être sûr qu´ils penseront aux particularités de votre matériel au moment d´écrire les shaders ou pensez-vous que c´est mieux pour leur créativité de travailler à un niveau d´abstraction plus élevé par rapport au hardware ?
C´est clairement mieux que les développeurs travaillent à un niveau plus élevé d´abstraction par rapport au hardware. Les limitations du hardware actuel doivent leur être masquées via les compilateurs et les outils autant que possible. Notre groupe de relations développeurs travaille constamment avec eux pour s´assurer qu´ils trouvent des moyens de contourner toutes les difficultés auxquelles ils peuvent faire face avec notre matériel actuel. Notez qu´ATI fournit également de façon pro active des outils tels que RenderMonkey et Ashli pour aider les développeurs. Notez que l´outil Ashli  indique aux développeurs un moyen pour masquer efficacement toutes les limites connues de notre matériel au niveau des shaders, y compris les lectures de texture dépendantes, les limites d´instruction, de registres etc.. etc... Nous démontrons avec cet outil que nous pouvons faire fonctionner des shaders complexes qui sont longs des plusieurs centaines d´instructions et utilisent des lectures de texture dépendantes à multi niveaux, et ce à une vitesse adaptée au temps réel.

3DMark05 donne un avantage à votre concurrent étant donné qu´avec leurs produits il utilise par défaut un mode de rendu différent et propriétaire (DST/PCF). Avez-vous quelque chose à dire à ce sujet ?
Ma vision de 3DMark est qu´il est censé fournir une manière fiable et impartiale de comparer les performances supposées de différentes configurations et de différentes cartes graphiques dans les futurs jeux DirectX 9. Il es logique de penser que la seule manière de fournir une comparaison équitable est de s´assurer que chaque carte examinée rend la même image, ou emploie au moins les mêmes méthodes et techniques de rendu. Ainsi je remets en cause la décision de Futuremark d´utiliser une technique de shadow map différente selon le type de matériel installé, particulièrement quand celle utilisée sur notre matériel est plus gourmande en puissance de calcul et visuellement plus séduisante que la méthode DST/PCF utilisée avec le matériel concurrent. Heureusement, Futuremark a fourni une option pour désactiver les ombres DST/PCF et forcer toutes les cartes graphiques à employer la même méthode de rendu. Ceci permet de produire des résultats plus comparables.

Y a-t-il du neuf au sujet de votre driver OpenGL ? Êtes-vous d´accord avec le fait qu´il ne semble pas être aussi bon que votre driver Direct 3D ? Il nous a été indiqué que vous travailliez à une réécriture complète mais qu´elle ne serait pas terminée avant un bon moment. Est-ce vrai ?
Laissez-moi d´abord expliquer le processus d´évolution des drivers chez ATI. Notre driver se compose de beaucoup de composants. Par exemple : 2D, multimédia, 3D, etc... Au fil du temps, chacun de ces composants est sujet à un grand nombre de modifications. À un certain point, faire davantage de modification à un composant n´est plus possible car il devient difficile de maintenir et d´optimiser le code. À ce point nous décidons habituellement de démarrer une réécriture partielle ou complète du composant. Dans notre industrie, chaque composant a besoin d´une réécriture majeure tous les 2 à 6 ans.

Vos lecteurs doivent comprendre que de telles activités sont complexes, coûtent chères et prennent un temps considérable. L´objectif n´est pas seulement de créer un composant fonctionnellement correct mais est aussi de concevoir une architecture fortement optimisée qui satisfasse les besoins actuels et futurs des systèmes d´exploitation et des systèmes de certification.

Notre composant OpenGL est sujet à un tel processus d´évolution comme le sont d´autres composants de notre driver.

Pour finir, laissez-moi assurer vos lecteurs que nous avons une équipe d´ingénieurs extrêmement compétente qui travaille à notre driver OpenGL. Nous ne manquons absolument pas de talent à ce niveau !

Quelle est votre opinion concernant la manière dont OpenGL 2.0 gère les shaders ? (Le shader en langage de haut niveau est transmis tel quel au driver contrairement à ce qui se fait en ASM et avec le HLSL de DirectX 9)
L´approche optée par OpenGL en intégrant le compilateur de langage de haut niveau dans le driver donne à un fabricant de GPU des opportunités intéressantes en s´assurant que le bon compilateur peut toujours être utilisé avec le matériel approprié. Par exemple, le code d´un shader en langage de bas niveau (assembleur) conçu explicitement par un développeur pour un Radeon 9700 ne sera pas toujours le code idéal pour un Radeon X800 ou pour les futurs Radeon. Le driver est souvent en bien meilleure position que le développeur, ou qu´un outil de génération de code de tierce partie, pour optimiser le shader pour un matériel spécifique. Le concept principal de travail est ici semblable à la neutralité de plateforme offerte par le byte code dans Java ou le CLR dans le .NET. Le désavantage évident est que cela ajoute plus de complexité au driver.
Vos réactions

Top articles