Tom's Hardware > Tous les dossiers > Composants > Cartes graphiques > La bataille des HLSL

Questions/réponses

00:00 - lundi 15 septembre 2003 par Fedy Abi-Chahla

Les HLSL permettent la virtualisation des ressources ?

Non ! Contrairement à une croyance répandue ce n’est pas le cas. Virtualiser les ressources signifie tout simplement que les HLSL permettraient de s’affranchir des limites du hardware sous jacent. De la même manière que lorsque vous programmez en C vous ne vous intéressez pas au fait qu’un CPU x86 dispose de 8 GPR contrairement à 32 pour les CPU RISC, un HLSL supportant la virtualisation des ressources permettrait de ne plus se soucier des limites physiques que l’on trouve dans les shaders actuels comme le nombre de registres temporaires, d’instructions de texture ou d’opérations arithmétiques.

Le compilateur serait à même de décomposer un shader trop complexe pour la cible en plusieurs passes supprimant ainsi les limites physiques que les shaders connaissent actuellement et avec lesquels les développeurs doivent jongler. Autrement dit le shader ne serait écrit qu’une fois et ensuite exécuté sur les différents chips, or si vous avez bien suivi cet article depuis le début vous savez que ce n’est pas le cas actuellement : les compile targets ou les profils sont justement le résultat de cette carence. Présenté de cette manière la virtualisation des ressources semble être la solution à tous les problèmes alors pourquoi n’est elle pas supportée ? Tout simplement parce que c’est très complexe à mettre en place, arriver à décomposer automatiquement un shader en succession de passes est loin d’être un problème trivial.

Ensuite parce qu’étant donné l’énorme delta qui existe entre les différentes versions des shaders ce serait quasiment inutile : décomposer un pixel shader d’une centaine d’instructions pour le faire tourner sur un chip DirectX 8 demanderait tellement de passes que le résultat serait d’une lenteur inexploitable.

Pour être complet à ce sujet il convient de signaler que GLSLANG virtualise certaines ressources en particulier le nombre d’instructions dans un shader n’est pas fixé mais ce n’est pas pour ça qu’il est illimité : en fait les limites restent fixés mais cette fois par le hardware et plus par l’API : le compilateur ne décomposera pas le shader en plusieurs passes automatiquement. Il s’agit donc plus de s’affranchir des limites qui pourraient brider les futurs chips graphiques à plus ou moins long terme plutôt que d’une réelle virtualisation au sens propre du terme.

Mais il faut bien garder cette notion à l’esprit car ce sera à n’en pas douter le prochain chantier dans le domaine des HLSL : quand les chips DirectX 8 n’auront plus aucune raison d’être supportés et que la base des fonctionnalités sera du niveau DirectX 9 à ce moment là une véritable virtualisation des ressources pourra être mise en place dans les compilateurs. Les HLSL seront obligés d’en venir par là à un moment ou à un autre.

A retenir : Ce n’est pas parce qu’un shader est écrit dans un langage de haut niveau qu’il tournera automatiquement sur l’ensemble des chips graphiques sans aucune modification. Aucun HLSL actuel ne permet de s’affranchir des limites physiques des chips en recourant au rendu multi passes ce sera sans doute la prochaine évolution des HLSL.

Quel est le rapport entre RenderMonkey et les HLSL ?

Le même qu’entre VisualStudio et les différents langages de programmation. RenderMonkey est ce que l’on appelle communément un IDE Integrated Development Environment soit Environnement de développement intégré. L’objectif de cet outil est d’offrir un environnement de développement indépendant du HLSL choisi, chaque langage peut ainsi être supporté par le biais de plug-ins, permettant un prototypage rapide des shaders. L’interface en elle-même est proche de VisualStudio et en reprend même certains concepts comme celui de Workspace.

A retenir : RenderMonkey est un environnement de développement. Ce n’est ni un langage, ni un compilateur : juste une interface graphique basé sur une architecture ouverte à base de plug-ins permettant de supporter les différents HLSL.

Qu’est ce qu’Ashli ?

Ashli (Advanced Shading Language Interface) est une interface conçue par ATI visant à introduire ses dernières cartes graphiques dans les studios de production de films. Le but est en fait de permettre aux graphistes d’utiliser les dernières capacités du hardware afin d’accélérer le temps de rendu tout en conservant la qualité d’un moteur de rendu logiciel. Ashli prend en entrée des descriptions de shaders haut niveau (comme RenderMan Shading Language, Maya Shading Network ou 3DS Max Standard Materials) et renvoie en sortie des shaders OpenGL ou DirectX prêt à être exécutés par le hardware. C’est donc totalement transparent pour le graphiste qui continue à utiliser des outils qu’il connaît bien tout en bénéficiant d’une accélération matérielle du rendu.

L’exécution de shaders RenderMan en temps réel a fait grand bruit il y a quelques temps mais il convient de relativiser l’évènement. Tout d’abord on savait depuis l’an 2000 que cela était possible. En effet Peercy avait démontré que tout shader RenderMan pouvait être décomposé en algorithme multi passes en utilisant les fonctionnalités de base d’OpenGL 1.2 étendus avec deux extensions : les lectures de texture dépendant (apparus avec le NV20 et dont la flexibilité a été améliorée ensuite) et le support des couleurs en virgule flottante (apparu avec le R300). Et ensuite Ashli ne supporte encore qu’un sous ensemble du RenderMan Shading Language. C’est donc un pas dans la bonne direction assurément mais il reste encore du travail à accomplir.

A retenir : Ashli est une interface permettant de faire le lien entre les outils de type DCC et le hardware afin d’utiliser les fonctionnalités de ce dernier pour accélérer le rendu.