EP2153319A1

EP2153319A1 - Generateur de code source pour une carte graphique

Info

Publication number: EP2153319A1
Application number: EP08760517A
Authority: EP
Inventors: Dongmei Pei Xing; Henri Fousse
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2007-06-05
Filing date: 2008-06-04
Publication date: 2010-02-17
Also published as: FR2917199B1; WO2008148818A1; FR2917199A1; CA2689566A1; US20110032258A1

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

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 combinaisons 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 de la 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 Graphie 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 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 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 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 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 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 ».

Une première solution selon l'art antérieur est décrit par Niklas

Folkegard et Daniel Wesslen dans l'ouvrage Dynamic Code Génération 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 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, • un code comportant des calculs et des opérations, et • 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 œuvre 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, GameDevelopers Conférence, 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 cours d'affichage. Cette technique est utilisable uniquement lorsque le nombre d'effets est limité, comme dans un jeu. Il est impossible de mettre en œuvre 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 œuvre 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 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 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 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 Graphie 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. 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 « shaders » selon l'invention ;

• la figure 4 : différentes étapes possibles de mise en œuvre 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échit la source lumineuse par exemple. On peut ainsi classer les 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 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 ou plusieurs effets visuels. En définissant des catégories d'effets, un rendu sur un point d'un espace th-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 prenant en compte :

• aucune, une ou plusieurs géométhes ;

• aucun, un ou plusieurs matériaux ;

• aucune, une ou plusieurs sources de lumière ;

• aucune, une ou plusieurs atmosphères. 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 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éfinit 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. Les interfaces sont définies selon un formalisme adapté à la définition d'interfaces communes entre les différents « shaders » unitaires. 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 « shaders » 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 Graphie Library Shading Langage, le CG signifiant en langage anglo-saxon C like Graphie, le HLSL signifiant en langage anglo-saxon High Level Shading Langage, développé par Microsoft.

A partir de « shaders » unitaires, un générateur selon l'invention peut par exemple composer de manière automatique 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 combinaison des « shaders ». Notamment, une définition d'interfaces communes entre les différents « shaders » unitaires permet de les combiner de manière simple sans avoir à adapter les interfaces à chaque changement de combinaison de « shader ».

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 ou les scènes. Avantageusement, le générateur peut prendre en compte toutes les combinaisons d'effets nécessaires pour une application. Tous les « shaders » combinés nécessaires à une application peuvent donc être générés. Ceci permet de modifier, dynamiquement et en temps réel, les effets au cours de l'exécution de l'application.

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 obtenus après compilation.

L'utilisation d'un langage dédié aux cartes graphiques, aussi nommé langage natif de carte graphique, permet avantageusement de réutiliser des « shaders » déjà définis pour d'autres applications et de les utiliser sans traduction vers un autre langage.

Avantageusement, le formalisme adopté pour définir les interfaces communes des « shaders » unitaires peut être adapté à la structure du langage natif de la carte graphique. Ceci permet une optimisation en amont du code de gestion du GPU, ladite optimisation étant effectuée par le compilateur compilant les combinaisons de « shaders ». En effet, les compilateurs sont adaptés à optimiser le code de gestion des GPU. Ceci permet avantageusement d'éviter des phases d'optimisation complexes et coûteuses en temps. De plus, une optimisation du code à posteriori nécessite une optimisation à chaque modification de combinaison.

Un autre avantage lié à l'utilisation de code natif des cartes graphiques est de fournir aux utilisateurs usuels des cartes graphiques, des outils de génération de « shaders » dans un langage qu'ils maîtrisent déjà. L'utilisation du générateur ne nécessite donc pas de connaissances particulières.

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.

Des 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.

L'utilisation d'un formalisme adapté à la définition d'interfaces communes permet également de limiter les contraintes de prise en compte des combinaisons de « shaders » unitaires par le compilateur adapté à la carte graphique utilisée ainsi que par le générateur de « shaders » 20.

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 œuvre 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.

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 œuvre 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 œuvre 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'interfaces, 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 la dé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 une liste des 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 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 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 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 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.

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 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. Notamment, un programmateur de « shader » n'a pas besoin de gérer la combinatoire des différents « shaders » unitaires pour créer un effet complexe, en effet, la combinaison des « shaders » unitaires est réalisée automatiquement par le générateur.

Avantageusement, le générateur permet de créer de manière automatique des « shaders » combinés, notamment grâce aux interfaces communes entre les « shaders » unitaire. 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 permettent donc avantageusement de gérer des « shaders » pour une application temps réelle, utilisant un moteur graphique, et possédant par exemple un nombre important d'effets visuels à réaliser ou un nombre important de calculs complexes à effectuer.

Claims

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 de « shader » définie par un « shader » de base (1 , 2), ledit « 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 ensemble de « shaders » combinés (24) pour la carte graphique (33), lesdits « shaders » combinés résultant de la combinaison des « shaders » unitaires (3, 4, 5, 6, 7) selon une ou plusieurs descriptions de combinaisons (22) de « shaders » unitaires (3, 4, 5, 6, 7), lesdits « shaders » combinés étant utilisés par l'application logicielle (32) ; les « shaders » unitaires, les « shaders » de base et les « shaders » générés étant codés dans un langage dédié à la carte graphique.

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 Graphie 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 de « shader » définie par un « shader » de base (1 , 2) , ledit « 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), d'un ensemble de « shaders » combinés (24) pour la carte graphique (33) , lesdits « shaders » combinés résultants de la combinaison des « shaders » unitaires (3, 4, 5, 6, 7) selon une ou plusieurs descriptions de combinaisons (22) de « shaders » unitaires (3, 4, 5, 6, 7), lesdits « shaders » combinés étant utilisés par l'application logicielle (32) ; les « shaders » unitaires, les « shaders » de base et les « shaders » générés étant codés dans un langage dédié à la carte graphique.

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 une opération de calcul complexe combinant plusieurs opérations de calcul unitaires.