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

[gouessej]

Envoyé par DzzDDzzD

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.

Nous avons besoin des cartes graphiques et d'API portables pour s'en servir. Nous avons besoin de puces avec des fonctions câblées plus rapides que tout ce que vous pourrez faire en réinventant l'eau chaude (je n'appelle pas ça de la créativité même si je suis conscient de la difficulté que cela représente) dans un moteur faisant du rendu logiciel et aussi pour le calcul scientifique. Regardez les performances d'OpenRT, il faut des machines de dingue même pour faire tourner un Quake avec du raytracing.

Cependant, le manque de flexibilité que cela induit pourra être progressivement corrigé sans causer la disparition des cartes graphiques comme ce fut le cas pour les shaders. Il serait utile que nous ayons plus de liberté pour choisir ce qui s'exécute sur le CPU et ce qui s'exécute sur le GPU, ce serait bien de pouvoir déplacer certaines tâches pour équilibrer la charge. Dans ce cas, le CPU et le GPU ne formeront peut-être plus qu'un, cela ne signera pas pour autant l'arrêt de mort d'OpenGL et de Direct3D, les fonctionnalités qu'elles offrent sont très utiles.

[screetch]

pourquoi un lock serait desastreux ?

ce que ca fait a l'heure actuelle c'est un busy wait sur une case lrosque celle ci est modifiée par un autre thread. Or, quand cela arrive-t'il ? lorsqu'un core n'a rien a faire sans sa propre liste. Est-ce courant ? non pas du tout.

Pour les listes chainees, une recherche sur google donnera plus de resultats; mais il est possible de concevoir des listes doublement chainées thread-safe avec seulement des oeprations "interlocked".

[deadalnix]

Un lock va devoir gere les correspondances avec les caches de tous les processeurs sur son état. Celui-ci va fatalement creer une rupture dans le flot d'instructions de tous les cores.

Qui plus est, une instruction atomique n'est pas un garantis de surretée sur un système vraiment multicore.

[screetch]

non, pas de tous les cores, la je ne suis pas d'accord. si le lock est local, le mal est local. Tu pnses verrouiller l'integralité de la liste, moi je l'ai bien séparée en zones appartenant a chaque core pour minimiser l'impact d'un lock.

[screetch]

Envoyé par deadalnix

Qui plus est, une instruction atomique n'est pas un garantis de surretée sur un système vraiment multicore.

wazah ? d'ou ? source ?

[Matthieu Brucher]

Il doit sans doute parler du fait que sur du multiprocesseurs, une donéne peut être présente sur plusieurs processeurs et qu'un instruction atomique sur l'un doit se propager sur l'autre qui peut être en train de faire la même opération. Mais là, on touche aux fondamentaux des locks, car un lock passe par uen instruction atomique à un moment ou un autre, donc ce problème est géré par les processeurs. Normalement.

[screetch]

quand je dis atomique je pense souvent interlocked. J'espere que c'etait clair pour tous, sinon, mea culpa.

[deadalnix]

Exactement, sur un systeme multiprocesseur, l'atomicité de l'instruction ne suffit pas. A un moment, il faut bien qu'il y ai une mémory barrier et une gestion de la cohérence des cache, ce qui aura une influence sur tous les cores, même si le lock est local.

Un GPU doit forcément gere ça autrement, car il arrive a très bien gerer tout ça malgré un nombre d'unité d'éxécution très grand et des taches très courtes (enfin il vaut meiux ).

pour l'instant, je me contente de faire en sorte que les taches soient suffisement importante pour que le temps de réartition de celles-ci soit négligeable devant le temps de la tache, mais sur un nombre important de core, je ne voit pas bien vers ou aller.

Ton système est interessant screetch, mais il a selon moi deux gros problèmes :
Il ne gere pas les taches de longeur très innégales. Or on ne sait souvent pas combien de temps va prendre une tache (je pense a la détéction de collision, qui peut aussi bien s'arêter au premier test qu'amener a une détéction du point d'impact).
On aura toujours un soucis avec une grand nombre de core (le système va montrer ses limtes avec 1024 cores par exemple).

Qui plus est, les langages tels que le C++ réordonnent les instruction, ce qui peut amener le code a devenir non thread safe (il faut du coup regarder ce qui est compilé pour voir si c'est correct, voir retravailler l'asm si ca ne l'est pas . . .).

On fait clairement dans la Mac Gyver a l'heure actuelle, mais ça ne peut pas continuer indéfiniment comme ça . . .

[screetch]

je ne vois qu'un gros probleme dans ce que tu dis, deadalnix, mais tu as dit qu'il y en avait deux ?

[deadalnix]

1/ Les tache de longeur très innégales vont poser problème.
2/ Le fait que cela ne fait que retarder le problème d'un système comme le mien (ce qui est donc mieux, mais loin d'être une vraie solution).

[LeGreg]

Envoyé par deadalnix

Un GPU doit forcément gere ça autrement, car il arrive a très bien gerer tout ça malgré un nombre d'unité d'éxécution très grand et des taches très courtes (enfin il vaut meiux ).

Ben c'est simple, un GPU ne fonctionne pas du tout comme un CPU avec plusieurs cores. C'est ce qu'il faut que tu te mettes dans le crane.

Les threads (dans les shader cores) sont executés en locked step (program counter interdépendant) dès qu'il est possible de le faire et n'ont pas de mémoire ou de données partagées (grâce au modèle de "pixel et shader programs"). Des tampons (buffers) absorbent les temps variables d'exécution aux endroits où il y a besoin de réordonnancement (au cas où deux tâches lancées simultanément finissent l'une après l'autre et ont besoin d'être réordonnancé par exemple pour le test avec le z buffer ou le triangle setup).

Je ne sais pas non plus où tu as été chercher que Z-test implique branchement. En tout cas pas branchement dynamique au sens CPU, au pire un masque d'écriture, au mieux une élagation (pruning) d'une grosse masse de travail ce qui au contraire libère des unités pour d'autres tâches.

Bref, j'ai l'impression que tu vois le GPU comme un gros CPU multi-core. Mais ce n'est pas du tout l'approche usuelle. Certes il y a plein d'autres problèmes inhérents au GPU (goulet d'étranglement sur le setup, maximisation de la bande passante et de la cohérence spatiale, maximisation de l'utilisation des unités de math sur un système balancé automatiquement etc..).

Certes certains (Intel) voudrait faire en sorte que le GPU se programme plus comme un CPU ce qui est un peu un cauchemard en réalité. Mais ce n'est pas la réalité aujourd'hui.

LeGreg

[deadalnix]

Non, je ne vois aps le GPU comme un CPU multicore. Je constate justement que ça ne marcherait pas du tout.

Du coup, je me pose la question de la pertinence d'un nombre important de cores CPU.

Bien sur, il a le fait que chacun des thread part d'un pixel et arrive a un pixel différent (si on prend l'exemple du pixel shader). Du coup, on a des soucis de synchronisation en moins car on ne travaille pas sur les mêmes données.

Prennons l'exemple du Z-test . J'ai (enfin, le GPU a) un pixel interpolé a partir des sommets. Il compare le Z de ce pixel a ce qui est marqué dans le Z buffer. Si le pixel en question est devant, il continu le traitement, sinon il passe a un autre pixel.

C'est la tout le soucis. Le choix de ce nouveau pixel, il sort d'ou ? Il faut bien de la synchro à ce moment la, comment le GPU le gère-t-il ?

La ou tu as raison, c'est que c'est l'attitude d'intel ou consort qui me fait tiquer. Les CPU en parallèle, c'est bien joli, mais ca va montrer ses limites rapidement, a moins de mettres des solutions au niveau matériel ET logiciel en place (comme cela existe sur un GPU).

[screetch]

Les taches longues ou courtes seront mieux reparties sur 1024 cores que sur 2. Le vrai probleme des 1024 cores serait de les occupper tous, pas de faire la repartition elle meme.

[LeGreg]

Envoyé par deadalnix

Prennons l'exemple du Z-test . J'ai (enfin, le GPU a) un pixel interpolé a partir des sommets. Il compare le Z de ce pixel a ce qui est marqué dans le Z buffer. Si le pixel en question est devant, il continu le traitement, sinon il passe a un autre pixel.

C'est la tout le soucis. Le choix de ce nouveau pixel, il sort d'ou ? Il faut bien de la synchro à ce moment la, comment le GPU le gère-t-il ?

Tout dépend de la granularité :
Le GPU moderne ne peut pas descendre en dessous du Quad (quatre pixels), donc si un seul pixel est masqué sur un quad de pixels alors les quatre pixel shaders sont tout de même exécutés : il en a besoin pour les calculs de dérivés dans le pixel shader ! d'où l'intérêt du locked step d'ailleurs, en pratique le quad shader est une unité de calcul vectorielle qui travaille sur quatre pixels simultanément même si le mode de programmation est scalaire et traite les pixels indépendamment.

Si la totalité du quad est caché, alors l'unité de pixel shader va tout simplement ignorer la tâche et prendre la suivante dans sa queue. Je ne vois pas où est le problème.

Quant à la synchro, tu raisonnes encore comme pour un CPU. Un GPU c'est du hardware spécialisé. là où il faudrait écrire un programme pour implémenter le test de Z et des manipulations de listes ou d'arrays ou je ne sais quoi, le GPU l'implémente sous forme de transistors organisés dans un pipeline quasi linéaire. Rien n'interdit d'avoir un mode d'execution synchro entre plusieurs parties si les temps d'execution sont prédictibles.

clipping -> setup -> raster -> early z -> shading ->

Si shading est bouché, il propage l'information en amont, l'unité en amont a donc soit le choix de s'interrompre soit de continuer à exécuter jusqu'à ce qu'elle ait rempli un tampon temporaire. La seule synchro nécessaire est entre une unité et celle qui la précède et celle qui la suit et cela ne se fait pas par des system-wide locks programmables comme un GPU, mais par une logique plus simple retranscrite en transistors (pour simplifier à l'extrême).

Il y a les mêmes choses dans un CPU (un CPU est également pipeliné), le langage de programmation = interface du hardware mais le hardware lui-meme a beaucoup de logique interne sous forme de transistors qui n'est pas directement accessible programmatiquement.

LeGreg

[deadalnix]

N'aie pas peur d'en dire plus, tu commence a rentrer dans le vif du sujet N'aie surtout pas peur d'y aller franchement avec la mécanique interne des CPU, c'est mon domaine. Le GPU moins, bien que j'en conniasse les grande lignes.

Continuons sur le Z test. En supposant qu'aucun des pixels du quad ne le passe, alors le shading ne se lance pas. Si un des 4 le passe, alors ces points sont mis en attente, et l'étage suivant les prend dès qu'il en a finit avec les précédents.

On peut supposer un système de flag ou quelque chose de proche pour signaler si l'unité de calcul est prête ou non a prendre de nouvelles données.

Comme on ne sait pas quel temps va mettre le shader a s'éxécuter (ou même s'il va s'éxécuter) les aléas vont se propager jusqu'a l'entrée du pipeline. Celui-ci sera amené a être prêt ou non a recevoir de nouvelles données a plus ou moins n'importe quel moment.

Cette entrée doit se trouver quel part au niveau du raster dans ton shema.

ceci veux dire que mes unités de calcul peuvent être amenées à demander des nouveaux pixels à n'importe quel moment ou presque.