FR2917199A1 - Generateur de code source pour une carte graphique - Google Patents

Abstract

La présente invention concerne un générateur de code source 20 pour une carte graphique utilisée par une application logicielle.Des « shaders » unitaires comportant des caractéristiques communes sont définis selon une structure commune définie par un shader de base. Le shader de base comporte les caractéristiques communes des « shaders » unitaires ainsi que des interfaces communes pour l'application logicielle.Le générateur de code source 20 est un générateur de « shaders », générant un ou plusieurs « shaders » 24 pour la carte graphique en combinant les « shaders » unitaires 21 selon une ou plusieurs descriptions de combinaisons 22 de « shaders » unitaires 21.Le générateur de code source 20 peut être utilisé afin de produire un code source pour la gestion de la combinaison d'effets visuels notamment pour une application générant des images en temps réel pour une simulation ou un jeu vidéo.

Description

1 Générateur de code source pour une carte graphique La présente invention

concerne un générateur de code source pour une carte graphique. Le générateur de code source peut être utilisé afin de produire un code source pour la gestion de la combinaison d'effets visuels notamment pour une application générant des images en temps réel pour une simulation ou un jeu vidéo.

Des simulations d'environnements, notamment dédiées à l'entraînement de pilotes d'aéronefs, nécessitent un réalisme élevé de représentation visuelle des environnements. En effet, la qualité de rendu de surfaces et de conditions atmosphériques influent beaucoup sur l'appréciation par le pilote de repères visuels utilisés dans les phases d'atterrissage et de décollage.

Des applications logicielles de visualisation peuvent notamment être utilisées pour reproduire des environnements virtuels utilisés lors de simulations par exemple. Les applications logicielles de visualisation sont exécutées par un processeur d'un ordinateur. Ensuite, une carte graphique permet un affichage d'images, générées en temps réel par l'application logicielle, sur un écran relié à l'ordinateur. Une carte graphique est une carte d'extension d'un ordinateur servant à stocker et à interpréter des images générées par une application logicielle de visualisation s'exécutant sur le processeur de l'ordinateur par exemple. La mise à jour continuelle des images sur l'écran, pour la visualisation d'une séquence d'images par exemple, est assurée par la carte graphique. La qualité du rendu est donc notamment liée aux performances d'une carte graphique utilisée afin de permettre une représentation visuelle d'un environnement. La mise au point de cartes graphiques à base de processeurs programmables graphiques, aussi nommés GPU, acronyme de Graphic Processing Unit en langage anglo-saxon, a amélioré de façon significative la génération d'images en temps réel. Cette amélioration concerne à la fois la qualité des images et les performances en terme de rapidité de rafraîchissement de l'affichage des images. De plus, la programmation de 2 GPU a été rendue plus efficace et les programmes réalisés plus compréhensibles avec l'introduction de langages de programmation de parties spécifiques du GPU. Le paramétrage d'une carte graphique, afin notamment de pouvoir disposer d'effets visuels sur les images affichées, est effectué par l'intermédiaire d'un programme communément désigné par l'expression anglo-saxonne shader . Le shader est un programme comportant un code source composé d'instructions écrites en un langage compréhensible. Un shader permet donc de paramétrer une ou plusieurs parties de la carte graphique. Le shader permet ainsi d'intervenir à différentes étapes d'une chaîne de traitements d'informations graphiques effectués par la carte graphique. Le code d'un shader est compilé par un compilateur dédié à chaque type de carte graphique afin d'obtenir un programme qui peut ensuite s'exécuter sur le GPU.

L'évolution des formats d'images vers des définitions de plus en plus fines contraint les constructeurs de cartes graphiques à mettre au point des GPU de plus en plus puissants. Les processeurs GPU sont capables d'effectuer de multiples opérations en parallèle et en temps réel. Ces performances sont notamment utilisées par des logiciels de jeu afin de représenter des environnements de plus en plus réalistes, mais aussi de plus en plus par des logiciels de calculs effectuant des opérations de calculs complexes. Cependant la programmation des shaders souffre d'un manque de flexibilité. En effet, un programme shader est une suite d'instructions de code généralement monobloc décrivant par exemple tous les effets d'affichages possibles pour une application de visualisation donnée. Les applications logicielles de visualisation combinant de plus en plus d'effets visuels, il est de plus en plus difficile d'intégrer les shaders avec les applications de visualisation. En particulier les interfaces entre les shaders et ces applications doivent être figées une fois pour toutes. Toute modification d'interface oblige potentiellement à réécrire quasi entièrement le code du shader. Une modification d'interface possède en outre un impact non négligeable sur les programmes des applications utilisant les shaders . Pour des applications de grande taille c'est à dire comportant beaucoup de modules fonctionnels faisant appel à une pluralité de shaders , l'écriture 3 des shaders est alors difficile et peu souple. Les capacités d'évolution des shaders au cours du développement de l'application, notamment l'ajout de nouveaux effets, nécessite de réécrire la quasi-totalité du code du shader concerné. En effet, un code de shader ne peut se structurer en combinant des sous-programmes élémentaires par exemple. Dans une application de visualisation temps réelle, utilisée notamment pour de la simulation d'environnement, se pose la problématique de la combinaison des effets visuels. Par exemple, on souhaite afficher un terrain comportant une surface d'eau, ce terrain étant survolé par un phare ~o l'éclairant. Les effets d'affichage à décrire pour afficher cette scène sont par exemple un effet terrain, un effet eau, et un effet source lumineuse. Pour réaliser un rendu d'affichage de l'effet source lumineuse sur la surface de l'eau ou sur le terrain, il faut décrire dans le shader les combinaisons possibles des trois effets : par exemple, le terrain sans source lumineuse, le 15 terrain avec source lumineuse, l'eau sans source lumineuse, l'eau avec source lumineuse. De manière générale, le nombre de rendus à décrire dans le shader est égal au nombre de combinaisons d'effets qu'une application de visualisation réalise. L'ajout d'un nouvel effet nécessite donc l'écriture de l'ensemble des rendus correspondant aux nouvelles combinaisons des effets 20 existants avec le nouvel effet. Ces contraintes induisent donc des coûts élevés de développement des applications de visualisation et des shaders associés, ainsi que des coûts élevés pour la maintenance et l'évolution de telles applications et de tels shaders .

25 Une première solution selon l'art antérieur est décrit par Niklas Folkegard et Daniel Wesslen dans l'ouvrage Dynamic Code Generation for Realtime shaders . Cette première solution a pour objectif de réduire les redondances dans le codage des shaders notamment dans la description des effets. A cette fin, Folkegard et Wesslen proposent de diviser un 3o programme shader en petites parties de code. Ensuite, un combineur assemble ces parties afin de construire un programme shader classique à partir de paramètres donnés par un utilisateur. Chaque partie comporte : • une description des données d'entrées ou de pré-conditions d'utilisation de la partie du code, 35 • un code comportant des calculs et des opérations, et 4 • des données de sorties ou de post-conditions d'utilisation de la partie du code. Le combineur prend en compte les paramètres donnés par l'utilisateur, et assemble les parties compatibles en fonction des paramètres et des données d'entrée et de sortie de chaque partie. Le combineur fourni ensuite un nouveau code de shader comportant toutes les combinaisons possibles. Le temps mis par le combineur pour assembler toutes les parties est d'autant plus long qu'il doit prendre en compte de nombreuses parties. Dans des applications utilisant une grande combinatoire d'effets, il est impossible de décrire chaque partie avec ses données d'entrée et de sortie, le niveau de décomposition étant trop fin.

Une deuxième solution permet notamment d'éviter des boucles et des branchements dynamiques dans le shader. Cette solution est mise en oeuvre dans un moteur de jeux nommé Far Cry, marque déposée par Ubisoft Entertainment, et décrit par Carsten Wenzel dans Far Cry and Directx X, GameDevelopers Conference, DirectX étant une marque déposée par Microsoft Corporation. Ce moteur de jeu effectue une pré-compilation de shader avec différents masques pour les sources de lumière. Ensuite, le moteur de jeu utilise un système de cache pour accélérer l'installation du shader au moment de l'utilisation d'un rendu par une application de visualisation. Ceci revient à utiliser un shader général comportant tous les effets combinés entre eux, en enlevant au moment de l'exécution du programme shader les effets non souhaités dans l'image en cour d'affichage. Cette technique est utilisable uniquement lorsque le nombre d'effets est limité, comme dans un jeu. Il est impossible de mettre en oeuvre cette solution lorsque l'on possède une combinatoire importante d'effets.

Une troisième solution est proposée par Dominic Filion dans Recombinant Shaders in Game Programming Gems 5. Cette troisième solution utilise également un shader générique dans lequel sont définis des points d'insertion permettant de générer des variantes de shader par addition et soustraction de parties de code de shader. Ces points d'insertion définissent des traitements à effectuer suivant un contexte correspondant par exemple à un point d'insertion. Cette solution peut être réalisée par l'insertion d'instructions pré-processeur dans le code du shader. Les instructions pré-processeur permettent à un compilateur de déterminer le code à utiliser afin de générer un programme de shader exécutable. Le principal inconvénient de cette solution est le nombre limité de points d'insertion possibles. Cette limitation rend impossible la gestion de nombreuses combinaisons d'effets.

Une autre solution mise en oeuvre par M. McCool et Al. est décrite notamment dans Shader Algebra et Metaprogramming GPUs with Sh. Cette solution repose sur un méta-langage nommé Sh, pouvant être utilisé afin de développer des shaders . Un méta-langage est un langage formel servant à décrire un ou plusieurs langages de programmation comme par exemple les langages propres à la programmation d'un shader . Ce méta-langage propose des opérateurs algébriques de connexion et de combinaison notamment pour des shaders unitaires considérés comme des objets. Un shader unitaire peut être par exemple un shader décrivant un effet. Le code des shaders est ensuite compilé afin de donner un code de shader usuel. Cette approche permet de faciliter l'intégration des shaders avec des applications de visualisation. Cependant le fait de développer un shader dans un autre langage qu'un langage de programmation propre aux shaders , ainsi que le fait de développer un compilateur spécifique au méta-langage limite les possibilités d'optimiser les traitements des shaders par la carte graphique. Ceci peut avoir comme conséquence de dégrader les performances d'affichage temps réel d'une image complexe.

Un but de l'invention est notamment de pallier les inconvénients précités. A cet effet, l'invention a pour objet un générateur de code source 30 pour une carte graphique, utilisée par une application logicielle. Des shaders unitaires comportant notamment des caractéristiques communes sont définis selon une structure commune définie par un shader de base. Le shader de base comporte par exemple les caractéristiques communes des shaders unitaires. Le shader de base 35 peut comporter des interfaces communes pour l'application logicielle 32.

Le générateur de code source est un générateur de shaders , générant un ou plusieurs shaders pour la carte graphique en combinant les shaders unitaires selon une ou plusieurs descriptions de combinaisons de shaders unitaires.

Le générateur peut associer une clef unitaire à chaque shader unitaire et à chaque combinaison de shaders unitaires. Les clefs unitaires générées sont par exemple fournies à l'application logicielle. L'application logicielle est par exemple une application de visualisation. Un shader unitaire correspond par exemple à un effet visuel. Une combinaison de shaders unitaires correspond par exemple à un rendu combinant plusieurs effets visuels. L'application logicielle est par exemple une application de calcul. Le shader unitaire est par exemple une opération de calcul unitaire. Une combinaison de shaders unitaires est par exemple une opération de calcul complexe combinant plusieurs opérations de calcul unitaires. Le code source des shaders générés est par exemple codé avec un langage GLSL, signifiant en langage anglo-saxon Graphic Library Shading Language, créé par OpenGL ARB.

Le générateur peut être codé avec un langage objet.

L'invention a également pour objet un procédé de génération de code source pour une carte graphique. Le procédé comporte notamment les étapes suivantes : • définition de shaders unitaires. Les shaders unitaires comportant notamment des caractéristiques communes. Les shaders unitaires peuvent être définis selon une structure commune. La structure commune est par exemple définie par un shader de base comportant les caractéristiques communes des shaders unitaires. Le shader de base peut aussi comporter des interfaces communes pour l'application logicielle ; • génération, par un générateur de code source, de shaders pour la carte graphique en combinant les shaders unitaires selon une ou plusieurs descriptions de combinaisons de shaders unitaires. 7 Une clef unitaire est par exemple associée à chaque shader unitaire. Une clef unitaire est par exemple associée à chaque combinaison de shaders unitaires résultant de la composition des clefs unitaires des shaders unitaires combinés.

L'application logicielle est par exemple une application de visualisation. Un shader unitaire correspondant par exemple à un effet visuel. Une combinaison de shaders unitaires correspond par exemple à un rendu combinant plusieurs effets visuels.

L'application logicielle est par exemple une application de calcul. Un shader unitaire est par exemple une opération de calcul unitaire. Une combinaison de shaders unitaires est par exemple une opération de calcul complexe combinant plusieurs opérations de calcul unitaires.

L'invention a notamment pour principaux avantages de permettre une programmation souple et peu coûteuse de shaders pour carte graphique, tout en optimisant les temps d'accès des applications logicielles aux programmes exécutables de shaders .

D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, donnée à titre illustratif et non limitatif, et faite en regard des dessins annexés qui représentent : • la figure 1 : un exemple schématique d'une conception d'un shader selon l'invention ; • la figure 2 : un exemple de génération d'un programme exécutable par un GPU selon l'invention ; • la figure 3 : un exemple d'utilisation d'un générateur de 30 shaders selon l'invention ; • la figure 4 : différentes étapes possibles de mise en oeuvre de shader selon l'invention.

La figure 1 représente un exemple schématique de diagramme de conception de shaders . Les shaders sont par exemple définis pour une application de visualisation Pour afficher une image, un ou plusieurs effets visuels peuvent être utilisés afin d'obtenir un rendu combinant ces effets. Par exemple pour représenter une surface liquide éclairée par le soleil, on peut combiner un effet d'eau et un effet de soleil. Dans cet exemple, le soleil possède une fonction de source lumineuse tandis que l'eau a une fonction de matériau sur lequel se réfléchi la source lumineuse par exemple. On peut ainsi classer les ~o effets désirés pour une application de visualisation selon plusieurs catégories. Les effets appartenant à une même catégorie ont des caractéristiques communes comme une fonction d'éclairage pour les sources lumineuses. Par exemple, on peut utiliser une catégorie matériaux, une catégorie source lumineuse, une catégorie atmosphère, une catégorie 15 géométrie. Le nombre de catégories dépendant des effets visuels à produire, il n'est donc pas limité. Pour afficher un point d'une image issue notamment d'une application de visualisation temps réelle, on utilise un programme de shader correspondant par exemple à un rendu. Un rendu est une combinaison d'un 20 ou plusieurs effets visuels. En définissant des catégories d'effets, un rendu sur un point d'un espace tri-dimensionnel d'un environnement simulé peut s'exprimer sous la forme d'une équation. L'équation donne par exemple la couleur C du point en fonction d'un ou plusieurs effets appartenant à une ou plusieurs catégories. On peut définir C comme le résultat d'une fonction 25 prenant en compte : • aucune, une ou plusieurs géométries ; • aucun, un ou plusieurs matériaux ; • aucune, une ou plusieurs sources de lumière ; • aucune, une ou plusieurs atmosphères. 30 C peut être décrit de la manière suivante : C = fonction(Géométrie,Matériaux, Source _ de _ lumière, Atmosphère) Chaque effet de chaque catégorie peut être défini par un shader unitaire. Les shaders correspondants aux effets d'une même catégorie peuvent avoir des caractéristiques en commun. Ces caractéristiques en 35 commun peuvent être par exemple : • pour une catégorie source de lumière : une intensité d'éclairage, une direction d'éclairage, une fonction d'éclairage ; • pour une catégorie matériaux : une couleur, une texture, un pouvoir de réflexion, une fonction de réflexion de la lumière.

Ceci permet de définir une structure commune de shader pour chaque catégorie de shaders unitaires définie. Cette structure commune de shader est par exemple une structure commune de shaders matériaux 1 ou une structure commune de shaders sources de lumière 2. Les shaders unitaires appartenant à la structure de shaders matériaux 1 comme le shader eau 3 et le shader terrain 4 ont donc une structure commune. Ces structures communes de shaders exploitent notamment des possibilités propres aux langages de programmation des shaders : la structure et la surcharge de fonction. La surcharge de fonction permet notamment de définir une fonction de manière générique par exemple au niveau de la structure de shaders matériaux 1. Puis cette fonction peut être décrite précisément au niveau de chaque shader unitaire comme le shader eau 3 et le shader terrain 4. De la même manière que l'on défini une structure commune de shaders matériaux 1, on peut définir une structure commune de shaders sources de lumière 2 pour un shader soleil 5, un shader spot 6, et un shader point 7, ce dernier correspondant à un effet relatif à une source de lumière ponctuelle. Un shader unitaire, correspondant par exemple à un effet, peut donc être défini comme une pseudo classe d'un langage objet avec des interfaces et une structure. Ainsi, les shaders unitaires ayant une même structure de shader commune implémentent notamment les mêmes interfaces. En pratique, les interfaces ont les mêmes structures, elles prennent en compte les mêmes paramètres par exemple, mais les instructions effectuées dans chaque fonction d'interface peuvent être spécifiques à chaque shader unitaire. Un espace de nom peut également être défini au niveau de chaque shader unitaire. Cet espace de nom permet de définir des fonctions ou des paramètres de fonction, des variables, ayant le même nom pour tous les shaders appartenant à une même catégorie par exemple mais représentant des fonctions ou des variables différentes selon l'espace de nom dans lequel elles sont définies. Ceci permet de faciliter l'intégration des shaders par les applications. Par exemple, une application de visualisation peut alors utiliser les mêmes noms pour les interfaces, quels que soient les effets d'une catégorie utilisés. Ceci apporte une grande souplesse en matière de programmation des interfaces des shaders avec les applications. Les applications de visualisation, par exemple, n'ont pas nécessairement besoin de connaître en détail les fonctions, paramètres et variables de chaque shader unitaire. Les applications de visualisation connaissent alors uniquement les interfaces des shaders de base. Ceci rend relativement indépendant les shaders unitaires et les applications de visualisation dans le sens ou une évolution d'un shader unitaire a peu d'incidence sur le codage d'une application. Les shaders unitaires ainsi que les structures de shader peuvent être codés en différents langages. Une manière efficace de coder les différents shader est d'utiliser un langage dédié aux cartes graphiques permettant ainsi de maîtriser et d'optimiser des paramètres d'exécution des programmes de shader sur un GPU. Ces langages peuvent être par exemple : le GLSL signifiant en langage anglo-saxon Graphic Library Shading Langage, le CG signifiant en langage anglo-saxon C like Graphic, le HSLS signifiant en langage anglo-saxon High Level Shader Langage, développé par Microsoft. A partir de shaders unitaires, un générateur selon l'invention peut par exemple composer un nouveau shader 8 : le shader terrain + spot + point 8 comme étant la composition des shaders unitaires suivant : le shader terrain 4, le shader spot 6 et le shader point 7. De la même manière, le générateur de shaders selon l'invention peut également composer un shader terrain + spot 9 et un shader terrain 10. La définition de shaders unitaires et la gestion de ces shaders unitaires de manière modulaire permet de simplifier la 30 combinaison des shaders .

La figure 2 représente de manière schématique un exemple de fonctionnement d'un générateur de shaders 20 selon l'invention.

Le générateur de shaders 20 peut prendre en compte les différents shaders unitaires 21. Chaque shader unitaire 21 correspond par exemple à un effet. Ensuite, à partir d'une liste d'entrée de différents effets 22 d'une scène d'un environnement à simuler par exemple, le générateur de shaders calcule les combinaisons utiles de shaders unitaires 21 pour la scène. La liste des différents effets 22 est une description de combinaisons d'effets et donc de shaders unitaires 21. Un environnement à simuler pouvant comporter plusieurs scènes, le générateur de shaders 20 peut prendre en compte plusieurs listes d'effets de scène par exemple. Ensuite, le générateur de shaders 20 génère des shaders combinés 24 pour la scène. Les shaders combinés 24 sont générés dans un langage de programmation propre à la carte graphique comme le GLSL, le CG ou le HLSL par exemple. Le code des shaders combinés 24 est ensuite compilé par un compilateur 25 propre au type de carte graphique sur laquelle s'exécute les programmes exécutables de shaders 26 obtenu après compilation. Le générateur de shaders 20 est un programme exécutable dont le code peut être écrit en un langage informatique quelconque. Par exemple le générateur de shaders 20 peut être codé avec un langage objet comme le langage C++. Le programme exécutable du générateur de shaders 20 est généré par un compilateur dédié au langage dans lequel est codé le générateur de shaders 20. D'autres paramètres peuvent être pris en compte par le générateur de shaders 20 comme un nombre d'instance de chaque effet 23. Ceci permet d'optimiser le code des shaders combinés 24 afin notamment d'optimiser l'exécution des programmes exécutables de shaders 26 correspondant. D'autres paramètres peuvent être pris en compte afin d'optimiser par exemple les traitements du générateur de shaders 20.

Cette manière de générer les shaders combinés 24 permet d'écrire le code des shaders unitaires 21 une seule fois. Le code des shaders unitaires 21 est ensuite utilisé par le générateur de shaders 20 afin de générer le code des shaders combinés 24.35 La figure 3 représente un exemple d'intégration d'un générateur de shaders 20 dans un moteur de rendu. Un moteur de rendu est par exemple l'ensemble des procédés et dispositifs mis en oeuvre pour afficher un rendu A 30 d'une image sur un écran 31. Une application de visualisation 32 peut utiliser des shaders afin de composer différents effets sur une image. L'application de visualisation 32 peut prendre en compte une liste de différents effets disponibles dans les shaders 24 générés par le générateur de shaders 20. L'application de visualisation 32 peut donc faire appel dans son code à différents effets codés dans les shaders combinés 24. Dans un premier temps, pendant le lancement de l'application de visualisation 32, le générateur de shaders 20 génère les shaders combinés 24. Ensuite les shaders combinés 24 sont compilés par un compilateur de shader 26. Un programme exécutable de shader 26, associé à un rendu, est ensuite stocké dans la carte graphique 33 pour être exécuté par la carte graphique 33 sur demande de l'application de visualisation 32. Par exemple, un programme exécutable de shader 26 peut donner un ou plusieurs programmes exécutables de rendu, comme le Prg rendu A, ou le Prg rendu B, Prg étant une abréviation pour programme.

Afin d'accélérer l'affichage d'un rendu, le générateur de shaders 20 peut générer une clef unique, codée sur un champ de bits, pour chaque effet. Les différentes clefs uniques générées sont fournies à l'application de visualisation 32. Le générateur de shaders 20 et l'application de visualisation 32 peuvent composer à partir des clefs uniques d'effets une clef unique de rendu correspondant à une combinaison d'effets souhaités. Une clef de rendu peut être un champ de bit, correspondant par exemple à la somme des clefs des effets souhaités. Une clef de rendu unique est ensuite associée par le compilateur 25 à chaque programme de rendu. Par exemple sur la figure 3, l'application de visualisation 32 souhaitant afficher un rendu A 30 compose une clef rendu A. Puis l'application de visualisation 32 fourni la clef rendu A à la carte graphique 32 qui peut rapidement retrouver le Prg rendu A correspondant à la clef rendu A. Par exemple, la clef rendu A peut être un numéro d'une case d'un tableau, chaque case du tableau correspondant à un programme de rendu. Ensuite la carte graphique 32 affiche l'image avec le rendu A 30 sur l'écran 31. 13 La génération d'une clef unique peut être généralisée à d'autres types d'applications : une clef unique peut être associée à chaque shader unitaire et à chaque composition de shaders unitaires.

La figure 4 représente différentes étapes possibles d'un procédé de génération et de mise en oeuvre de shaders selon l'invention dans le cadre d'une application de visualisation par exemple. Une première étape 40 est une étape de définition de différentes catégories par exemple d'effets à mettre en oeuvre pour une application de visualisation donnée notamment. Les catégories sont définies de manière générique et peuvent être réutilisées pour une autre application de visualisation par exemple. Par exemple on peut définir une catégorie matériaux, une catégorie source lumineuse, une catégorie atmosphère, une catégorie géométrie. La définition d'une catégorie permet de définir une structure de shader commune que l'on peut nommer shader de base. Un shader de base correspondant à une catégorie comporte notamment la définition de fonctions, d'interface, de paramètres et de variables qui sont communs à tous les shaders de la catégorie définie.

Une deuxième étape 41 est une étape de définition des shaders unitaires. Les shaders unitaires représentent par exemple un effet appartenant à une catégorie. La définition d'un shader unitaire est ladéfinition du corps des fonctions et des interfaces définies dans le shader de base de la catégorie à laquelle appartient le shader unitaire. Un shader unitaire peut aussi comporter des fonctions, des interfaces, des paramètres ou des variables qui lui sont propres. Une troisième étape 42 est une étape de paramétrage du générateur de shaders 20. Cette étape permet notamment de préciser par exemple les effets souhaités 22 combinant plusieurs effets unitaires ainsi que le nombre d'instance de chaque effet 23. Le paramétrage du générateur de shaders 20 permet également de décrire l'ensemble des shaders unitaires à prendre en compte par le générateur afin de générer les effets 23. Une quatrième étape 43 est une étape de génération des shaders combinés 24 par le générateur de shaders 20. Les shaders combinés 24 ainsi générés permettent notamment de réaliser les effets décrits dans la liste des effets 22 pour une scène. Une cinquième étape 44 est une étape de compilation des shaders combinés 24 par le compilateur de shader 25, propre à la carte graphique 33. La compilation des shaders combinés 24 produit un ensemble de programmes exécutables shaders 26, c'est à dire un ensemble de programmes de rendus comme les prg de rendu A et prg de rendu B. Une sixième étape 45 est une étape d'utilisation des programmes ~o de rendus par l'application de visualisation 32 afin d'afficher une image avec un rendu 30 sur un écran 31.

Un procédé de génération de shaders tel que décrit peut être 15 utilisé pour réaliser des calculs avec une carte graphique. Une carte graphique peut être utilisée afin d'effectuer des calculs parallèles comme du calcul vectoriel par exemple. L'application utilisant les shaders est alors une application de calcul. Les shaders unitaires définis dans ce cas peuvent par 20 exemple correspondre à des opérations unitaires pouvant être regroupées par exemple en familles d'opérations selon leurs caractéristiques afin de définir des catégories d'opérations. L'application de calcul combinant ensuite les opérations unitaires afin d'effectuer en parallèle des opérations complexes sur la carte graphique. Ceci permet de profiter de la puissance de 25 calcul d'une carte graphique à moindre coût. Il est alors très intéressant de pouvoir utiliser une méthode souple et économique de programmation de shader telle que la génération de shaders selon l'invention.

30 Le procédé selon l'invention permet avantageusement de définir des shaders de façon modulaire et de gérer des combinaisons de shaders . La définition des shaders de manière modulaire permet avantageusement de simplifier l'intégration des shaders avec une 35 application de calcul ou de visualisation.

L'invention permet donc une grande souplesse de programmation des shaders destinés à des cartes graphiques. Cette souplesse se traduit en un gain de temps de développement des shaders entraînant également une réduction des coûts de développement d'une application utilisant une carte graphique. La définition de clefs unitaires pour les shaders permet une augmentation de la rapidité d'exécution du choix d'un programme exécutable shader par l'application. Cette rapidité et cette souplesse permet donc avantageusement de gérer des shaders pour une application temps réelle possédant par exemple un nombre important d'effets visuels à réaliser ou un nombre important de calculs complexes à effectuer.

Claims (10)

REVENDICATIONS

1. Générateur de code source (20) pour une carte graphique (33) utilisée par une application logicielle (32) caractérisé en ce que : • des shaders unitaires (3, 4, 5, 6, 7) comportant des caractéristiques communes sont définis selon une structure commune définie par un shader de base (1,

2) comportant les caractéristiques communes des shaders unitaires (3, 4, 5, 6, 7) ainsi que des interfaces communes pour l'application logicielle (32) ; • ledit générateur de code source (20) est un générateur de shaders (20), générant un ou plusieurs shaders (24) pour la carte graphique (33) en combinant les shaders unitaires (3, 4, 5, 6, 7) selon une ou plusieurs descriptions de combinaisons (22) de shaders unitaires (3, 4, 5, 6, 7). 2. Générateur selon la revendication 1, caractérisé en ce qu'il associe une clef unitaire à chaque shader unitaire (3, 4, 5, 6, 7) et à chaque combinaison (8, 9, 10) de shaders unitaires (3, 4, 5, 6, 7), les clefs unitaires générées étant fournies à l'application logicielle (32).

3. Générateur selon l'une quelconque des revendications précédentes, caractérisé en ce que l'application logicielle (32) est une application de visualisation, un shader unitaire (3, 4, 5, 6, 7) correspondant à un effet visuel, une combinaison (8, 9, 10) de shaders unitaires (3, 4, 5, 6, 7) correspondant à un rendu combinant plusieurs effets visuels.

4. Générateur selon l'une quelconque des revendications précédentes, caractérisé en ce que l'application logicielle (32) est une application de calcul, un shader unitaire (3, 4, 5, 6, 7) étant une opération de calcul unitaire, une combinaison 8, 9, 10 de shaders unitaires (3, 4, 5, 6, 7) étant une opération de calcul complexe combinant plusieurs opérations de calcul unitaires.

5. Générateur selon l'une quelconque des revendications précédentes, caractérisé en ce que le code source des shaders générés(24) est codé avec un langage GLSL, signifiant en langage anglo-saxon Graphic Library Shading Language.

6. Générateur selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est codé avec un langage objet.

7. Procédé de génération de code source pour une carte graphique (33), caractérisé en ce qu'il comporte au moins les étapes suivantes : • définition de shaders unitaires (3, 4, 5, 6, 7), les shaders unitaires (3, 4, 5, 6, 7) comportant des caractéristiques communes étant définis selon une structure commune définie par un shader de base (1, 2) comportant les caractéristiques communes des shaders unitaires (3, 4, 5, 6, 7) ainsi que des interfaces communes pour l'application logicielle (32) ; • génération, par un générateur de code source (20), de shaders (24) pour la carte graphique (33) en combinant les shaders unitaires (3, 4, 5, 6, 7) selon une ou plusieurs descriptions de combinaisons (22) de shaders unitaires (3, 4, 5, 6, 7).

8. Procédé selon la revendication 7, caractérisé en ce que : • une clef unitaire est associée à chaque shader unitaire (3, 4, 5, 6, 7) ; • une clef unitaire est associée à chaque combinaison (8, 9, 10) de shaders unitaires (3, 4, 5, 6, 7), résultant de la composition des clefs unitaires des shaders unitaires combinés.

9. Procédé selon l'une quelconque des revendications 7 et 8, caractérisé en ce que l'application logicielle 32 est une application de visualisation, un shader unitaire (3, 4, 5, 6, 7) correspondant à un effet visuel, une combinaison (8, 9,

10) de shaders unitaires (3, 4, 5, 6, 7) correspondant à un rendu combinant plusieurs effets visuels. 10. Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce que l'application logicielle (32) est une application de calcul, un shader unitaire (3, 4, 5, 6, 7) étant une opération de calcul unitaire, une combinaison (8, 9, 10) de shaders unitaires (3, 4, 5, 6, 7) étant uneopération de calcul complexe combinant plusieurs opérations de calcul unitaires.