Brevet FR2868854A1 — publié le 20051014

- 1 "Procédé et système pour gérer des objets multimédia à diffuser, au moyen d'une unité de traitement associée à un accélérateur multimédia." La présente invention se rapporte à un procédé et un système pour gérer des objets multimédia à diffuser, audio ou graphique en particulier, au moyen d'une unité de traitement associée à un accélérateur multimédia. L'invention trouve une application particulièrement intéressante, mais non exclusivement, dans le domaine des modules embarqués tels que par exemple des systèmes automobiles faisant appel à une interface homme- machine à travers un écran. Toutefois, l'invention est d'un cadre plus large puisqu'elle peut s'appliquer à tout système comprenant un processeur principal épaulé par un second processeur ou coprocesseur, notamment graphique ou audio, pour la diffusion sur écran ou enceinte. D'une façon générale, l'approche objet est une réponse universellement reconnue et employée aujourd'hui au sein des développements informatiques. Outre ses capacités d'abstraction qui facilitent les phases de spécification, ses propriétés d'encapsulation et de modularité la rendent idéale dans le cadre de développements logiciels partagés. Ses qualités ont inspiré bon nombre de langage (ADA, C++, JAVA, etc.), très populaires aujourd'hui devant l'importance des développements de produits complexes, notamment les systèmes multimédia. Une des particularités de ces "objets" est d'être représentatifs du monde réel et donc d'être mieux appréhendable par l'esprit humain, car façonnés selon ses habitudes de perception. D'un point de vue conceptuel, ces objets sont capables d'exister de façon totalement parallèle et autonome, par rapport aux autres objets de l'environnement considéré. Cependant, lorsqu'il s'agit de passer de ces concepts simples à une réalisation concrète permettant de construire et de dérouler une réelle application, les solutions restent aujourd'hui principalement logicielles. On peut citer par exemple le langage Java, qui est le plus avancé aujourd'hui en terme de concept objet, s'appuyant sur une "machine virtuelle" généralement réalisée par une importante couche d'abstraction logicielle, masquant la diversité des - 2 plateformes matérielles. Des accélérateurs matériels existent cependant, mais ils proposent des accélérations au niveau du jeu d'instructions. Dans le cas d'accélérateur matériel selon l'art antérieur, par exemple au sein d'un micro-ordinateur de type PC, lorsqu'il s'agit d'accélérer le traitement graphique par l'intermédiaire d'une architecture distribuée, par exemple une carte graphique, les solutions actuellement retenues passent généralement par le transfert des données, pouvant constituer des "objets", du processeur principal du PC cherchant à se délester de la tâche d'affichage vers un coprocesseur graphique. Ce dernier peut ensuite exploiter l'intégralité des données de façon autonome par rapport au processeur principal. Dans ce cas, il y a généralement mise en forme et transfert des données de la mémoire du processeur principal vers le coprocesseur graphique secondaire (ou accélérateur graphique). Dans ce cadre là, c'est la spécification de la mise en forme des données qui dicte l'interface d'échange entre les sous-systèmes (Open GL , Direct X(D, etc.). La structure physique d'échange est alors constituée par une mémoire tampon partagée dans laquelle l'un verse des données, tandis que l'autre les exploite. L'échange entre les sous-systèmes s'effectue généralement à travers un ensemble de registres ou une zone mémoire partagée, généralement en écriture seulement, de type FIFO, dans lesquels le processeur d'application déverse des commandes graphiques ou la description des données constitutives d'objets pour les coprocesseurs les plus avancés. Dans le dernier cas, il devient possible de spécifier des opérations s'appliquant sur l'ensemble des objets préparés. Le problème des solutions utilisées dans l'art antérieur est qu'elles nécessitent la plupart du temps l'utilisation de plusieurs composants mémoires, attachés d'une part au processeur principal et d'autre part au co-processeur, permettant le transfert de données ou de commandes pour la désynchronisation du traitement par rapport aux requêtes. Dans l'état antérieur de la technique, les principes de base tels que décrits ci-dessus, sont la conséquence logique d'une approche d'intégration. En effet, dans la mesure où l'on répartit des fonctions complexes telles que l'une gérant un moteur 2868854 - 3- d'Interface Homme-Machine (IHM)et l'autre ayant en charge la gestion de l'affichage, selon deux responsabilités distinctes, on converge intuitivement vers une telle solution selon l'art antérieur, où un système délègue à un autre un type de travail, pouvant ainsi récupérer sa puissance CPU pour effectuer ses propres tâches. Dans le cas d'un traitement d'informations graphiques par un coprocesseur, le besoin est principalement unilatéral. Le processeur d'application a besoin de transférer des données ou des commandes de son environnement vers la mémoire ou les registres de travail du coprocesseur (généralement rapidement), afin de se décharger du travail d'affichage. Le besoin principal reste donc de connaître l'état du coprocesseur lui-même occupé ou prêt à traiter d'autres commandes. On connaît des interfaces qui sont orientées objet en offrant un jeu de commandes permettant de solidariser des données qui sont alors vues comme constitutives conceptuellement d'un seul objet. Le problème se pose alors d'être capable, selon les besoins et pour le suivi par la tâche applicative, de récupérer des informations témoignant de l'état ou de l'activité de l'objet. II faut alors prévoir dans l'interface, par exemple par des fonctions de récupération d'état, de position, etc..., ou la structure physique d'échange, par exemple à l'aide de registres, des moyens permettant d'assurer ce canal "inverse" d'information entre le coprocesseur graphique et le processeur principal. Ceci peut conduire à l'instauration de processus logiciels de suivi lourds. L'usage d'un coprocesseur peut s'avérer alors beaucoup moins rentable. La présente invention a pour but de remédier aux inconvénients précités en proposant un mécanisme nouveau dans le 30 cadre d'un système permettant à un processus applicatif de se délester des fonctions d'affichage en manipulant des objets multimédia, graphiques ou sonores en particulier, à travers une interface de haut niveau. L'invention a encore pour but d'éviter la redondance 35 d'informations entre un processeur et un coprocesseur multimédia, et de maintenir ainsi une cohérence entre les données applicatives et les données d'affichage. On atteint au moins l'un des buts précités avec un procédé pour gérer des objets multimédia à diffuser, en particulier audio 2868854 - 4- ou graphique, au moyen d'une unité de traitement, tel qu'un processeur principal, auquel on associe un accélérateur multimédia tel qu'un coprocesseur, ledit accélérateur multimédia intégrant au moins un mécanisme matériel câblé. Selon l'invention, - pour chaque objet, on crée un descripteur comprenant un ensemble de données rendant ledit objet autonome, ledit ensemble de données comprenant des données de définition de l'objet et des données d'exploitation de l'objet, - on stocke ledit descripteur dans une mémoire partagée entre l'unité de traitement et l'accélérateur multimédia, - on stocke dans un espace mémoire d'une structure de commande, l'adresse de stockage dudit descripteur. La structure de commande peut être un pointeur d'adresse ou une indirection. En particulier, selon l'invention, à chaque fois que l'unité de traitement spécifie l'adresse d'un objet dans au moins un espace mémoire de la structure de commande, on réalise les étapes suivantes: - activation de l'accélérateur multimédia, - prise en charge, par l'accélérateur multimédia, du descripteur stocké à l'adresse contenue dans ledit espace mémoire de la structure de commande, espace mémoire spécifié ci-dessus par l'unité de traitement, - l'accélérateur multimédia diffuse et anime de façon totalement autonome et automatique, par des mécanismes matériels câblés, ledit objet autonome à partir dudit ensemble de données. Par mémoire partagée, on entend une mémoire accessible à l'unité de traitement et à l'accélérateur multimédia. La spécification d'une adresse peut être l'écriture d'une adresse valide dans la structure de commande ou encore l'activation d'une adresse valide présente dans la structure de commande. L'écriture d'une adresse non valide peut correspondre à l'effacement d'un objet par exemple. Avec le procédé selon l'invention, l'accélérateur multimédia peut totalement gérer l'objet indépendamment, sans intervention, de l'unité de traitement. Le descripteur est conçu de telle sorte que l'objet associé devient autonome vis à vis du processeur principal. - 5 Les deux entités, unité de traitement et accélérateur multimédia, peuvent travailler de façon asynchrone ou synchrone. Les données traitées sont uniques entre ces deux entités, il n'y a pas de transfert de données, d'où une faible occupation de la bande passante. La quantité mémoire nécessaire est moindre par rapport à l'art antérieur. Enfin, le suivi applicatif est simplifié. Un autre avantage de l'invention est de permettre un système faible puissance autorisant des affichages de qualité, dynamiques 10 et temps réel. Contrairement à certains systèmes de l'art antérieur où un jeu d'instruction peut être traité de façon câblée, ici c'est l'objet, considéré comme une entité, qui est traité de façon câblée, de façon électronique par opposition à un traitement logiciel de l'unité de traitement. Le fait de manipuler de façon électronique des "objets" construits par une unité de traitement informatique va dans le sens de la réduction des coûts de partage d'espace mémoire en vue d'une réduction de la quantité mémoire utilisée notamment dans le cadre de produits embarqués. On a ainsi remplacé le mécanisme d'interface standard, permettant d'une part de spécifier la définition des objets et leurs opérations, et d'autre part de récupérer leur état, par une solution selon l'invention où c'est l'objet lui-même qui sert de support d'échange. La partie descriptive de l'objet est crée et initialisée par le processeur principal (chargé par exemple du déroulement des scénarii d'I.H.M.), tandis qu'elle est utilisée et mise à jour de façon totalement matérielle, totalement "hardware" ou câblée, c'est à dire gérée électriquement selon des machines d'états, par le coprocesseur multimédia. Une telle approche selon l'invention conduit à la réalisation d'objets complètement autonomes et pris en charge par l'électronique, pouvant garantir l'aspect temps réel selon les besoins d'affichage indépendamment de la charge du CPU applicatif, garantissant par-là même l'aspect parallèle. On peut ainsi parler "d'objets câblés" ou "d'objets hardware". Pour mettre en uvre le procédé selon l'invention, on peut utiliser les technologies permettant de mettre à l'intérieur d'une même puce électronique plusieurs processeurs virtuels, tels - 6 que par exemple des FPGAs intégrant des cellules de traitement sous forme de composant VHDL. On peut alors gérer un même espace mémoire partagé entre plusieurs processeurs puisque l'électronique d'accès à la mémoire par les processeurs est elle- même réalisée à l'intérieur du composant. Par ailleurs, selon l'invention, à tout moment du cycle de vie d'un objet, les données de définition, spécifiées par le processeur principal, sont fusionnées avec les données d'exploitation qui régissent son comportement et qui sont maîtrisées par le coprocesseur. Contrairement à l'art antérieur, il n'y a plus besoin de tâche de suivi de l'objet et ce dernier existe de façon complètement autonome à travers son empreinte mémoire. C'est en ce sens que l'on peut parler "d'objet hardware", "d'objet câblé", puisqu'il n'y a plus transfert de données entre l'unité de traitement qui construit l'objet et le processus matériel ou "hardware" qui le manipule (mécanisme câblé). De manière plus précise, un objet structuré selon la présente invention est autonome car: - l'objet porte l'ensemble des informations nécessaires à sa propre description (son type propre, l'organisation de ses pixels en mémoire s'il s'agit d'un objet de type image bitmap, etc.) et celles exprimant la volonté de l'utilisateur quant à son affichage (sa position, sa transparence, etc.); - on peut lui associer une action ou une suite d'actions (décrites de façon comportementale et temporelle) capables de se dérouler sans suivi ni intervention de la partie applicative; - l'objet est capable d'évoluer visuellement (animation) ou de se transformer dans le temps en une autre forme (séquence de 30 "morphing"). La notion d'objet câblé permet à la partie électronique d'accéder de façon indépendante à n'importe quelle structure d'objet dans l'espace d'adressage mémoire partagé entre le "hardware" et le "software". Cela signifie qu'à un instant donné, il peut exister en mémoire un très grand nombre d'objets préparés par exemple à l'avance par le processeur d'I.H.M. et dont la position en mémoire est non prédéfinie et inconnue de l'accélérateur multimédia à l'avance. 2868854 - 7 En d'autres termes, le procédé selon l'invention permet de fusionner la gestion d'objets informatiques avec leur traitement électronique en garantissant l'unicité de leurs données de description, et la décorrélation totale de leur traitement par une cellule "hardware", de la partie applicative (logiciel) qui leur a donné naissance. Selon un mode de mise en uvre avantageux de l'invention, les données de définition comprennent des données définissant la classe de l'objet concerné. Pour diffuser l'objet, l'accélérateur multimédia extrait la classe de l'objet dans le descripteur, et dirige l'objet vers un mécanisme matériel câblé adapté à ladite classe. L'objet peut aussi bien être constitué par un espace mémoire contenant une image dont l'organisation pixel est définie par exemple en mode RGB 16, BGR24, noir & blanc, etc... ou bien par un fichier image compressé selon un algorithme fixé, ou bien même une figure géométrique définie de façon vectorielle (ligne, cercle, polygone, etc.). On appelle classe d'objet, l'ensemble des objets dont les caractéristiques demandent un traitement équivalent pour leur traitement. On peut citer entre autre, en ce qui concerne les éléments graphiques, des classes image bitmap, lignes, polygones, fenêtre vidéo, ... Avantageusement, les données d'exploitation comprennent, sous forme d'une action à mener par l'accélérateur multimédia, des données relatives au comportement de l'objet. Les données d'exploitations peuvent aussi comprendre une suite d'actions exécutées à la chaîne par l'accélérateur multimédia. Ainsi, à un objet peut être associé une action ou une suite d'actions qui vont définir son comportement. Le fonctionnement du coprocesseur étant déterministe (généralement cadencé sur la fréquence de trame vidéo), le comportement des objets est totalement maîtrisé d'un point de vue temporel et la spécification des actions est basée sur le temps réel. Une action est considérée comme une entité indépendante liée aux possibilités du mécanisme matériel. Les types d'actions sont donc de préférence prédéfinis (déplacement, apparition, disparition, effet visuel, etc.) mais peuvent être paramétrables par la partie applicative, par exemple, la spécification des coordonnées et de la vitesse d'un déplacement. Afin de permettre des comportements complexes - 8- d'objets, les actions peuvent être elles-mêmes chaînées, permettant ainsi au mécanisme matériel ("hardware") d'enchaîner sur une nouvelle action, dès la terminaison de l'action en cours ou après prise en compte d'un délai d'attente, sans aucune intervention de la partie applicative. C'est le mécanisme matériel qui effectue lui-même le chaînage entre les actions et la mise à jour de ses variables de travail. L'action s'arrête lorsque l'entité qui définit l'action courante ne fournit plus l'indirection pointant sur une action suivante. Avantageusement, les données d'exploitation comprennent en outre des données: - de transformation (dimensionnement, "resizing") permettant à l'accélérateur multimédia de modifier de façon automatique et autonome, l'aspect visuel d'un objet; - de chaînage de descripteurs permettant à l'accélérateur multimédia de gérer de façon automatique et autonome, la substitution d'un objet par un autre. A travers le terme de chaînage, on entend la possibilité pour un objet actif d'être substitué de façon toujours automatique par l'accélérateur multimédia sans intervention de la partie applicative, par un objet de représentation différente. On peut citer comme exemples d'application d'un tel besoin: - les objets animés, par exemple un icône en rotation: à chaque trame, ou après plusieurs trames, vidéo doit correspondre une image différente; - la déformation d'un objet aussi bien constitué par une image bitmap ("morphing") que par une description vectorielle. Dans ce cas, le but de la séquence est d'amener de façon progressive un objet d'une représentation initiale à une représentation finale. II s'agit d'un processus fini en terme d'étapes et borné temporellement, bien qu'il puisse être rebouclé (processus cyclique). Selon l'invention, l'accélérateur multimédia peut avantageusement introduire, par mécanisme matériel, des temporisations entre plusieurs actions et entre plusieurs objets d'un chaînage. Par ailleurs, on peut par exemple parler d'objet physique et d'objet logique. Un icône animé par exemple correspond pour l'application à un objet logique autonome, tandis que d'un point de vue de son empreinte mémoire, il sera constitué d'une suite d'objets physiques représentant toutes les étapes de l'animation. Selon l'invention, pour garantir un fonctionnement asynchrone et dynamique sans intervention du processus applicatif, l'architecture proposée est articulée autour de deux zones d'accès mémoires indépendantes - la mémoire partagée permettant la création et le stockage d'objets physiques la taille de la zone mémoire allouée conditionne directement le nombre d'objets physiques et donc l'aspect dynamique de l'application (permet les séquences d'animation et de transformation); et - la structure de commande, permettant d'activer ou d'inhiber l'affichage d'objets logiques à l'écran. Le nombre d'entrées possibles de cette structure est lié au nombre d'objets maximal traités simultanément par le coprocesseur multimédia. Pour spécifier quels sont les objets physiques qui doivent être pris en charge par le coprocesseur multimédia, on utilise donc la structure de commande qui peut être une mémoire partagée conventionnelle (registres, FIFO, etc.) dont l'adresse est fixée conventionnellement et connue à l'avance par le processeur applicatif principal. La seule information nécessaire à l'activation d'un objet se résume alors à la spécification de l'adresse mémoire contenant la description de l'objet. Les données d'exploitation peuvent encore comprendre des données de relations permettant à l'accélérateur multimédia d'exécuter de façon automatique des mécanismes de communication, tels que déclenchement, inhibition, changement de paramètres, etc..., entre plusieurs objets. Plusieurs objets peuvent être regroupés afin de fonctionner de façon synchrone. On peut étendre les paramètres de gestion intrinsèques à l'objet (incluant son comportement) au moyen des mécanismes de communication, il est alors possible de faire réagir l'objet à des stimuli tels que des évènements provenant de l'extérieur ou d'autres objets, et donc de construire des menus d'I.H.M. complètement câblés. Le regroupement ou l'association d'objets peut permettre également de lier la création ou la destruction d'objets, ainsi que leur comportement, pour assurer leur synchronisation d'un point de vue applicatif. 2868854 - 10 - De préférence, le descripteur d'objet est constitué par un ensemble d'espaces mémoires d'organisation (caractéristiques des différents champs du descripteur) prédéfinie au sein de la mémoire partagée. Il peut également être accessible par l'intermédiaire d'une indirection. En particulier, le descripteur reste à tout moment accessible à l'unité de traitement. En fait, la partie applicative est capable à tout moment de réaliser son contrôle sur l'objet (création, destruction, affichage, .. .) ou d'interagir avec ce dernier (changer sa position, ses attributs, ) Selon l'invention, l'accélérateur multimédia est apte à mettre à jour le descripteur ainsi que la structure de commande. Avantageusement, dans la mémoire partagée, les objets sont disséminés à des adresses mémoires dynamiques. L'accélérateur multimédia est devenu un système auto-suffisant pouvant traiter des objets dynamiques. Selon l'invention, l'unité de traitement peut élaborer, au préalable, une pluralité d'objets logiques. Puis, au cours de la diffusion, on élit en tant qu'objet physique, au moins l'un desdits objets logiques préélaborés pour une prise en charge par le mécanisme matériel câblé. Cette élaboration préalable permet de respecter de manière efficace les contraintes liées au temps réel. Suivant un autre aspect de l'invention, il est proposé un système pour gérer des objets multimédia à diffuser, en particulier audio ou graphique. Ce système comprenant une unité de traitement à laquelle on associe un accélérateur multimédia, ce dernier intégrant au moins un mécanisme matériel câblé. Selon l'invention, le système comprend. - une mémoire partagée entre l'unité de traitement et l'accélérateur multimédia, ladite mémoire partagée comprenant pour chaque objet, un descripteur créé par l'unité de traitement et comportant un ensemble de données rendant ledit objet autonome, ledit ensemble de données comprenant des données de définition de l'objet et des données d'exploitation de l'objet, et - une structure de commande comportant une pluralité d'espaces mémoires, l'adresse de stockage dudit descripteur étant stockée dans l'une au moins desdits espaces mémoires. Selon l'invention, l'accélérateur multimédia comprend: - des moyens pour s'activer à chaque fois que l'unité de traitement spécifie l'adresse d'un objet dans au moins un espace mémoire de la structure de commande, - des moyens pour prendre en charge le descripteur stocké à l'adresse contenue dans ledit espace mémoire de la structure de 10 commande spécifié par l'unité de traitement, et - des mécanismes matériels câblés pour diffuser et animer de façon totalement autonome et automatique, ledit objet autonome à partir dudit ensemble de données. D'autres avantages et caractéristiques de l'invention 15 apparaîtront à l'examen de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés, sur lesquels: - La figure 1 est une vue schématique illustrant le système selon l'invention; - La figure 2 est un exemple de l'organisation d'un descripteur d'objet selon l'invention; et La figure 3 est un schéma illustrant un procédé selon l'invention. Bien que l'invention n'y soit pas limitée, on va maintenant 25 décrire le procédé selon l'invention appliqué à l'affichage d'objet graphique sur un écran de visualisation. Sur la figure 1, on voit une partie applicative 1 dite "software", dans laquelle opère un processeur applicatif 3. Ce processeur 3 réalise les tâches "normales" pour la gestion d'une interface homme- machine par exemple. Pour décharger ce processeur applicatif 3, il est prévu un accélérateur matériel ou coprocesseur 4 installé dans une partie électronique 2 dite "hardware". Cette dernière peut être une carte graphique d'un PC destiné à afficher des images sur un écran de visualisation 7. Le coprocesseur comporte des mécanismes électroniques câblés permettant de réaliser des fonctions de façon matérielle. Les descripteurs, en particulier les objets physiques associés, sont disséminés dans la mémoire partagée 5 à des adresses mémoires 2868854 - 12 - dynamiques, c'est-à-dire à des adresses non connues avant l'exécution des programmes applicatifs. Tout descripteur porte de façon localisée l'ensemble des informations servant au traitement de l'objet associé qui conduira à l'affichage de cet objet sur l'écran 7. On notera l'aspect bidirectionnel des flèches 9 et 10 pointant sur la mémoire partagée 5 pour l'ensemble de ses accédants. En effet, la partie applicative 1 crée et initialise le descripteur de chaque objet, mais les objets ayant leur vie propre une fois pris en charge par le coprocesseur 4. La mise à jour des descripteurs peut s'effectuer par le coprocesseur 4 afin de maintenir la cohérence d'information et d'autoriser le suivi entre la partie applicative 1 et la partie électronique 2. La structure de commande 6 peut aisément être réalisée à l'aide de registres. Mais, bien que l'architecture décrite soit illustrée par deux zones d'accès mémoires distinctes 5 et 6, elle pourrait être réalisée en fixant un certain nombre d'adresses dédiées, faisant office de structure de commande 6, au sein de la même mémoire partagée 5. C'est l'écriture du pointeur d'objet 8 dans les registres de commande 6 qui déclenche la prise en compte de l'objet pointé pour son affichage sur l'écran 7 ou son effacement lors d'une suppression du pointeur. Sur la figure 2, on voit en détail un exemple d'organisation d'un descripteur d'objet selon l'invention. On distingue un premier groupe 11 de champs communs à toutes les classes objets, un second groupe 14 de champs dépendant de la classe objets associée à l'objet en question, et un troisième groupe 17 comprenant également des champs communs à toutes les classes objets. Les champs des groupes 11 et 17 sont à tailles fixes, alors que les champs du groupe 14 sont à tailles variables. Le groupe 14 comporte un premier champ 15 renfermant des données de définition de l'objet correspondant, ainsi qu'un second champ 16 renfermant des données diverses de communication. Lorsque le mécanisme câblé du coprocesseur 4 accède l'objet physique, il ne dispose que de la seule information de l'adresse du descripteur de données de l'objet. Or, l'objet peut être de différentes classes, demandant pour chaque classe un traitement électronique différent et adapté. Le premier champ traité du - 13- descripteur sera donc un champ d'identification 12 dans lequel le mécanisme "hardware" extraira l'information de classe et aiguillera par la même les données suivantes vers la cellule de traitement adaptée. L'identification, l'extraction des informations de la structure de base et le traitement d'une classe sont de la responsabilité du coprocesseur. Concrètement, cela signifie que les premières informations portées par le descripteur d'objet en mémoire sont constituées par un champ permettant d'identifier la classe d'objet, spécifiée par le logiciel applicatif, afin que le mécanisme "hardware" puisse exploiter les informations du descripteur. Ensuite sont stockées dans ce descripteur les informations consignant les attributs d'affichage 13 spécifiés par le processus applicatif. Ces attributs sont: position, placement, profondeur, coefficient de transparence, etc... Afin de conférer une réelle autonomie à l'objet, il faut ajouter une information capable d'être complètement contrôlée par un mécanisme"hardware", sans intervention de la partie applicative 1 et permettant de définir son comportement. Cette information supplémentaire est placée dans la structure de base du descripteur et considéré comme un pointeur sur une entité informatique qui définit une action ou une suite d'actions 18. L'élément clé de ce descripteur reste un pointeur de chaînage 19 sur un autre objet physique permettant au mécanisme "hardware" d'accéder de façon automatique à l'élément de représentation suivant de l'objet logique selon des conditions également décrites dans le descripteur, dans le champ 16 par exemple, (délai d'attente entre deux éléments de représentation, conditions, etc.). Lorsque l'objet physique courant (ou représentation de l'objet logique à un instant donné) arrive à la fin de son cycle de vie (ou de son délai d'activité), la cellule "hardware" charge et active automatiquement l'objet suivant pointé, selon un procédé complètement récurrent et automatique. A titre d'exemple, à chaque chaînage, le mécanisme "hardware" vient écraser, dans la structure de commande, l'adresse de l'objet actif pour mettre à la place de façon autonome l'adresse de l'objet indiqué dans le chaînage. On parle alors de mise à jour de la structure de commande par le mécanisme "hardware". - 14 - L'ordre des champs est sans importance dans le cadre d'une réalisation donnée. Les champs sont définis en cohérence avec le mécanisme "hardware". Les champs de tailles variables peuvent être constitués par (ou inclure) un pointeur d'indirection sur une autre zone mémoire. Les données d'actions peuvent être définies en tant que suite d'actions rebouclées ou non. Elles peuvent être constituées par un pointeur sur des entités mémoire chaînées, équivalent à des pointeurs d'actions. Sur la figure 3 on voit un exemple de réalisation de mécanisme "hardware" pour la gestion d'objets autonomes et de leurs actions. Les flèches en pointillées 20, 21, 22 indiquent une action de chaînage à l'aide d'un pointeur. On considère trois objets physiques (Objet 1 à 3) stockés et initialisés dans la mémoire partagée 5. Ils sont prêts à être exploités dans le cadre d'un objet logique. Un processus applicatif 3 active un objet logique en fournissant le pointeur d'adresse 8 de l'objet physique Objet 1 dans la structure de commande 6 (registres). Cela déclenche le mécanisme "hardware" qui l'affiche à l'écran. Puis à la trame suivante, il exécute en 23 la première action de la suite (23 et 22) d'actions qui lui est associée. On peut imaginer par exemple action 1 comme une action d'apparition et action 2 comme une action de déplacement. Une fois la dernière action de la chaîne d'action effectuée, action 2 ne pointant plus sur aucune action suivante, le pointeur d'objet 1 est remplacé en 20 par son pointeur d'objet suivant qui correspond au pointeur d'objet 2. Ce dernier s'affiche donc en 24 à la trame suivante. Une fois l'action 2 de l'objet 2 exécutée, l'objet 2 est remplacé en 21 à l'écran par l'objet 1. On se retrouve alors dans la condition initiale pour une animation en boucle conformément à l'organigramme de l'encadré 25. Bien qu'ayant été préparé par la tache applicative, l'objet physique Objet3 est prêt à être affiché à l'écran, mais ne l'est pas dans le scénario présenté. L'homme du métier comprendra que l'insertion de délais de 35 temporisation entre les actions est tout à fait possible d'un point de vue électronique et que sa faisabilité n'est dépendante que du choix de l'interface utilisateur. La présente invention permet donc à un coprocesseur électronique multimédia de gérer de façon indépendante des objets - 15- dynamiques. Les objets sont dits "autonomes" car une fois initialisés par une unité de traitement informatique, leur comportement et leur évolution sont totalement pris en charge par le mécanisme électronique intégré dans le coprocesseur multimédia. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. - 16-REVENDICATIONS 1. Procédé pour gérer des objets multimédia à diffuser au moyen d'une unité de traitement auquel on associe un accélérateur 5 multimédia, ledit accélérateur multimédia intégrant au moins un mécanisme matériel câblé, caractérisé en ce que: - pour chaque objet, on crée un descripteur comprenant un ensemble de données rendant ledit objet autonome, ledit ensemble de données comprenant des données de définition de l'objet et des données d'exploitation de l'objet, - on stocke ledit descripteur dans une mémoire partagée entre l'unité de traitement et l'accélérateur multimédia, - on stocke dans un espace mémoire d'une structure de commande, l'adresse de stockage dudit descripteur; et en ce qu'à chaque fois que l'unité de traitement spécifie l'adresse d'un objet dans au moins un espace mémoire de la structure de commande, on réalise les étapes suivantes: - activation de l'accélérateur multimédia, - prise en charge, par l'accélérateur multimédia, du descripteur stocké à l'adresse contenue dans ledit espace mémoire de la structure de commande spécifié par l'unité de traitement, l'accélérateur multimédia diffuse et anime de façon totalement autonome et automatique, par des mécanismes matériels câblés, ledit objet autonome à partir dudit ensemble de données. 2. Procédé selon la revendication 1, caractérisé en ce que lesdites données de définition comprennent des données définissant la classe de l'objet concerné. 3. Procédé selon la revendication 2, caractérisé en ce que pour diffuser l'objet, l'accélérateur multimédia extrait la classe de l'objet dans le descripteur, et dirige l'objet vers un mécanisme matériel câblé adapté à 4. Procédé selon l'une précédentes, caractérisé en d'exploitation comprennent, sousladite classe. quelconque des revendications ce que lesdites données forme d'une action à mener par l'accélérateur multimédia, des données relatives au comportement de l'objet. 2868854 - 17- 5. Procédé selon la revendication 4, caractérisé en ce que les données d'exploitations comprennent une suite d'actions exécutées à la chaîne par l'accélérateur multimédia. 6. Procédé selon la revendication 5, caractérisé en ce que 5 l'accélérateur multimédia introduit, par mécanisme matériel, des temporisations entre plusieurs actions. 7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que chaque action est prédéfinie. 8. Procédé selon l'une quelconque des revendications 4 à 7, 10 caractérisé en ce que chaque action est paramétrable. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites données d'exploitation comprennent des données de transformation permettant à l'accélérateur multimédia de modifier de façon automatique et autonome, l'aspect visuel d'un objet. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites données d'exploitation comprennent des données de chaînage de descripteurs permettant à l'accélérateur multimédia de gérer de façon automatique et autonome, la substitution d'un objet par un autre. 11. Procédé selon la revendication 10, caractérisé en ce que l'accélérateur multimédia introduit, par mécanisme matériel, des temporisations entre plusieurs objets d'un chaînage. 12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites données d'exploitation comprennent des données de relations permettant à l'accélérateur multimédia d'exécuter de façon automatique des mécanismes de communication entre plusieurs objets. 13. Procédé selon la revendication 12, caractérisé en ce que plusieurs objets sont regroupés afin de fonctionner de façon synchrone. 14. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le descripteur d'objet est 35 constitué par un ensemble d'espaces mémoires d'organisation prédéfinie au sein de la mémoire partagée. 2868854 - 18 - 15. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le descripteur reste à tout moment accessible à l'unité de traitement. 16. Procédé selon l'une quelconque des revendications 5 précédentes, caractérisé en ce que l'accélérateur multimédia met à jour le descripteur. 17. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'accélérateur multimédia met à jour la structure de commande. 18. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que dans la mémoire partagée, les objets sont disséminés à des adresses mémoires dynamiques. 19. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'unité de traitement élabore au préalable une pluralité d'objets logiques, et en ce qu'au cours de la diffusion, on élit en tant qu'objet physique, au moins l'un desdits objets logiques préélaborés pour une prise en charge par le mécanisme matériel câblé. 20. Système pour gérer des objets multimédia à diffuser, comprenant une unité de traitement à laquelle on associe un accélérateur multimédia, ledit accélérateur multimédia intégrant au moins un mécanisme matériel câblé, caractérisé en ce que le système comprend: - une mémoire partagée entre l'unité de traitement et l'accélérateur multimédia, ladite mémoire partagée comprenant pour chaque objet, un descripteur créé par l'unité de traitement et comportant un ensemble de données rendant ledit objet autonome, ledit ensemble de données comprenant des données de définition de l'objet et des données d'exploitation de l'objet, - une structure de commande comportant une pluralité d'espaces mémoires, l'adresse de stockage dudit descripteur étant stockée dans l'une au moins desdits espaces mémoires; et en ce que l'accélérateur multimédia comprend: - des moyens pour s'activer à chaque fois que l'unité de 35 traitement spécifie l'adresse d'un objet dans au moins un espace mémoire de la structure de commande, - 19- - des moyens pour prendre en charge le descripteur stocké à l'adresse contenue dans ledit espace mémoire de la structure de commande spécifié par l'unité de traitement, et - des mécanismes matériels câblés pour diffuser et animer 5 de façon totalement autonome et automatique, ledit objet autonome à partir dudit ensemble de données.