Discussion :

[Lsong]

Bonjour à tous,

Une présentation succincte :
TYPE : Bibliothèque générique de distribution de calculs. La première application concernera un moteur de physique pour le jeu vidéo.
NOM : 4D Game Engine Library.
TECHNO : C++ standard.
SITE : Désolé pour l'instant c'est en cours.
EQUIPE : Nous sommes trois
- Lsong 32 ans : moi même, je suis dans le développement Java(première version) et C++ (deuxième version, et troisième dont on commence le refactoring)
- fraggy 34 ans : architecture logicielle (analyse, conception, refactoring) et recherche de partenaires et de clients.
- ??? n'est pas inscrite sur le forum 33 ans : gestion et administration d'entreprise.

Nous avons bien quelques idées de scénarios mais le but de ce post n'est pas de monter une équipe amateur pour faire un jeu vidéo, cela dit, ça reste une option s'il y a des personnes suffisamment motivées.

L'avenir est aux processeurs multicores
On peut dire aujourd'hui que le processeur le plus performant sera celui qui aura le plus de coeurs. Intel a déjà mis sur le marché des Quad-core et dispose d'un processeur de laboratoire de 80 coeurs (http://www.pcinpact.com/actu/news/34...s-teraflop.htm). De même AMD prévoit ses Opterons quadricoeurs pour le milieu de cette année et travaille certainement sur des architectures plus musclées. Dans le domaine des consoles de jeu vidéo, le PowerPC tricoeurs hyperthreading équipe la XBox 360 de microsoft, le processeur 16 coeurs "the Rock" de Sun pourrait très bien convenir à la prochaine génération de console de jeu vidéo :p.
L'exploitation de ces architectures processeurs ne peut passer que par le développement multithread et le but de ce projet est d'apporter une solution pérenne à ce type de développement.

L'objectif de ce projet :
Il s'agit de proposer une bibliothèque permettant le calcul parallèle dans des domaines où les informations sont très liées, comme le moteur de physique d'un jeu vidéo.
Nous disposons actuellement d'un moteur de physique très basique en 2D basé sur des algorithmes gérant des cercles, des murs, la gravité ainsi que les collisions cercle-cercle et cercle-mur. Un démonstrateur est opérationnel et montre une augmentation de puissance de l'ordre de 300% sur un Quad-Core (il reste des parties non parallélisées).

La programmation parallèle :
Avant d'aller plus loin je vais vous présenter brièvement les principales méthodes de programmation parallèle, pour que chacun comprenne de quoi il en retourne car le sujet est assez vaste et complexe.

Il existe deux grands modèles pour paralléliser des calculs dans le cadre d'un jeu vidéo (http://www.gamasutra.com/features/20...onen_03.shtml).

- La décomposition fonctionnelle Le plus évident et le plus utilisé actuellement
Il s'agit de découper le jeu en fonctions (l'affichage, Physique, IA, son etc ...) et de les mettre sur des threads séparés, un exemple récent :

Supreme Commander
Afin de tirer au mieux parti des derniers processeurs disponibles, les ingénieurs de GPG ont fait de Supreme Commander un jeu multithread, c'est-à-dire qu’il est capable de tirer parti des processeurs dotés de 1, 2 et même 4 core. Pour ce faire, ils ont opté pour une gestion du threading « relativement » simple, c'est-à-dire que chaque grande partie du jeu est un thread. Il y en a notamment un pour la partie graphique, un autre pour la partie simulation, et d’autres annexes moins gourmands pour le son notamment.

C'est un système qui a fait ses preuves et qui exploite parfaitement un dual core. Ce type d'architecture se repartit très bien sur 2, 3 voir 4 coeurs (3 dans cas de Supreme commander), mais qu'adviendra-t-il quand les processeurs auront 8 cores ou plus ?

- La décomposition basée sur les données
Il s'agit de séparer les données en blocs distinct et de traiter ces blocs en parallèle. Ce type de programmation est très simple quand il s'agit de groupe de données indépendants, comme un rendu 3D (chaque mesh peut être préparée séparément), de la compression audio/vidéo, etc ...
L'avantage de ce modèle, c'est qu'il fonctionnera très bien sur une architecture 4-8-cores ou plus, ou sur un super calculateur comme BleuGene/L "65 536 processeurs double-coeurs, soit 131 072 coeurs de PowerPC 440 à 700 Mhz" (Ok personne n'a ça à la maison, mais ça viendra peut être).

Dans le cas du monde virtuel d'un jeu vidéo, les données sont intimement liées entre elles (le déplacement d'un objet peut perturber potentiellement l'ensemble de tous les autres objets). Si on découpe ce monde virtuel en zones contiguës indépendante et que l'on traite chaque zone en parallèle, il faudra prendre le temps de synchroniser chaque zone pour maintenir la cohérence dans le monde virtuel. Cette synchronisation est particulièrement couteuse en temps. C'est pour cela que les jeux vidéo actuels n'exploitent pas ce type de découpage, les gains obtenus par ce modèle sont éclipsés par le temps consacré à la synchronisation.

Une autre limite de ce modèle concerne le non déterminisme de l'ordre d'exécution, c'est à dire que rien ne peut prédire dans quel ordre vont se lancer les threads, ce qui entraine des problèmes de cohérence (en particulier pour les jeux en réseau).

Notre choix :
Nous avons pris le parti de travailler sur le modèle par répartition de donnée, les algorithmes que nous avons développé permettent de :
- synchroniser le monde avec des performances compatibles avec la réalisation d'un jeu vidéo.
- résoudre les problèmes liés au non déterminisme du modèle et faire des moteurs utilisable pour des jeux en réseau.

En forçant l'affinité du programme sur un seul coeur, notre démonstrateur gère environ 4000 cercles en mouvement et en collision.
Avec les 4 coeurs actif (Sur un Quad-core Q6600), le moteur gère jusqu'a 12000 cercles...
On obtient un gain de performance de l'ordre de 300% sur les calculs de physique, la perte est due en partie à l'affichage des 12000 cercles qui finissent par monopoliser un core entier.

Nos besoins :
- Rencontrer des partenaires industriels intéressés par le co-développement d'un moteur de jeu vidéo avec l'aide de cette bibliothèque. Donc si vous travaillez dans l'industrie du jeu vidéo ou si vous connaissez quelqu'un qui y travaille, pensez à nous !
- On aimerais aussi tester notre démonstrateur sur une machine comportant 8 coeurs ou plus (genre un bi ou quadri processeur quadricore)
- On aimerais rencontrer un développeur de moteur de physique qui connaitrait bien ODE (idéalement).

LSong

[Mat.M]

Notre besoin actuelle est de rencontrer des partenaires industriel intéressés par développer sur cette librairie. Donc si vous travaillait dans le jeux vidéo ou que vous connaissait quelqu'un qui y travaille vous pouvez faire circuler l'information.

A quoi va bien pouvoir me servir une telle bibliothèque ?
Les threads c'est difficile de faire quelque chose de générique cela colle trop à l'OS et c'est pas forcément toujours adaptable au projet que l'on veut faire.
Il existe déjà pthread et si je développe un projet et que je veux faire du multiprocessus je prends des fonctionnalités toutes bêtes comme _beginthread sous Windows
C'était juste une remarque en passant...
Tu vas être en concurrence avec un très gros comme Intel qui développe ses propres bibliothèques comme VTune par exemple.

Pour exploiter la pleine puissance des quad-core au besoin il faut faire des optimisations en assembleur donc avoir un niveau très pointu dans ce domaine ce que des gens rares comme chez Intel possèdent

[Lsong]

Bon le post ne devait pas etre super clair

la Lib n'est pas une réecriture des threads, ca ne sert à rien de réinventer la roue. Il s'agit d'algorithmes qui permettent de faire de la programmation parallèle par découpage de données, les threads sont à faire par l'utilisateur de la lib (en assembleur s'il le desir, mais bon j'ai des doutes que ça soit franchement mieux), en fonction de l'OS qu'il cible.
Le but n'étant absolument pas de faire de la concurrence à Intel sur l'implémentation des threads.

L'exemple qui a été developpé tourne avec des threads SDL, mais avec une synchronisation windows .

La Lib se concentre sur les Datas et leurs interactions pour gérer les problèmes de calculs parallèles, c'est assez complexe, mais faire de l'innovation en informatique c'est forcement non trivial les algos simples étant déjà tous traités.

[Fraggy]

Bonjour,
je me présente rapidement, je travaille avec Laurent sur la bibliothèque de calculs distribués. Mon rôle se situe principalement au niveau de l'architecture logicielle (refactoring, analyse, conception) ainsi qu'au niveau de la recherche de partenaires et de clients.

Nous avons bien des idées de scénarios mais le but à court terme n'est pas de monter une équipe amateur pour faire un petit jeu vidéo même si ça reste une option s'il y a des personnes très motivées.

Le projet de jeu vidéo est au point mort actuellement : on attend d'abord d'avoir le moteur de physique pour se lancer dans le développement d'une démo de jeu.
Le concept du jeu dépend fortement du moteur, vu les caractéristiques de notre jeu "multimode, réseau/MMO"

Multimode
Dans la même partie on doit pouvoir se connecter avec 3 types de jeux vidéo différents (FPS, Stratégie temp réel et Hack and Slash), en fonction de ce qu'on aime.

Réseau
Le jeu doit pourvoir fonctionner en réseau local et via internet (le fonctionnement des mondes virtuels doit être parfaitement déterministe, pour éviter les problèmes de cohérences). Le monde virtuel doit être distribué (en local seulement) entre les joueurs connectés, de façon à utiliser au maximum la puissance disponible. le monde virtuel doit être suffisamment robuste pour permettre de supporter une déconnexion involontaire d'un ou plusieurs joueurs.

MMO
Cette partie là c'est dans un second temp :p Si on arrive a faire le mode réseau classique et le multimode on y pensera. En résumé, le but est de faire un monde unique mono instance accessible de partout sur internet, tous les joueurs peuvent virtuellement se retrouver au même endroit. Ce mode implique des problèmes relativement complexe (et c'est peu dire) :
- distribution d'un monde unique (une seule instance) sur des clusters de serveurs partout dans le monde (rien que ça, ça l'air impossible)
- problème de monté en charge des serveurs au niveau de la bande passante mais aussi au niveau de la charge de calculs
- interface publique de connexion au monde virtuel en ligne (on souhaite publier une bibliothèque pour interfacer n'importe quel client 3D à notre jeu en ligne)


Nous avons bien conscience de l'importance et de la difficulté de ce projet, mais nous nous donnons les moyens d'y arriver :
- Ca fait bientôt 4 ans qu'on bosse sur une architecture logicielle qui pourra distribuer un monde virtuel sur un cluster de machine (et faire des synchronisation en temps réel via Internet) la bibliothèque 4DGE permet déjà de distribuer les calculs sur des coeurs et Le POC de La distribution sur des machines en réseau à été fait l'année dernière en Java (on est plus très loin de ce qu'on veut)
- le moteur de jeu vidéo sera développé par un partenaire, on apporte une bibliothèque spécialisée dans le calcul distribué ainsi que notre expérience dans le domaine du calcul parallèle pour que notre partenaire réalise un moteur de jeu vidéo multithread.
- dans la version MMO, les clients 3D seront également développés par des partenaires à partir d'un moteur de jeu vidéo basé sur 4DGE.

Si vous avez un projet de jeu vidéo en cours suffisamment proche ou si ce projet vous intéresse, on a aussi un début de scénario, envoyez moi un MP. On est tout a fait prêt à fournir une version alpha de notre moteur de jeu vidéo pour qu'une équipe motivée fasse une démo.
Merci de ne poster ici que des sujets qui concerne 4DGE, si ça concerne le projet de jeu vidéo envoyé moi un MP.

Fraggy

[Fraggy]

Discutons de l'intérêt des processeurs asymétriques pour le jeu vidéo.

http://www.matbe.com/actualites/1510...rre-des-cores/

Au-delà des nombres, ce sont des paris très différents qu’envisagent les deux constructeurs. Intel mise sur des cores relativement simples, épurés et qui font leur force dans le traitement en parallèle des données. Le tout nécessitant de trouver un moyen de paralléliser un peu plus efficacement qu’actuellement le code des programmes [...]. AMD en gardant des cores plus gros et plus traditionnels prend une route plus conservatrice.

Un processeur asymétrique est pensé pour la programmation fonctionnelle, le Cell d'IBM en est le plus récent exemple (http://fr.wikipedia.org/wiki/Cell_(processeur)). Si AMD produit des processeurs de ce type, les jeux vidéo fonctionnant sur un modèle de parallélisation fonctionnels pourront profiter de ce supplément de puissance. Les processeurs asymétriques semble donc bienvenu à court terme.

Mais à plus long terme ? Quand Intel proposera un processeur 32 coeurs symetrique que pourra faire AMD ?
Si un processeur AMD comportant 8 coeurs généralistes et 24 coeurs fonctionnel arrive sur le marché, on se retrouve avec les mêmes problèmes de découpage basé sur les données et de synchronisation !

De plus, avec notre architecture logicielle, un processeur multicoeur symétrique de 32 coeurs sera forcément plus performant qu'un processeur asymétrique 8/24 coeurs (ne serait ce pour ce qui concerne la puissance brute.)

Notez que notre architecture est normalement prévue pour fonctionner sur des processeurs symétriques, mais il est probablement qu'on puisse l'adapter pour des architectures asymétriques comportant plusieurs coeurs généralistes (donc pas le CELL, sauf sur des architectures multiprocesseurs)

En résumé, les processeurs asymétriques apporteront probablement un gain significatif aux jeux développés avec un modèle de calcul parallèle fonctionnel. Mais à plus long terme il faudra utiliser un modèle de calcul basé sur les données quelque soit le type de processeur.

Fraggy, je vote symétrique parce que ça me fait moins de boulot...

[granquet]

ça fait un petit moment que je m'interresse a la parallélisation des moteurs (3D et physiques) avec un decoupage par data.

j'ai jamais pris le temps de me pencher serieusement sur la question, mais le peu de temps que j'ai passé dessus m'as fait entrevoir quelques difficultés ...
je suis vraiment impatient d'en apprendre plus sur vos algos (seulement en tant qu'etudiant lambda assez curieux par nature).

quelle license prevoyez vous?

[Matthieu Brucher]

Le CELL peut tout de même prendre en charge 2 threads.
Le pb est plutôt dans la faiblesse architecturale derrière, même chose pour le Xénon, à savoir pas ou presque de prédictiond e branchement, ...

Pour le jeu vidéo, si déjà on utilisait OpenMP dans les parties parallélisables, ça serait rapide et efficace.

[Fraggy]

Le CELL peut tout de même prendre en charge 2 threads.
Le pb est plutôt dans la faiblesse architecturale derrière, même chose pour le Xénon, à savoir pas ou presque de prédictiond e branchement, ...

Le cell peut prendre en charge idéalement 1 gros thread et 8 petit. j'ai pas encore vraiment réfléchis à la chose mais à priori ca doit pas être impossible de faire qq chose avec notre modèle. Faut savoir qu'à court terme on a décidé de ne pas développer pour lui, on ne vise que les processeurs symetriques.

Pour le jeu vidéo, si déjà on utilisait OpenMP dans les parties parallélisables, ça serait rapide et efficace.

Vrais.
OpenMP est une bibliothèque à base de thread léger qui permet de paralléliser facilement les parties naturellement parallélisable. (http://en.wikipedia.org/wiki/OpenMP)
Notre modèle est complétement compatible avec OpenMP.

Quelques remarques sur OpenMP :
- utiliser en parallèle avec un modèle fonctionnel, OpenMP permet un gain de performance important. Les moteurs de jeux vidéo récents sont tous sur le modèle fonctionnel+OpenMp ou équivalent (voir coarse threading and fine grained threading du moteur de valve -> http://techreport.com/etc/2006q4/sou...e/index.x?pg=1)
- utilisé seul, OpenMP ne permettra pas des gains aussi important qu'avec notre modèle de calcul car dans un jeu vidéo il n'y a pas tellement d'algorithmes vraiment parallélisable
- l'utilisation d'OpenMP revient à revoir entièrement le code source de l'application et a rechercher tous ce qui est parallélisable. C'est trés long et cela peu provoquer des bugs difficiles à détecter. Notre architecture permet de réutiliser le code existant avec moins de problème.

Fraggy, OpenMP c'est bien mais pas suffisant

[Matthieu Brucher]

Le processeur principal peut en prendre 2, il est équivalent à l'un des procs du Xénon qui peut lui aussi prendre 2 threads. Ensuite, gros, ce n'est pas gros, c'est tout de même des threads relativement simples avec peu de sauts.

Sinon, d'accord avec toi, pour moi OpenMP doit être un début, une parallélisation à faible échelle alors que les gros traitements doivent être mis en // (son, 3D, AI, ...)

[Fraggy]

quelle license prevoyez vous ?

Ca dépend :
- Notre bibliothèque peut se résumer à 15/20 classes abstraite, une simple lib statique C++. Vu le temps qu'on a passer sur le sujet, le source restera privé et l'utilisation de ce produit sera régie par une licence commerciale classique (on peut s'arranger si le but est de développer un produit gratuit).
- Les démonstrateurs et autres testeurs automatiques seront libre de droits
- La licence du moteur de jeu vidéo co-developpé avec un studio de dev partenaire sera probablement commercial (en fonction du studio)
- La licence du moteur de physique basé sur ODE (on va le développer nous même dès qu'on trouve un développeur qui connait TRES BIEN ce moteur) sera probablement en LGPL (si on peut garder le code source de notre bibliothèque en privé avec cette licence)

Fraggy

[Fraggy]

Le processeur principal peut en prendre 2, il est équivalent à l'un des procs du Xénon qui peut lui aussi prendre 2 threads.

désolé j'avais oublié que le core principal permet de gerer 2 threads, c'est un peu l'équivalent d'hyperthreading d'intel, effectivement
Mais même, on ne fera pas de dev spécifique pour ce processeur, na Mais bon si une console de JV sort avec 4 Cell en parallèle ca change tout...

Sinon, d'accord avec toi, pour moi OpenMP doit être un début, une parallélisation à faible échelle alors que les gros traitements doivent être mis en // (son, 3D, AI, ...)

Tu décris un modèle fonctionnel de parallélisation, celui que tous le monde utilise actuellement. Il fonctionnera sans problème pour les architectures comportant jusqu'a 4 cores. Mais il faut savoir qu'au dela de 4, ce modèle se heurte à des problèmes qui sappent entièrement le gain en performance.

Avec notre projet on souhaite proposer une architecture logicielle utilisable sur des architectures comportant bien plus de 4 coeurs. Notre modèle de calcul parallèle est basé sur un découpage symétrique des données du monde virtuel, pas un découpage fonctionnel

Fraggy

[bafman]

et qu'est ce que votre architecture apporte de plus par rapport a un moteur physique comme bullet qui gere déjà le multithreading au niveau donnée ?

[Fraggy]

pour plus d'info concernant bullet voir ici -> http://www.continuousphysics.com/Bullet/

et qu'est ce que votre architecture apporte de plus par rapport a un moteur physique comme bullet qui gère déjà le multithreading au niveau donnée ?

Note que tous les moteurs de physique commerciaux sont ou seront multithread à trés court terme. Bullet n'est pas le seul moteur multithread

Bullet parallélise tout ce qui est naturellement parallélisable dans un moteur de physique, notre architecture parallélise le reste. Ce que notre bibliothèque apporte en plus à bullet :
- un gain de performance supplémentaire du à une plus grande parallélisation de la physique
- un gain de performance supplémentaire du à la possibilité d'appliquer le calcul parallèle aux autres sous système du jeu vidéo (on distribue aussi le rendu 3D, l'IA, les animations, le son etc...)

En fait Bullet n'est pas un concurrent, on peut même considérer que c'est un "client" potentiel. Si un développeur peut intègrer notre bibliothèque, ce moteur de physique sera encore plus performant et compatible avec les processeurs 8/16 ou 32 coeurs.

Si quelqu'un connait BIEN bullet, y a peut etre un moyen de faire une version du moteur plus efficace grace à notre bibliothèque.

Fraggy, Si vous connaissez bien ODE ou Bullet, dites le !

[Fraggy]

Bonjour à tous,

Nous recherchons un programmeur C/C++ expérimenté dans le développement de moteur de physique. L'objectif du projet 4DGE est d'introduire un modèle de calcul parallèle basé sur les données (Data parallel model) dans un moteur de physique existant. (http://www.gamasutra.com/features/20...konen_03.shtml)
Le choix du moteur est libre mais son code source doit etre accessible et il doit disposer d'une licence suffisament libre (LGPL, Zlib) pour pouvoir y introduire une bibliothèque en code source fermé. Pour le moment je ne vois que Bullet et ODE.

L'objectif de ce projet n'est pas de refaire un moteur de physique de A à Z. Il s'agit de :
- réutiliser le code source d'un moteur de physique existant
- conserver l'interface publique du moteur de façon à garder la compatibilité avec la version d'origine.
- écrire un testeur de montée en charge qui démontrera l'intérêt de notre bibliothèque pour les architectures comportant 8 cores et plus.

Le profil idéal du programmeur recherché :
- bonne connaissance du C, du C++, d'ODE (ou de Bullet)
- ayant participé au développement d'un moteur de physique
- capable d'étendre ses (ou disposant de) connaissances dans d'autres domaines (IA et rendu 3D principalement)

Si vous êtes intéressés par ce poste, merci de me contacter en MP. Si vous avez des précisions à demander merci de le faire ici (ça profitera à tous le monde)

Fraggy

[Fraggy]

j'ai ouvert un autre forum sur le sujet.
quelqu'un peut il stoper celui la il est un peu vieux ?

Vincent