Que peut apporter le multithread au développement de jeux ?

[HanLee]

[HS]
Quand même dans le contexte économique actuel, les économies d'énergies tout ça, ça commence à me dégoûter de voir ces cartes graphiques afficher des consommations affolantes comme ça.
[/HS]

[ac_wingless]

Dans mon expérience, qui n'est pas le domaine du jeu, mais qui tourne sur du matériel et a des contraintes de performance assez comparable, nous sommes confrontés à un écueil dont on ne parle pas assez: déplacer les données. Ou comment exploiter des téraflops sur des GB/s... ça ne passe pas! Nous sommes toujours à décider à propos de où mettre telle ou telle donnée, selon son chemin complet entre le GPU, le CPU (et le reste des périphériques, ce qui nous différencie du domaine du jeu).

En gros, si on peut se contenter comme sous DirectX9 de balancer des données sur un GPU et le laisser bosser (mode "fire and forget"), tout va bien, on pourra dans l'avenir faire des centaines++ de TFlop sur 10 GB/s, si bien sur on a l'utilité d'effets graphiques ultra compliqués. Le multi-thread est compréhensible, ses gains estimables, les évolutions sur CPU multi-coeur et sur les GPU annoncés sont faciles à anticiper.

Par contre, dès qu'on veut faire des aller-retour entre le GPU et le CPU, on a une dégelée de paramètres supplémentaires qui peuvent tout chambouler: les bus, leur bande passante, les tailles de cache et les vitesses respectives, la synchronisation, les plages de mémoire spécialisées, etc. Aujourd'hui, une jungle infâme avec des choses non documentées, des drivers qui se permettent de tout casser d'une version mineure à l'autre, bref une horreur qui perturbe gravement toute extrapolation.

C'est pourquoi je pense que la question initiale ne peut pas faire l'économie du contexte: multi-thread dans le CPU et sans interaction avec le GPU? Oui, bien sûr, mais il n'y a pas énormément à gagner (quel jeu est vraiment limité par le CPU?). Multi-thread à l'intérieur du GPU sans interaction avec les CPU (fire-and-forget)? Ben ya pas le choix de toute façon, et bien sur il faut y aller à fond, c'est le point fort du système, par contre là non plus il n'y a pas non plus vraiment beaucoup à gagner, on est vraiment coincé dans un GPU qui peut pas faire grand chose pour l'ensemble de l'appli. Multi-thread avec interactions significatives entre le GPU et le CPU? Là on rentre dans des subtilités qui font que l'aspect multi-thread va souvent être l'esclave des autres contraintes, et ne va pas apporter grand chose par soi-même, mais va peut-être justement se révéler déterminant dans la bonne utilisation combinée.

Si on regarde un peu plus loin, lorsque les différents matériels convergent (Larrabee...), et donc très probablement des outils plus standards, extensibles et simples pour la circulation des données?
Là, je ne vois pas comment éviter une conception extrêmement différente des applications actuelles. La programmation de ces trucs sera probablement très inspirée du mode de raisonnement utilisé actuellement pour essorer à fond les GPUs d'aujourd'hui, sauf que ce sera étendu à une variété de tâches bien plus grande... Bien du travail en perspective, mais c'est passionnant.

Pour qu'on en arrive là, il faudra aussi que les langages utilisés se plient aux critères de productivité récents. Si C++03/0x n'est pas supporté, qui va prendre le risque de faire passer tout un projet en CUDA ou proche? Et comment faire un vrai compilateur capable de tirer parti de Larrabee à partir d'un programme C++0x?

Pour rester avec des choses réalistes, si on suppose qu'il y a bien un projet de compilateur C++0x pour Larrabee basé sur la TBB (ça parait très fortement pas impossible du tout...), alors il vaut mieux se préparer à un gros choc. Les nouveautés annoncées en Juin sont franchement pas simples (affinité avec les threads). Je m'attend à une courbe d'apprentissage rude d'après les premiers tests que nous avons fait.
Par contre, je vois bien des bases très intéressantes se mettre en place chez Intel, on a vraiment l'impression qu'ils ont une vision d'un mouvement d'ensemble vers des architectures bien plus intégrées que maintenant, prenant en compte non seulement des cœurs (très) multiples, mais surtout la glu nécessaire pour qu'ils fonctionnent au mieux ensemble.

[Matthieu Brucher]

Envoyé par ac_wingless

Dans mon expérience, qui n'est pas le domaine du jeu, mais qui tourne sur du matériel et a des contraintes de performance assez comparable, nous sommes confrontés à un écueil dont on ne parle pas assez: déplacer les données.

Toujours le même problème de la communication qui n'a été résolu que récemment.

Envoyé par ac_wingless

Par contre, je vois bien des bases très intéressantes se mettre en place chez Intel, on a vraiment l'impression qu'ils ont une vision d'un mouvement d'ensemble vers des architectures bien plus intégrées que maintenant, prenant en compte non seulement des cœurs (très) multiples, mais surtout la glu nécessaire pour qu'ils fonctionnent au mieux ensemble.

Euh, ils sont à la ramasse au niveau vue d'ensemble plutôt ! AMD a de l'avance grâce au consortium HT qui lui permet d'avoir une meilleur communication entre les processeurs ou les noeuds de calcul. Intel vient à peine de remarquer que c'est critique (et ici, dans un domaine HOC, la seule remarque qui reste, c'est qu'Intel va enfin pouvoir tenter de rattraper son retard face à AMD).

[Polyfructol]

Envoyé par shenron666

Objectif à long terme : disparition du GPU tel qu'on le connait aujourd'hui ...

C'est ce que pense Carmack et Tim Sweeney (Unreal) en accord avec l'auteur de cet article qui prédit le retour du software rendering :

"Software rendering gives game programmers the freedom to implement whatever algorithms suite their needs, and they aren't tied to the DirectX and OpenGL APIs which Tim says is really tying their hands."

Source : Doug Schaefer - Another legend has eyes on the future

[DzzDDzzD]

pour revenir sur le multithread ( ou multi-core ?) et les jeux videos je ne pense pas que cela apporte ou enleve quelque chose, les OS sont maintenant reellement multi-thread, bon ok mais avant on fesait pareil sauf que quand un thread executé une instruction les autres non, en gros fonctionellemnt ca n'a pas changé gand chose, et si tout cela est bien fait j'imagine que dans le futur ca deviendra completement transparent pour le developpeur, charge à l'OS et au compilateur de répartir/synchroniser les instructions au mieux sur les différents core du CPU, c'est à ca qu'ils devraient s'atteler.

et pour ce qui est du retour au software rendering ca me parait une evidence , bcp plus de possibilitées et de créativitée, plus de dépendance vis-a-vis des concepteurs de CG et des fonctions qu'ils choississent d'implémenter, libertée de programmation... ca ouvre enormemment de possibilitées.

vive le software rendering

[copter74]

Envoyé par screetch

vu que les consoles actuelles xbox 360 et ps3 sont multi cores, les projets multi core pour PC arrivent. Le futur est en marche, vous ne le savez seulement pas

Salut les gars...

screetch, you are
Pourrais tu nous dire un peu plus...
Personnellement, je me pose beaucoup de question sur le sujet et je sens que tu as encore bcp a nous dire...
Le DX11 serat-il commercialisé nativement en multitraitement ou ce sera une version genre DX11b non optimisé genre 20% de perf en plus en multicore ?
Le DX11 fera normalement son apparition au début de l'année 2009 tout comme les cartes graphiques compatibles...

Avant c'etait assez simple de faire une estimation au niveau ressource cpu entre chaque genration de GPU....il fallait compter 700Mhz de vitesse supplémentaire a compter du R300.
Aujourd'hui on est en plein virage...les frequences stagne, les coeurs se parallélise et les editeurs sont attentiste marketingment parlant sur la part du gâteau a se faire...c'est a dire l'équipement matériel du parc informatique.

Le feu sera t-il passé au vert niveau marketing en 2011 ? (date d'arrivé des next gen...720, etc...).
Le DX11 pour multicore sera t-il optimisé (cad, gain doublé et proportionnel au nombre de core)
Tu estimes quoi niveau ressource CPU pour faire tourner des jeux Next Gen entre 2011 et 2012 sur un r9xx ?
En repere la 360 a ces début (... janvier 2006) avec son r500 optimisé etait exploité a peine a 20% et arrive aujourd'hui a mi-generation console a maturité et pourtant fait jeu egal avec un C2D d'entré de gamme et un r6xx...

Selon toi, un R9X0 d' ATI ou soyons fou un r1xxx par exemple, qui sortira d'ici 2 ou 3 ans, aura t-il une chance de pouvoir tourner sans etre cpu limited sur une config toute neuve en socket 775 qui est en fin de vie avec un E8500@4.4ghz ? Avec un Q6600@3.6ghz ?
Une alternative a base de coprocesseur sur le meme PCB a coté du GPU prevu par les constructeur si le marché du quad se porte mal, sachant que 99% des utilisateurs de pc qui @ pas leur cpu et que le chiffres des utilisateurs de quad en 2011 ne sera sans doute pas suffisant pour que les éditeurs développe en multi ??

Bref tout est en train de changer mais je me demande pour assemblé une machine qui doit durée 4/5 ans en 775 si ce n'est pas trop tard et trop tot pour du Nehalem...un bon E8500E0@4.2ghz ou un bon Q6600@3.6 ghz min ???

Désolé si je me suis trop étalé sur votre topic en mode HS: actived

[deadalnix]

Moi je me pose une grosse question. Faire tourner une appli sur 4 voir 8 cores, c'est tout a fait faisable.

Le problème étant que répartir les taches entre les threads demande des ressources. Or, cette réârtition ne scale pas du tout, sans quoi deux thread peuvent se retrouver avec la même tache.

Avec une augmentation du nombre de cores comme le propose intel avec le larabee, ne risque-t-on pas de se retrouver dans une situation ou on passe plus de temps a organiser ce que les cores vont faire que de le faire vraiment ?

Quel outils seront proposés au programmeur ? Il me parrait évident qu'une solution doit être apportée au niveau matériel et logiciel conjointement.

A ce propos, comment les GPU gerent ce genre de problèmes (matérielement et logicielement ?). Ceci est en effet masqué par l'API, et le driver, mais je suis sur qu'il y a des choses a apprendre.

[LeGreg]

Envoyé par deadalnix

A ce propos, comment les GPU gerent ce genre de problèmes (matérielement et logicielement ?). Ceci est en effet masqué par l'API, et le driver, mais je suis sur qu'il y a des choses a apprendre.

Le logiciel pilote (qui tourne sur le CPU) est ridiculeusement simple en principe (meme si les lignes de code et la maintenance ne sont pas simples..).

Les commandes envoyées par DirectX et OpenGL, sont traduites en commandes proches directement comprehensibles par le GPU.
SetRenderstate(alphablendfunc, add)
devient un HW_state_alphablendfunc, hw_add
pour caricaturer (mais en fait c'est ça..).
Les commandes HW_ sont décodées en général par une unité spécialisée qui l'envoie ensuite à l'unité concernée.

Le seul parallélisme que doit vraiment "gérer" le pilote à l'heure actuelle c'est le parallélisme CPU/GPU, via un command buffer (une longue FIFO cyclique), une update en ligne ou asynchrone des constant buffers, textures, vertex buffers etc.

Pour le parallélisme à l'intérieur du GPU c'est un artefact de la façon dont sont tracés les triangles.

Un triangle est rasterisé : une opération de setup définit les équations qui vont permettre d'interpoler les attributs une seule fois par triangle, puis ces équations sont envoyés avec les attributs "screen space" (position x0,y0 d'un point fixe du triangle et dx, dy à l'intérieur du triangle) à des unités séparées qui vont chacune à leur tour faire tourner un programme prédéfini appelé pixel shader.

Le gros gros avantage du GPU est que :
- le code du pixel shader est commun pour une array of pixel, donc les instructions ont des chances d'êtres les mêmes à un moment donné ce qui permet de scheduler les tâches en "gros". Si il y a branchement ou appel conditionel de code alors cet avantage est perdu.
- les pixel shaders n'ont jamais besoin de communiquer avec un état "global" synchronisé tout est passé en input local et ils ne communiquent pas entre eux (à certaines exceptions près pour définir des phases pour accéder aux textures de manière cohérentes mais c'est une optimisation). De même les pixels simultanés sont organisés de telle manière que leur output ne se superposent pas (trop) à l'écran ce qui évite d'avoir à synchroniser l'écriture. Ils peuvent aussi être organisés en tiles pour booster l'utilisation de bande passante mémoire.
- Une grosse économie de transistors est réalisé en implémentant des opérations incontournables sous forme de "fixed function" transistors, configurables mais pas programmables, ou moins programmables que le core d'exécution des shaders. Le setup, clipping, blending, texture filtering, compression, etc peuvent être géré en parallèle à l'exécution des cores, de manière rapide et à une fraction du coût (en transistor et en temps d'execution) qui serait nécessaire pour les implémenter de manière "programmable".

Le vertex shader a le même avantage que le pixel shader. C'est juste que les input et les outputs sont organisées différemment (lues depuis un vertex buffer et index buffer et écrites dans une FIFO interne pour le viewport transform/clipping/setup etc.). Là encore les vertex shaders ne partagent pas de donnée et leur place dans la FIFO interne est réservé avant même leur exécution (pas de superposition puisque le VS écrit toujours la même quantité de données).

Le coût typique du GPU n'est pas mesuré en cycles d'exécution mais en nombre de transistors/taille (pour yield)/dissipation de chaleur.

PS: c'est un vaste sujet mais oui un GPU a un gros avantage lié au type de charge (vertex shaders/pixel shaders). Pour Cuda c'est un autre problème.

LeGreg

[screetch]

la repartition des taches peut etre faite par les cores eux-memes, on se retrouve donc avec un probleme plus complexe mais avec plus d'unité pour le résoudre.

Un exemple, si tu as 32 cores, il te faut diviser tes taches en 32 sous-taches (en fait c'est le coté tres optimiste, on va dire 32*8, chaque core effectuant 8 taches). Mais tu n'es pas obligé de faire toi meme ces subdivisions, tu peux le diviser en deux, puis deux cores vont diviser leur tas en deux, puis encore en deux, etc.
on se retrouve avec un probleme traité en O(log(n))
lors du scaling a 64, tu doubles le nombre de core mais tu ne rajoutes concretement qu'une etape.


Au niveau du CPU/GPU je ne suis pas encore assez calé sur le sujet. De ce que je sais, Dx11 ne changera pas grand chose; il diminuera principalement la latence entre le debut de la frame et la fin, ce qui permettra de tourner a la meme vitesse mais avec 0,1 secondes d'avance par rapport a avant. C'est a dire de commencer le rendu plus tot, bien que celui ci prenne toujours autant de temps. mais ca peut varier suivant beaucoup de parametres et principalement le driver vidéo et la carte graphique.

[deadalnix]

En fait ça n'est pas si simple sur GPU :
Tout d'abord les accès mémoires ne sont pas aussi parallèles que le calcul, ce qui implique que le code commence et donc se termine de façon différée sur deux instances d'un même shader.

De plus, il y a au moins un branchement : le Z-test. Si un Z test ne passe pas, qu'est ce que les unités font ? Elle glandent en attendant qu'on leur refourgue un autre pixel a dessiner ? Si elle en prend un autre, lequel ?

screetch > Comment faire cela sans mutex ? ce dernier coupera en effet tout le flot d'exécution, et cela 64 fois sur 64 cores.

[Matthieu Brucher]

Envoyé par deadalnix

screetch > Comment faire cela sans mutex ? ce dernier coupera en effet tout le flot d'exécution, et cela 64 fois sur 64 cores.

Le premier coeur découpe les données en 2, puis récursivement envoie les morceaux vers un nouveau découpage. Très facile à faire sans aucun mutex.

[deadalnix]

Disons qu'un thread A récupère un action a effectuer. Il la scinde en deux et en refille la moitié a un thread B. Il exécute l'autre moitié.

Si j'ai tout bien compris, c'est de cela dont-il s'agit.

Comment le thread A peut fournir sa tache au thread B sans mutex ou mécanisme équivalent ?

[screetch]

je vais t'expliquer mon implementation thread safe sans mutex (mais avec quelques locks par moment) :

les taches sont mises dans une liste simplement chainee circulaire, mettons qu'on est core alors j'insere "fausses" taches dedans. chaque core scanne la liste a partir de sa "fausse" tache.
Lorsqu'on insere des taches, on peut le faire a l'aide d'instructions atomiques (liste simplement chainee); on insere alors des taches dans la queue "appartenant" a un core.

Un core parcours la liste chainee et cherche une tache disponible; lorsqu'il l'a trouvée il la detache (toujours atomiquement par liste chainée). La, il doit y avoir une sorte de reservation de la tache, le temps de voir ce qu'on peut faire avec.

La liste chainée contient toute les taches, mais elle est divisée en zones ou chaque core à la main principale; du coup, il y a peu de chances qu'un autre core vienne la souvent, sauf si il n'a rien a faire.

Dans le cas ou ca arrive, au lieu de voler la tache au core destination, il va la recouper en deux et voler la nouvelle moitié seulement. Il fait ca sauf si le nombre de taches est faible, la il va completement la voler.

Il y a donc un seul "lock" c'est la reservation de la tache, mais en fait je ne crois pas que ce soit un lock. L'un des cores reserve une tache, si la tache est reservée l'autre core passe par dessus je crois. Je ne me souviens plus comment j'ai fait.

Il y a beaucoup de choses que je n'ai pas encore finalisé, j'essayerai de poster un screenshot dans la journée

[screetch]

cliquez sur le lien
cela montre la repartition des taches sur les 4 threads (sur un quad core), chaque couleur represente un travail different, puis ce travail est divisé en 8 taches par core.
Les traits rouges representent le temps ou le core recherche une des taches. On voit que globalement, ca va.
Ce que je vais faire, c'est diminuer les taches (faire moins de calculs) pour faire ressortir la recherche de tache par les cores

[deadalnix]

Lock, mutex, ca sera le même combat et la même conséquence désastreuse sur un nombre important de cores.

Par contre, comment peux-tu faire une insertion/suppression atomique dans une liste chainée ? Il faut au moins trouver la cellule et modifier le lien, ce qui fait deux opérations.