Discussion :

[Sébastien P]

Salut à tous !

Je me met à l'arrêt pendant un petit moment su mon projet de moteur pour me poser une question qui me trotte dans la tête....

Lorsque on a un moteur 3D on a souvent et vous ne me contredirez pas de grands voir très grands tableau de données ... Que ce soit sommets, coordonnées de texture, textures elles mêmes, structure de partitionnement etc ...

étant donné l'évolution courante de la technologie qui tend à multiplier les coeurs, les processeurs et donc le nombre de tâches exécutables en même temps à la "même vitesse" ( entre guillemet évidemment)

Ne serait il pas une bonne chose de découper les tableau pour effectuer les traitement en parallèles (traitement totalement indépendants évidemment )

Je pose la question sur un domaine que je n'ai encore jamais pratiqué mais que je pense adopter rapidement si les réponses à ma question sont positives !!!

Merci d'avance @++
Seb

[bafman]

ca peut effectivement être une bonne idée, mais c'est effectivement une chose très difficile à mettre en oeuvre... ce n'est pas pour rien que les boites de jeux evitent le plus possible de le faire, car obtenir un moteur qui marche de façon sure avec du parallelisme est juste super difficile...

par contre, on peut simplifier le problème pour obtenir un gain interessant sans pour autant tomber dans des situations à risque.
un exemple simple consiste à utiliser un algo de partitionnement de l'univers et à effectuer les calculs en parallele sur chaque section.

[Lsong]

je travaille sur un moteur parallèle, nous sommes passé par le découpage en zone pour faire de la programmation parallèle, la grosse difficulté étant la synchronisation de toutes les activités qui sont à cheval sur les zones.

[Sébastien P]

Ok Merci de vos réponse,

Bon étant complètement novice en la matière évidemment je pose peut-être des questions qui ont déjà été étudiées mais bon je pose quand même ...

Mais je pensais par exemple à des choses de la sorte :

Dans une passe de rendu, on a par exemple :

Transformation des sommets => Illuminations => Rendu effectif via API

On pourrais donc par exemple encapsuler chacune de ces phase dans un thread et faire suivre les données d'étapes en étape ainsi on se retrouve avec un programme principal qui a un point de vue sur Transformation des sommets et un sur Rendu

Il donne son premier modèle à transformation qui des qu'elle a terminé le fait suivre à Illumination et attaque dessuite la transformation suivante

Des que le programme de rendu principal à donné à manger son dernier modèle il n'as plus qu'à attendre la fin de Rendu effectif et a faire un swap des buffers

il faut surement j'imagine rajouter des "Ponts file d'attente entre les différents
threads" et le gain n'est peut-être finalement pas monstrueux mais je me dis que ca peut tout de même être une bonne idée .....

Voila qu'en pensez vous ?

Sachant que par exemple en plus ensuite on pourrais imaginer dupliquer ces "Pipes " du style

P1 => TS => Illu => Rendu via API
P2 => TS => Illu => Rendu via API

et donner la moitié à une et à l'autre ... cela risque par contre de poser des problèmes ... 1 d'ordre d'affichage ... et sur les api de rendu qui ne supporteraient peut-être pas deux appels simultané sur le même contexte ??


voila voila j'attends vos avis avec impatience

ps : Désolé si j'ai utilisé des termes inappropriés ou qui existe sous d'autres formes

[Lsong]

Je ne connais pas trop le fonctionnement de l'affichage graphique, je sais juste afficher une mesh/vertex sous DX9 ... ca ne va pas loin, je travail plus sur la physique.

Je sais juste que DX effectivement ne suporte pas de faire deux draw sur le même context en même temps.
Ce que tu proposes est de faire un pipeline, ca marche si chaque blocs de données sont independante, je pense que c'est le cas.

Cela dit quand j'ai regardé DX
set la transphormation en envoyant la matrice
set les lumières avec une structure, materiaux effet etc... et apres
je fais le draw ...
le probleme c'est que le travail à faire est ridiculement faible et passe par l'API. Mais il doit être fait pour chaque objets ce qui peu être long.

Chaque étape est faible en temps de traitement il y a de fort risque que le gain soit tres faible, nule ou pire, dut au besoin de synchro. Un thread quand il s'arrete pour cause de famine, ou autre peut rester en pause 1-2-5-16 ms impossible de savoir et ca risque de bloquer l'emsemble ou de se retrouver avec des performances pire. Faire un pool, pour éviter la famine, à l'inconvéniant de devoir la synchroniser et si tu veux des performances les synchronisations doivent être limitées au maximum.

L'autre solution est de faire des pipelines séparés comme tu le proposes, mais là, l'API risque de ne pas aimer les appels en même temps, j'ai un ami qui a esseyé ca lui à fait un beau écran bleu ...

[Laurent Gomila]

Transformation et illumination c'est fait par le GPU, à partir du moment où tu envoies tes sommets tu n'as plus la main ; donc pas facile de paralléliser. D'autant plus que le GPU le fait très bien (selon la tâche il peut avoir plusieurs unités qui bossent en parallèle).

Ce qu'il serait plus intéressant de parallèliser ce sont les traitements sur la scène (tri des objets, culling, ...). Je pense que là ça devient assez dépendant de la structure de partitionnement utilisée.

[bafman]

tout comme Laurent
il faut savoir que :

1. les drivers actuels gerent relativement bien le parallelisme sur les multicore
2. une fois les info envoyé à la carte graphique, c'est elle qui prend en charge les traitement, et elle est elle même TRES fortement parallele

donc il ne sert à rien d'essayer de paralleliser les traitement graphiques, mais plutot tout ce qui est algo en amont.

[Lsong]

Le trie c'est assez dur à paralléliser car les données sont plutot ... dépendantes les une des autres , il faut que le gain que l'on en retire soit tres important pour que le temps de le faire soit ratrapé.

Le culling je ne sais pas, je ne connais pas beaucoup les algorithmes qui en font, dans mes souvenirs c'est un peu lourd.

Cela dit la Lib sur la quelle je travail permet ce genre de parallélisation
ca fait partie des choses que le projet 4DGE peu prendre en charge

[Sébastien P]

Merci pour toutes ces réponses mais effectivement j'ai mal pris mes exemples effectivement les transformations de sommets sont prise en charge par les Api
mais par contre pour l'éclairage vous m'en direz tant ? :o Si l'éclairage est pris en compte pourquoi y a-t-il tant de tutos sur l'éclairage par vertex et par lightmap etc ... avec des algos assez jolis en nombre de boucles for .... Calcul des normales calcul des coordonnees de textures etc....

En fait c'est surtout vis à vis de cet étape du développement que je me suis posé la question de savoir si il était possible de procéder à un découpage de la sorte quand à paralléliser les tris effectivement je ne suis même pas encore suffisamment calé dans ces systèmes pour penser les paralléliser !!!