FR3099262A1 - Système de traitement graphique de données - Google Patents

Système de traitement graphique de données Download PDF

Info

Publication number
FR3099262A1
FR3099262A1 FR1908358A FR1908358A FR3099262A1 FR 3099262 A1 FR3099262 A1 FR 3099262A1 FR 1908358 A FR1908358 A FR 1908358A FR 1908358 A FR1908358 A FR 1908358A FR 3099262 A1 FR3099262 A1 FR 3099262A1
Authority
FR
France
Prior art keywords
data
graphic
instructions
data processing
formatting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1908358A
Other languages
English (en)
Other versions
FR3099262B1 (fr
Inventor
Olivier Roche
Romain De Bossoreille
MIchael Nahmiyace
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Safran Electronics and Defense Cockpit Solutions SAS
Original Assignee
Zodiac Aero Electric SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zodiac Aero Electric SAS filed Critical Zodiac Aero Electric SAS
Priority to FR1908358A priority Critical patent/FR3099262B1/fr
Priority to EP20742294.0A priority patent/EP4004755A1/fr
Priority to PCT/EP2020/070839 priority patent/WO2021013948A1/fr
Priority to CN202080054355.2A priority patent/CN114175089A/zh
Priority to US17/629,353 priority patent/US20220250764A1/en
Publication of FR3099262A1 publication Critical patent/FR3099262A1/fr
Application granted granted Critical
Publication of FR3099262B1 publication Critical patent/FR3099262B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/78Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7828Architectures of general purpose stored program computers comprising a single central processing unit without memory
    • G06F15/7832Architectures of general purpose stored program computers comprising a single central processing unit without memory on one IC chip (single chip microprocessors)
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00General purpose image data processing
    • G06T1/20Processor architectures; Processor configuration, e.g. pipelining
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B64AIRCRAFT; AVIATION; COSMONAUTICS
    • B64DEQUIPMENT FOR FITTING IN OR TO AIRCRAFT; FLIGHT SUITS; PARACHUTES; ARRANGEMENT OR MOUNTING OF POWER PLANTS OR PROPULSION TRANSMISSIONS IN AIRCRAFT
    • B64D43/00Arrangements or adaptations of instruments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G06F3/147Digital output to display device ; Cooperation and interconnection of the display device with other functional units using display panels
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/005General purpose rendering architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2200/00Indexing scheme for image data processing or generation, in general
    • G06T2200/24Indexing scheme for image data processing or generation, in general involving graphical user interfaces [GUIs]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Graphics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Human Computer Interaction (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Processing Or Creating Images (AREA)
  • Digital Computer Display Output (AREA)

Abstract

Système de traitement graphique de données (1), comprenant au moins cœur (C1-C4) de traitement graphique de données comportant des moyens de mise en forme (2) aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme-machine, caractérisé en ce que lesdits moyens de mise en forme (2) sont répartis sur un ou plusieurs cœurs (C1-C4). Figure pour l’abrégé : Fig 1

Description

Système de traitement graphique de données
La présente invention concerne les systèmes de traitement graphique de données et plus particulièrement les systèmes monocœur et multicœur pour interface graphique.
Elle se rapporte à une interface homme-machine utilisant un tel système de traitement.
Une application particulièrement intéressante de l’invention concerne les systèmes de traitement de données pour interfaces homme-machine embarquées à bord d’aéronefs.
Ainsi, dans ce domaine, les systèmes de traitement de données sont classiquement utilisés pour exécuter des calculs graphiques et créer des contenus graphiques destinés à être affichés sur un écran de l’interface. Il peut en particulier s’agir de créer des contenus graphiques comportant des zones tactiles manipulables manuellement, en l’espèce par un pilote, pour l’exécution de fonctions prédéfinies.
Pour la réalisation de calculs graphiques, on utilise, de manière générale, au moins un processeur de calculs graphiques (GPU, pour « Graphic Processing Unit ») coopérant avec au moins une unité centrale de traitement CPU (pour « Central Processing Unit » en anglais).
Les architectures GPU sont des architectures de calcul exécutant un jeu d’instructions tels que des calculs bidimensionnels ou tridimensionnels permettant de construire une image.
Les GPU peuvent être composés d’un cœur unique ou de multiples cœurs de calcul qui se répartissent les tâches graphiques. Il s’agit d’architectures de traitement partiellement ou entièrement parallèles.
En ce qui concerne les systèmes de traitement de données destinés à être embarqués à bord d’aéronefs, comme on le conçoit, ce type de système électronique est soumis à des contraintes sévères de maîtrise du matériel employé et de déterminisme, qui impose de déterminer de manière certaine le fonctionnement du système, par exemple en ce qui concerne la durée de transfert de données. Ils nécessitent une validation et une certification par les autorités compétentes.
Les systèmes de traitement de données pour les interfaces homme-machine embarqués pour avions commerciaux doivent ainsi satisfaire un certain nombre de règles et de recommandations de développement.
Dans l’état de la technique, les systèmes de calcul embarqués sont généralement réalisés à partir de composants pris sur étagère ou « COTS » (pour « Commercial Off The Shelf »), c’est-à-dire de composants fabriqués en grande série pour réduire les coûts de fabrication et de maintenance.
Généralement, les composants constituant la chaîne de traitement pour les interfaces homme-machine sont groupés dans une unique zone par exemple un cœur physique.
On entend par « chaîne de traitement », une série de modules configurés sur ces composants et comprenant au moins une application graphique, communément appelée « User Application » en anglais, ci-après UA, générant des instructions pour l’exécution de fonctions graphiques prédéfinies aidant au pilotage des aéronefs.
La chaîne de traitement comprend également au moins une unité de calcul graphique GPU et optionnellement un système d’affichage dans un poste de pilotage (CDS « Cockpit Display System » selon le vocable anglosaxon), ci-après CDS s’il n’y a pas de norme à respecter.
Enfin, la chaîne de traitement est délimitée par au moins un dispositif périphérique relié à un ou à plusieurs écrans d’affichage par exemple des écrans LCD.
Compte tenu du temps de développement et de la durée de vie d’un produit pour l’aéronautique, qui peut atteindre plusieurs dizaines d’années, il est courant que les composants utilisés lors de la conception de la chaîne de traitement soient en fait obsolètes même avant la fin du processus de conception, obligeant à réaliser des phases de modification et de recertification périodique.
Autrement dit, le remplacement d’un de ces composants par de nouveaux composants différents conduit à recertifier tous les composants de la chaîne de traitement pour vérifier qu’il n’y ait pas de perturbations, ce qui peut être lent et coûteux.
En outre, les besoins relatifs à la composition de la chaîne de traitement diffèrent selon les industriels, obligeant le fournisseur à reconfigurer lesdits modules modifiant également leur emplacement, ce qui peut nécessiter des certifications à chaque nouvelle configuration.
Au vu de ce qui précède, l’invention se propose de pallier aux contraintes précitées dans un système de traitement graphique de données.
L’invention a donc pour objet, selon un premier aspect, un système de traitement graphique de données, comprenant un au moins un cœur de traitement graphique de données comportant des moyens de mise en forme aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme-machine, et dans lequel lesdits moyens de mise en forme sont répartis sur un ou plusieurs cœurs.
Par « interprétation » on entend la possibilité de lire des données sous forme graphique ou sous forme d’un langage informatique, et d’exécuter les actions demandées ou nécessaires suite à cette lecture.
On peut citer par exemple le fait pour un pilote d’appuyer sur un bouton tactile affiché sur son écran conduisant par exemple à l’enclenchement d’un évènement et donc à l’exécution d’une fonction.
Les moyens de mise en forme ont ainsi interprété des données sous forme graphique.
En outre, étant donné qu’appuyer sur un bouton tactile peut supposer que celui-ci change de forme graphique, des données sous forme d’instructions seront, dans ce cas, envoyées aux moyens de mise en forme pour modifier ladite forme du bouton.
Ces moyens de mise en forme sont ici répartis sur un ou plusieurs cœurs. Autrement dit, chaque cœur physique est entièrement ou partiellement partitionné et peut comporter une partie des moyens de mise en forme ou tout l’ensemble.
Cela permet de réaliser une certification incrémentale.
Il est donc possible de mettre à jour une partie des moyens de mise en forme contenue dans un cœur physique sans devoir recertifier les autres parties des moyens de mise en forme accessibles via les autres cœurs physiques ou contenus dans le même cœur.
Avantageusement, les moyens de mise en forme comprennent des moyens de conversion aptes à convertir les données échangées via l’interface homme-machine, soit sous la forme graphique, soit sous la forme d’instructions, au moins un module de traitement apte à générer les instructions, et des moyens d’affichage aptes à afficher lesdites données sous forme graphique.
Ledit au moins un module de traitement est couplé aux moyens de conversion, eux-mêmes couplés auxdits moyens d’affichage.
On entend par « module de traitement » tout module UA apte à recevoir des données de capteurs par exemple et à générer des instructions pour représenter graphiquement lesdites données reçues.
Ces instructions sont envoyées auxdits moyens de conversion. Le module de traitement est aussi apte à recevoir des données suite à une interaction homme-machine, par exemple un appui sur un bouton, puis à envoyer des données sous forme d’instructions graphiques aux moyens de conversion pour éventuellement modifier le rendu du bouton.
Les moyens de conversion permettent, une fois les instructions graphiques reçues par le module UA, d’assurer des fonctions de calcul de l’affichage à projeter sur un écran par exemple LCD.
Cette projection est rendue possible grâce à des moyens d’affichage sous forme de périphériques couplés à un ou à un plusieurs écrans d’affichage.
De préférence, les moyens de conversion comprennent au moins un module de mise en conformité apte à conformer les données à une norme de communication et d’affichage aéronautique ou automobile, et au moins une unité de calcul graphique apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de mise en conformité et à les convertir en données aptes à être affichées par les moyens d’affichage.
Ledit au moins un module de mise en conformité est de type CDS. Plus particulièrement, les données reçues par ledit au moins un module de traitement, sont rendus conforme à une norme telle que « ARINC 661 Part 1 » ou « ARINC 661 Part 2 ».
Par la suite, ces données conformes seront envoyées à au moins une unité de calcul graphique GPU apte à exécuter des fonctions de calcul pour permettre auxdites données d’être affichées sous forme graphique.
Bien sûr, les données peuvent être réparties entre plusieurs unités de calcul graphique aptes à fonctionner partiellement ou entièrement en parallèle.
Alternativement, les moyens de conversion comprennent au moins une unité de calcul graphique apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de traitement et à les convertir en données aptes à être affichées par les moyens d’affichage.
En d’autres termes, les moyens de conversion sont ici optionnels. Par exemple, dans le cas où il n’y a pas de norme à respecter, le module de traitement UA peut envoyer une valeur d’altitude à afficher qui ne nécessite généralement pas de mise en conformité avec un standard quelconque.
Avantageusement, la répartition des moyens de mise en forme est configurable.
Ainsi, l’architecture comprenant les moyens de mise en forme est entièrement modulaire. Autrement dit, on peut avoir par exemple, un module de traitement UA par cœur physique.
Cette configuration est particulièrement avantageuse étant donné que la mise à jour d’un module de traitement UA n’entraîne pas la mise à jour et la recertification des autres modules de traitement UA.
Ceci est également le cas pour le module CDS et l’unité de calcul graphique GPU.
Il est à noter qu’on peut également avoir un ensemble de modules de traitement UA et/ou de modules CDS et/ou d’unités de calcul graphique par cœur physique.
On peut aussi choisir une autre configuration à tout moment. Par exemple, on peut choisir de répartir un ou plusieurs modules CDS sur plusieurs cœurs physiques ou les grouper dans un seul cœur physique.
Chaque unité de calcul graphique GPU est ainsi apte d’adresser ou un plusieurs écrans d’affichage.
De préférence, les moyens de mise en forme sont raccordés entre eux au moyen d’au moins un système de communication apte à autoriser les échanges de données entre lesdits moyens de mise en forme.
Le système de communication peut être un bus commun entre les moyens de mise en forme.
L’invention a encore pour objet une interface graphique pour cockpit d’aéronef comprenant un système de traitement graphique de données tel que défini ci-dessus.
D’autres buts, caractéristiques et avantages de l’invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés sur lesquels :
illustre un exemple de l’architecture générale d’un système de traitement de données conventionnel réalisé à partir de composants COTS ;
représentent différentes configurations alternatives et exemplatives des moyens de mise en forme selon l’invention.
On a représenté sur la figure 1 l’architecture générale d’un système de traitement graphique de données selon l’invention, d’une interface homme-machine, désignée sous la référence numérique générale 1.
L’architecture générale 1 est ici multicœur. Elle peut évidemment être monocœur.
Elle comprend, dans cet exemple de mode de réalisation, un ensemble de cœurs physiques de traitement de données C1-C4, ici au nombre de quatre, reliés entre eux par un système de communication B1, ici un bus de communication partagé apte à autoriser les échanges de données entre lesdits cœurs physiques C1 à C4.
Chaque cœur physique de traitement est apte à fonctionner complètement ou partiellement en parallèle permettant de traiter des informations de manière simultanée dans le but de réaliser le plus grand nombre d’opérations en un temps plus court.
Comme on le voit sur la figure, chaque cœur de traitement C1-C4 comprend des moyens de mise en forme 2 aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme-machine non représentée ici.
Autrement dit, les moyens de mise en forme 2 sont aptes à lire des données sous forme graphique ou sous la forme d’un langage informatique, et d’exécuter les actions demandées ou nécessaires suite à cette lecture.
Le langage informatique peut être par exemple le langage de programmation C ou C++.
Les moyens de mise en forme 2 comportent une zone mémoire partitionnée en un ensemble de zones mémoires ZM aptes à stocker des programmes participant à l’interprétation sous forme graphique ou sous forme d’instructions les données échangés via l’interface homme-machine.
Chaque programme stocké dans une zone mémoire ZM peut communiquer avec un autre programme stocké dans une autre zone mémoire ZM à l’intérieur du même cœur C1-C4.
Cette communication peut être réalisée par exemple via un bus de communication B2 apte à transférer les données résultant desdits programmes.
Cette architecture multicœur de traitement graphique des données peut être entièrement ou partiellement partitionnée.
Cela permet de réaliser une certification incrémentale.
Il est donc possible de mettre à jour une partie des moyens de mise en forme 2 contenue dans un cœur physique sans devoir recertifier les autres parties des moyens de mise en forme 2 accessibles via les autres cœurs physiques ou contenus dans le même cœur physique.
Autrement dit, dans une architecture partitionnée, une modification d’un module UA ou CDS ou GPU contenu dans une partition, permet d’éviter de recertifier les autres modules contenus dans d’autres partitions.
Ce partitionnement est également modulaire, ce qui permet d’avoir plusieurs configurations alternatives possibles des moyens de mise en forme 2, dont certaines sont représentées sur les figures 2A à 2E.
Les moyens de mise en forme 2 comprennent au moins trois types de modules, illustrés dans la figure 2A, c’est-à-dire, UA, des moyens d’affichage EC sous la forme de périphériques, GPU et/ou CDS ici sous la dénomination PL.
Ces modules sont configurables et partitionnés dans les cœurs C1-C4.
Sur la figure 2A est illustré un premier exemple de configuration. Ici, un unique module de traitement UA est couplé à un unique module de conversion PL, lui-même couplé à un unique périphérique d’affichage, et cela dans le même cœur C1.
Cette configuration est reproduite dans les trois autres cœurs C2, C3 et C4.
Ainsi, si un de ces modules UA devait être modifié, les autres modules de traitement UA opérationnels ne seront pas mis à jour et/ou recertifiés.
On peut également avoir, comme illustré dans la figure 2B, un unique module de traitement UA stocké dans le cœur C1, couplé à un premier module de conversion PL1 stocké dans le cœur C3, et couplé à un deuxième et à un troisième module de conversion respectivement PL2, PL3, stockés dans le cœur C2.
Une autre configuration possible, représentée dans la figure 2C, serait de stocker un premier et un deuxième module de traitement UA1, UA2 dans le cœur C4 et les coupler à un module de conversion PL stocké dans le même cœur C4.
Le module de conversion PL peut être également couplé à un troisième module de traitement UA3 stocké dans le cœur C3, et à trois moyens d’affichage EC1, EC2 et EC3 qui sont, comme illustré dans la figure 2D, dans le cœur C4.
Une autre alternative serait de stocker le premier, le deuxième et le troisième module de conversion PL1, PL2 et PL3, et les moyens d’affichage EC dans le même cœur C4 comme représenté sur la figure 2E.
Bien évidemment, ces configurations sont données à titre d’exemples non limitatifs.
Ainsi, le partitionnement modulaire des cœurs physiques C1 à C4 permet de modifier la configuration des moyens de mise en forme 2 selon les besoins du système tout en réduisant le nombre de modules à mettre à jour et/ou à recertifier si l’un d’eux devait être modifié.

Claims (7)

  1. Système de traitement graphique de données (1), comprenant au moins un cœur (C1-C4) de traitement graphique de données comportant des moyens de mise en forme (2) aptes à interpréter sous forme graphique ou sous forme d’instructions les données échangées via une interface homme-machine, caractérisé en ce que lesdits moyens de mise en forme (2) sont répartis sur un ou plusieurs cœurs (C1-C4).
  2. Système selon la revendication 1, dans lequel les moyens de mise en forme (2) comprennent des moyens de conversion (PL) aptes à convertir les données échangées via l’interface homme-machine soit sous la forme graphique, soit sous la forme d’instructions, au moins un module de traitement (UA) apte à générer les instructions, et des moyens d’affichage (EC) aptes à afficher lesdites données sous forme graphique, ledit au moins un module de traitement (UA) étant couplé aux moyens de conversion (PL), eux-mêmes couplés auxdits moyens d’affichage (EC).
  3. Système selon la revendication 2, dans lequel les moyens de conversion (PL) comprennent au moins un module de mise en conformité (CDS) apte à conformer les données à une norme de communication et d’affichage aéronautique ou automobile, et au moins une unité de calcul graphique (GPU) apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de mise en conformité (CDS) et à les convertir en données aptes à être affichées par les moyens d’affichage (EC).
  4. Système selon la revendication 2, dans lequel les moyens de conversion (PL) comprennent au moins une unité de calcul graphique (GPU) apte à recevoir les données résultant de la mise en œuvre dudit au moins un module de traitement (UA) et à les convertir en données aptes à être affichées par les moyens d’affichage (EC).
  5. Système selon l’une quelconque des revendications précédentes, dans lequel la répartition des moyens de mise en forme (2) est configurable.
  6. Système selon l’une quelconque des revendications précédentes, dans lequel les moyens de mise en forme (2) sont raccordées entre eux au moyen d’au moins un système de communication (B1, B2) apte à autoriser les échanges de données entre lesdits moyens de mise en forme (2).
  7. Interface graphique pour cockpit d’aéronef, caractérisé en ce qu’elle comporte un système de traitement graphique de données (1) selon l’une quelconque des revendications 1 à 6.
FR1908358A 2019-07-23 2019-07-23 Système de traitement graphique de données Active FR3099262B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1908358A FR3099262B1 (fr) 2019-07-23 2019-07-23 Système de traitement graphique de données
EP20742294.0A EP4004755A1 (fr) 2019-07-23 2020-07-23 Système de traitement graphique de données
PCT/EP2020/070839 WO2021013948A1 (fr) 2019-07-23 2020-07-23 Système de traitement graphique de données
CN202080054355.2A CN114175089A (zh) 2019-07-23 2020-07-23 图形数据处理系统
US17/629,353 US20220250764A1 (en) 2019-07-23 2020-07-23 Graphic data processing system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1908358A FR3099262B1 (fr) 2019-07-23 2019-07-23 Système de traitement graphique de données
FR1908358 2019-07-23

Publications (2)

Publication Number Publication Date
FR3099262A1 true FR3099262A1 (fr) 2021-01-29
FR3099262B1 FR3099262B1 (fr) 2023-10-20

Family

ID=68425091

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1908358A Active FR3099262B1 (fr) 2019-07-23 2019-07-23 Système de traitement graphique de données

Country Status (5)

Country Link
US (1) US20220250764A1 (fr)
EP (1) EP4004755A1 (fr)
CN (1) CN114175089A (fr)
FR (1) FR3099262B1 (fr)
WO (1) WO2021013948A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120319965A1 (en) * 2011-06-16 2012-12-20 Empire Technology Development Llc Process management in a multi-core environment
FR3019668A1 (fr) * 2014-04-07 2015-10-09 Zodiac Aero Electric Systeme multicoeur de traitement de donnees a dispositifs d'entree/sortie locaux et globaux et interface graphique comportant un tel systeme de traitement de donnee
US20150379670A1 (en) * 2014-06-30 2015-12-31 Altug Koker DATA DISTRIBUTION FABRIC IN SCALABLE GPUs
EP3579109A1 (fr) * 2018-06-08 2019-12-11 Honeywell International Inc. Système et procédé de traitement réparti de composants de serveur graphique

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9235871B2 (en) * 2014-02-06 2016-01-12 Oxide Interactive, LLC Method and system of a command buffer between a CPU and GPU

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120319965A1 (en) * 2011-06-16 2012-12-20 Empire Technology Development Llc Process management in a multi-core environment
FR3019668A1 (fr) * 2014-04-07 2015-10-09 Zodiac Aero Electric Systeme multicoeur de traitement de donnees a dispositifs d'entree/sortie locaux et globaux et interface graphique comportant un tel systeme de traitement de donnee
US20150379670A1 (en) * 2014-06-30 2015-12-31 Altug Koker DATA DISTRIBUTION FABRIC IN SCALABLE GPUs
EP3579109A1 (fr) * 2018-06-08 2019-12-11 Honeywell International Inc. Système et procédé de traitement réparti de composants de serveur graphique

Also Published As

Publication number Publication date
WO2021013948A1 (fr) 2021-01-28
US20220250764A1 (en) 2022-08-11
FR3099262B1 (fr) 2023-10-20
CN114175089A (zh) 2022-03-11
EP4004755A1 (fr) 2022-06-01

Similar Documents

Publication Publication Date Title
EP1594091B1 (fr) Système et méthode pour améliorer un pipeline graphique
JP2020524866A (ja) コンテンツ取引合意のシステムおよび方法
US20230256826A1 (en) Three-Dimensional Cluster Simulation on GPU-Less Systems
US8943287B1 (en) Multi-core processor system configured to constrain access rate from memory
WO2010048637A2 (fr) Conversion de données 3d en données hogel
US20090150555A1 (en) Memory to memory communication and storage for hybrid systems
WO2009004023A1 (fr) Système d'affichage d'applications avioniques et non-avioniques
US10902000B2 (en) Heartbeat propagation in a distributed stream processing system
FR2946769A1 (fr) Procede et dispositif de reconfiguration d'avionique.
CA2887077C (fr) Systeme de traitement de donnees pour interface graphique et interface graphique comportant un tel systeme de traitement de donnees
EP3204867B1 (fr) Système embarqué sur puce à haute sûreté de fonctionnement
FR2963121A1 (fr) Procede et dispositif de protection de commandes logicielles dans un cockpit d'aeronef
US20220107777A1 (en) Content fidelity adjustment based on user interaction
EP2511842A1 (fr) Consultation de maquettes numériques à partir de postes légers
EP3103726B1 (fr) Panneau de commande configurable pour cockpit d'aéronef et procédé de configuration d'un tel panneau
FR3099262A1 (fr) Système de traitement graphique de données
US9767179B2 (en) Graphical user interface for modeling data
De Munck et al. Revisiting conservative time synchronization protocols in parallel and distributed simulation
FR2971596A1 (fr) Dispositif pour accelerer l'execution d'une simulation systemc
EP2507590A1 (fr) Dispositif d'affichage d'informations critiques et non critiques, et aeronef incorporant un tel dispositif
JP2013009044A (ja) 制御装置、処理装置、処理システム、制御プログラム
WO2014090514A1 (fr) Procédé de création de simulateur de configuration client
US11949761B2 (en) Techniques for distributed interface component generation
FR2992086A1 (fr) Dispositif de composition d'image
FR2958440A1 (fr) Systeme d'affichage de graphiques sur ecran, dispositifs et procedes associes

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210129

PLFP Fee payment

Year of fee payment: 3

CD Change of name or company name

Owner name: SAFRAN ELECTRONICS & DEFENSE COCKPIT SOLUTIONS, FR

Effective date: 20211004

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6