Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pour
Contre
Discussion :
Un processeur n'est pas plus data-parallel qu'un autre, c'est l'algorithme qui sera data-parallel ou task-parallel ou rien du tout. Et la majorité des algorithmes, c'est task-parallel ou rien du tout.
Ce n'est pas pour le grand public tout de suite, c'est pour certaines applications (comme le raytracing que tu connais bienEnvoyé par LeGreg
)
est ce vraiment une question de data parallelisme ? ce n'est pas plutot une question de localité (c'est a dire, faire deux choses simultanément sans qu'elles interfèrent ?) il me emble que le data-aprallelisme est uniquement sur un algorithme ou une partie de code, alors qu'un logiciel a une architecture bien plus large que cela.
Le GPU n'effectue pour ainsi dire qu'une tache, les cartes dediees sont donc adaptées a un pipeline graphique a plusieurs etapes et du data parallelisme, cependant il n'est pas necessaire de diviser un logiciel ni en "taches" ni en "data" parallelisme, tu peux faire un peu d'IA et un peu de physique ant qu'elles n'entrent pas en conflit. Et ces taches ne sont pas "data paralleles", elles sont independantes. On peut augmenter l'independance en utilisant des copies privées sur lesquelles chaque "worker" peut travailler sans voir son resultat detruit par un autre trhead, et ainsi de suite.
Le seul parallélisme qui fonctionnera bien sur les prochains processeurs, c'est le parallélisme des données. Et ça implique aussi une certaine localité, naturellement, sinon ce n'est pas du paralélisme de données.
En général, seule une partie du code a cette propriété. Le principe est de l'agrandir au maximum, mais comme c'est un sous-ensemble très restreint des algorithmes existants, c'est difficile à mettre en oeuvre.
L'avantage du parallélisme de données n'est pas vraiment de traiter plus vite les mêmes données avec un processeur plus rapide (justement parce qu'ona une partie non parallélisable, et donc on atteint rapidement les limites de la parallélisation), mais de traiter plus de donénes dan sle même temps. Par exemple, on fait sauter la limitation du nombre d'unités dans un jeu.
Ce que tu décris, c'est le parallélisme de tâches. Certaines tâches sont data-parallel, mais ce n'est pas la panacée, et on sera limité par celles qui ne le sont pas.
Je ne suis pas d'accord, je trouve que tu regardes avec une trop grosse granularité (c'est a dire que tu ne divises pas tes taches en taches plus petites)
c'est dur de faire du parallelisme avec le C++ car il n'a pas été prévu pour au debut, mais tu divises quand meme ton logiciel en 4 et je pense que tu peux faire mieux. en articulier, tu parles de taches qui sont toutes continues (la physique, l'IA, etc)
Moi je te parle de taches ponctuelles, comme "lancer un missile", "avancer de deux pas", que tu englobes allegrement dans "IA" (ou dans "Gameplay").
En gros je pense que tu parles de theorie mais que tu es trop loin de la pratique. Les micro-taches ci-dessus ne sont pas data ou task ou quoi que ce soit, elles sont indépendantes, ou locales, ne necessittent pas d'etre ordonnancées. Toi tu parles plutot de la resolution generique de programmes, ce qui me parait tres eloigné de la réalité mais bon pour un article de wikipedia.
Certes personne n'a dit que ce serait facile. C'est pour ça qu'il y a une forte valeur ajoutée à la fois dans le hardware et les outils, alors que l'importance du CPU (modèle single threaded ou faiblement threadé) décline.
Par ailleurs, je n'oppose pas Data parallelism et task parallelism. Je dis qu'on doit exploiter les deux (ce que les GPUs actuels font pour le domaine du graphisme mais feront demain dans beaucoup d'autres domaines). Le danger c'est le code "serial". Mais on y travaille.
Larrabee n'est pas fait que pour le ray tracing. Le ray tracing est possible sur le GPGPU du futur mais n'est qu'une petite application parmi tant d'autres. L'IA, la physique, les calculs de visibilité, la detection des collisions, la compression/décompression de textures, tout ça va bénéficier aux jeux (on parle toujours de jeux, hein ?).Ce n'est pas pour le grand public tout de suite, c'est pour certaines applications (comme le raytracing que tu connais bien
Je cite une étude d'Intel :
"D3D Runtime and Driver account for 25-40% of CPU cycles per frame" et c'est sans compter les cycles CPU "administratifs" que l'application doit dépenser de son coté pour garder le GPU busy. La tâche "affichage" est celle qui est coûte le plus sur un jeu moderne.
-> avec une nouvelle API, et un GPU qui est capable de générer ses propres tâches, tu réduis ce coût d'un ordre de magnitude. Et du coup l'importance du CPU faiblement threadé et du code serial décline.
Cela va arriver :
2009/2010 : Direct3D11 introduit le data parallelism dans son API (programmation multithread).
2012 (?) : Direct3D12, le GPU est suffisamment flexible pour être programmable en langage proche du C++ (ou une variante d'un langage fonctionnel pour les amateurs) et pouvoir générer ses propres tâches (rester occupé sans s'appuyer sur des cycles du processeur serial).
Je cite Tim Sweeney (Epic games et Unreal engine) en 2005 :
"2009 Next console generation. Unification of the
CPU, GPU. Massive multi-core, data parallelism, etc"
"By 2009, game developers will face…
- CPU’s with:
– 20+ cores
– 80+ hardware threads
– >1 TFLOP of computing power
- GPU’s with general computing capabilities.
- Game developers will be at the forefront."
Pour être safe, remplace 2009 par 2012 (En 2005 il était encore optimiste Tim Sweeney).
LeGreg
Mon site web | Mon blog | Mes photos | Groupe USA
> BONJOUR, JE SUIS NOUVEAU SUR CE FORUM
> presse la touche caps lock, stp
> OH.. MERCI C EST BEAUCOUP PLUS FACILE COMME CA
J'ai dit que certaines tâches pouvaient être parallélisées, mais je suis désolé, toutes ne peuvent pas l'être. Donc quand tu fais du task-parallel dans un workflow ou un pipeline, tu seras ralenti par le plus lent.
On ne peut pas toujours faire mieux. Il y a des applications qui sont purement monocore et où le gain parallèle sera infinitésimal. Un exemple simple, un filtrage AR d'ordre 1, qui peut être paraléllisé, mais le gain, c'est le calcul du filtre divisé par le calcul du filtre + l'accès mémoire. Bref, c'est quasiment négligeable.
Je pense être bien plus proche de certaines pratiques que toi. J'ai dit aussi qu'on pouvait paralléliser certaines tâches, comme la gestion de plusieurs entités, mais il y a une limite. Tous les algorithmes ne sont pas parallélisables, il faudra bien que vous vous en rendiez compte.
Le problème, c'est qu'il ya plusieurs démonstrations mathématiques sur les problèmes algorithmiques expliquant clairement que tout n'était pas scalable, mais bon, si tu penses savoir mieux que les spécialistes du parallélisme (et je ne m'inclue pas dedans, j'apprends encore beaucoup).
On parle de la partie massivement parallèle, et là je n'ai jamais dit le contraire de ce que tu dis. Mais comme le marketing fait bien les choses, on a l'impression que le massivement parallèle est la solution à tout (ça me fait doucement rire, mais il y a quelques années, le principal problème des applications //, et c'est toujours encore le cas, c'est la congestion des flux de communication. Et ça n'a toujours pas encore été résolu).
Exemple avec la PS3. Avec Folding@Home, elle explose en terme de Tflops la contribution des PCs. C'est bien, mais si on regarde mieux les chiffres, dans les applications non massivement parallèlisables, elle reste très loin du PC. Quand dans une application, on a souvent des branchement et des prises de décision, elle s'écroule face à un processeur mono-thread actuel.
Donc pour bien faire, il faudrait différencier les tâches pouvant être parallélisées de celles qui ne le peuvent pas (ou plutôt que l'intérêt n'y est pas).
Si je suis ton raisonnement, une IA c'est de la pise de décision donc pas d'intérêt à être multi-threadé ? Ou devrait-elle avoir son propre thread ?
Je dois avouer que je m'y perd un peu...
En tout cas, c'est un débat très intéressant.
Un jeu n'est pas qu'un algorithme, c'est beaucoup. si certains sont divisibles en taches car "data parallels" tant mieux pour eux. si d'autres ne le sont pas, il reste la possibilité de faire tourner les bouts de codes independants en parallele, sans que ca soit le MEME bout de code. Tu est calé sur une boucle for, mais dans un jeu, y'en a pas qu'une de boucle for......
Dernière modification par raptor70 ; 10/09/2008 à 23h05. Motif: mise en forme
Est-ce que j'ai dit qu'il n'y avait qu'une boucle for ?
Je n'ai pas dit qu'un jeu n'était qu'un algorithme. Il y a plusieurs entités qui tournent ensemble et communiquent ensemble. Ce nombre sera quasiment fixe dans les années à venir. Ces tâches diverses peuvent elles-même être séparées en d'autres tâches (des bouts de code différents). Certaines pourront scaler, pas d'autres. Mais il y a une limite à ce parallélisme qui est inhérent à la phrase que tu as dite, à savoir "sans que ce soit le MEME bout de code". Ces différents bouts sont en nombre finis, donc il y a un nombre fini qui sera rapidement atteint de tâches différentes (et toutes ne peuvent pas être exécutées en même temps).
Par exemple dans un RTS, la sous-tâche de gestion de chaque entité sur le terrain pourra scaler dans une certaine limite. En revanche, la gestion du graphisme sera, avec l'architecture actuelle, bien plus difficile à scaler. Et même dans l'IA, il y a la gestion du path-finding qui aura elle aussi du mal à scaler car pour déplacer une unité, il faut tenir compte des autres unités, donc même là, il faudra faire attention.
Personnellement je me demande pourquoi c'est pas le compilo qui gère cela. En théorie rien qu'en parcourant le code il devrait être capable de dire quelles tâches et groupes de tâches peuvent être exécutés parallèlement ou non (ou du moins en déduire une bonne partie), est-ce qu'il existe déjà des approches de ce type ?
Vive les roues en pierre
Il existe des approches de ce types, mais on sait que ça ne fonctionne pas. Ca devait être la nouvelle révolution de la programmation, mais c'est impossible de le faire.
Impossible ou plutôt impossible à l'état actuel des nos connaissances ?
En tout cas cette discussion me donne l'eau à la bouche d'essayer d'établir un moteur qui serait capable de découpler ces tâches pour améliorer le gameplay.
Quelqu'un pour se joindre à moi ?
Impossible, à mon avis. Déjà un code multi-thread tournant sur un seul processeur passé sur un multi-processeur donne des résultats incertains (la preuve que déjà pour les humains, il est difficile de voir ce qui se passe), donc automatiser cette tâche, sans avoir la certitude que ce qui doit se passer se passe effectivement, c'est impossible (IMHO).
En effet, je vois que tout cela révèle pas mal de problème... Cela demande réflexion !
Commençons par aborder les problèmes qui pourront être engendrés, cela permettra d'y voir plus clair et de savoir quelle solution y apportée (si une solution est possible bien sûr).
Avis donc aux amateurs.
Pour apporter ma maigre contribution à cette discussion qui est vraiment passionnante (et en même temps vachement intimidante, ces histoires de cores de plus en plus nombreux, bientôt de Larabee, puis de fusion totale entre CPU-GPU, et tout ça en quelques années, ça va vraiment remettre en cause et rendre obsolète beaucoup de choses notamment dans le domaine du jeu vidéo).
En tout cas, j'avais trouvé un lien il y a quelques temps qui discute de la répartition des tâches pour les processeurs multithread et qui serait relativement scalable par rapport au nombre de cores : http://www.pablo-zurita.com.ar/spani...ra-motores-3d/ (EDIT : désolé, je croyais qu'il était en anglais, désolé pour les non-hispanophones)
Est-ce parce qu'elle est si coûteuse qu'elle est la plus coûteuse, ou bien est-ce qu'elle a pour objectif de l'être ? Je m'explique (du moins, je tente
J'ai un peu l'impression qu'aujourd'hui, pour la plupart des jeux, la condition de vente première est d'avoir un graphisme qui tourne bien et soit joli. Et qu'on n'arrive pas à aller assez loin dans ce sens avec le matériel d'aujourd'hui.
Conclusion, on attribue 95% des ressources (ressources hardware, mais aussi ressources de développement) au graphisme, et les miettes qui restent au reste. Peut-être qu'on arrivera un jour à avoir du graphisme suffisant, en qu'on pourra se concentrer sur le reste.
Ce qui fait que même si on n'arrive pas à paralléliser le graphisme (mais je ne vois pas de raisons de ne pas y arriver, après tout, ça fait plus de 10 ans que je vois des architecture graphiques parallélisées hors grand public), l'arrivée de multi-cœurs aura quand même pour effet de permettre d'avoir des jeux non pas plus rapides, mais plus riches.
Ça me désole un peu de voir que je n'ai pas plus de challenge intellectuel dans un RTS moderne que dans un warcraft.
Pour Matthieu Brucher : Sur les aspects est-ce qu'un processeur data-parallel peut améliorer les choses, je suis d'accord que ce qui compte avant tout, c'est l'algorithme, mais comme une partie de l'algorithme est directement écrite dans des processeurs spécialisés, de nouveaux processeurs peuvent avoir un impact, non ?
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Si un coeur en lui-même est amélioré, oui. Malheureusement, on se tourne plus vers la multiplication des coeurs que vers l'amélioration d'un seul.
Mais comme dit, un processeur n'est pas task- ou data-parallel, l'implémentation d'un algorithme oui
Sinon, complètement d'accord avec ton analyse sur le graphisme dans les jeuxCa va être un peu plus fun d'avoir de vrais adversaires.
En fait, l'IA .. ou plus particulièrement, le pathfinding, est souvent utilisé comme exemple de système "paralellisable" car il en possède toutes les caractérisques.
Il possède généralement une structure propre à lui (un graphe, une grille ou autre) qui n'est utilisé que par lui donc pas de risque interférance extérieur.
De plus, les algorithmes peuvent être lourds et long donc pouvoir faire quelquechose en même temps est interressant.
Enfin, il a très peu d'entrée et de sortie. On lui donne un départ et une arrivée et il nous donne un chemin.
Donc en étant completement indépendant, il est très facile de lui posé un question et d'attendre la réponse (même quelques frames plus tard)..
Mes Tutos DirectX, OpenGL, 3D : http://raptor.developpez.com/
Exact, on peut le mettre dans un thread à côté. En revanche, il est plus difficile de calculer deux chemins pour deux entités en même temps, car elles peuvent vouloir passer au même endroit alors qu'une seule peut passer. Et ce genre de goulot d'étranglement pour l'algorithme est fatal à la scalabilité.
Est-ce si gênant ? Quand je planifie un déplacement, je ne sais pas si d'autres voitures vont vouloir aller comme moi, mais je m'adapte au fur et à mesure. Quitte en cas de bouchon à prendre un itinéraire bis (qui souvent me rallonge encore plus).
La planification stratégique doit certainement en tenir compte, mais le pathfinding ?
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager