Discussion :

[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]

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]

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.

[LeGreg]

En tant que designer de hardware ta responsabilité c'est de dimensionner les fifos et autres tampons de manière raisonnable (pas trop grande pour pas bouffer des transistors, pas trop petite pour ne pas affamer telle ou telle unité) de manière à laisser un peu de marge sur l'imprévisible.

Bien évidemment ce n'est pas uniquement une question de taille de FIFO si les flux sont trop assymétrique :
si le z-test refuse les pixels trop rapidement (ça peut arriver notamment parce que les GPUs intègre un z-test hierarchique qui peut refuser des centaines de pixels par cycle), alors ton unité de pixel shader peut se retrouver à attendre qu'on lui fournisse du travail. Mais si ça arrive tu t'en fiches parce que c'est le paradis pour toi (le pixel le plus rapide c'est celui qui n'est pas tracé) .

Enfin jusqu'à un certain point, ça veut aussi dire que tu es peut-etre setup limited. Et là.. il faut trouver un moyen au niveau de l'application de diminuer le coût du setup. (sur PS3 qui a tendance a être facilement setup limited, certains programmeurs font du culling de géométrie sur le Cell pour "assister" le GPU).

LeGreg

[Invité]

Enfin jusqu'à un certain point, ça veut aussi dire que tu es peut-etre setup limited. Et là.. il faut trouver un moyen au niveau de l'application de diminuer le coût du setup. (sur PS3 qui a tendance a être facilement setup limited, certains programmeurs font du culling de géométrie sur le Cell pour "assister" le GPU).

Tu es sûr que c'est propre aux programmeurs PS3? Selon moi, même sans "The Cell", ce n'est pas nouveau qu'on utilise des méthodes de subdivision de l'espace puis une méthode de culling (view frustum culling ou contribution culling par exemple) pour macher le travail du GPU en lui passant une plus petite partie de la géométrie.

[LeGreg]

Le culling grossier n'est pas spécifique (frustum culling, conditional rendering etc) et effectivement, de la meme façon que le pixel le moins cher c'est celui qui n'est pas tracé, le triangle le moins cher et l'objet (mesh + renderstate) le moins cher est celui qui n'est pas envoyé à la carte graphique (et qui n'est pas à traiter par le CPU).

Le culling dont on parle sur PS3 (je n'ai pas de chiffre ou de nom à donner, désolé) était un peu peu plus précis : en général on considère que faire du culling/vertex processing par triangle sur le CPU est trop coûteux pour le gain apporté. Mais dans certaines situations comme sur PS3 c'était bénéfique, sans compter que le vertex shader est fixe sur PS3 (rsx basé sur geforce6/7) contrairement aux derniers GPUs qui partagent les unités de math entre vertex et pixel.

C'est un pur trade off comme souvent en programmation. Le PC tend à ne pas avoir un core ou de SPE à dédier au vertex processing (sauf sur certaines configs déséquilibrées avec un CPU démesuré pour un GPU bas de gamme) et donc dépenser du temps CPU pour ça parait futil surtout que c'est une fraction de la base utilisateur (qui peut toujours baisser les détails et le nombre de polygones à afficher), sur console le hardware est fixe (ça touche 100% de la base), l'API est ultra légère avec peu d'overhead, il faut booster les graphismes au maximum pour paraitre concurrentiel au niveau des graphismes. Et il y a probablement un SPE qui peut-etre dédié à la tâche en question.

Mais effectivement même quand on programme même sur PC il faut toujours faire attention à bien déterminer son goulet d'étranglement (pour ne pas chercher à réduire le coût CPU quand c'était le setup qui bloquait etc).

LeGreg

[copter74]

Bonsoir,

J'aurais une question et je cherche plein d'infos a cette reponse mais c'est tres flou dans mes conclusions !
Je pense qu'ici je ne peux rêver mieux pour la poser...

J'ai appris que le direct X11 va gérer le multithrading avec un système de buffer...
Le directX11 arrive en début 2009 ainsi que les cartes graphiques...bon OK je vous apprend rien

Je découvre une très grande complexité dans la programmation que j'avais du mal a soupçonner en vous lisant assez silencieusement et c'est très instructif.

Il faut attendre que le multlithreading soit optimisé a combien de % avant d'être validé, et surtout avez vous une date officiel, estimé, ou une idée personnel de quand est-ce que le premier jeux (*Alan Wake ) pointera le bout de son nez avec une gestion multitreading sur plusieur core ????
...une limite commerciale ?

http://fr.youtube.com/watch?v=mV2AYo...eature=related
http://fr.youtube.com/watch?v=CLEBOn9K5Nk&NR

1an , 5ans ?
N'hésiter pas a répondre les gars toutes vos réponses sont les bienvenues et merci

encore une tant que j'y suis
Le jeux devra t-il etre spécialement devellopé pour etre gere sur plusieurs CPU ou une sorte de patch qui analyse le programme et dispatche les charges est envisable a terme ?

[deadalnix]

Il y a déjà des débuts de choses. Il faut par contre repenser pas mal de choses et ça prendra du temps à être bien maîtrisés.

La prochaine génération de moteurs devrait bien supporter ces technologies (je penses à tech5 par exemple). Comme aucune date de sortie n'est annoncée . . .

Disons que cette première génération va exploiter la chose, mais des améliorations vont être amenées au fil du temps.

[copter74]

C'est vraiment enorme....merci deadalnix mais toujours pas une date...Alan Wake sortirai en 2009 ?
Tu dis que cela prendra du temps mais combien de de temps a peu pres ?

Sans parler du Nehalem (qui ne sera pas abordable avant le 32nm) il vaut mieux prendre un Quad@3.6Ghz ou un C2D@4.2Ghz pour les jeux multicore qui vont arriver...si il vont arriver un jour ! Il arrive quand ? La monter en Frequence c'est terminé je pense ?

Vous en pensez quoi ?
merci

[deadalnix]

La montée en fréquence n'est pas terminée. Comme on en discutait plus haut, le parallélisme a des limites. Certaines choses ne sont pas parallélisable ou difficilement.

Je pense que la solution sera dans une archi avec quelques cores complexes destinéés a éxécuter l'applicatif (comme les cores de CPU actuels) le tout secondé d'un armada d'unités de calculs plus simples.

Mais on est encore loin de ce genre de choses. Pour le jeu, je pense que le C2D reste encore une valeur sur pour un moment. En effet, d'ici que 4 cores soient bien exploités par les jeux, le C2D ne sera de toute façon plus d'actualité.

[buggen25]

Salut tous le monde;
Ce que peut aporter le multithreading aux jeux video.
C'est une reponse un peu bete; il faut demarrer un jeux récent comme "call fo duty advance war fighters" ou "assassins creed" ..
Allez dans le gestionnaire des processus et voir combien de "threads" portent le processus

[deadalnix]

La répartition des taches n'est pas vraiment très efficace dans ces moteurs. Les thread sont souvent la pour charger des ressources en asynchrone, gere certains modules spécifiques comme le son ou l'ia, mais ca reste de parallélisme de taches. Le potentiel du multithread peut être bien plus grand.

[buggen25]

J'ai fait quelques programmes en d3d ( la version 9c) mais je pense que le multithreading est pour le future quand il y aura du vrai paralellisme ( dans les ordinateurs personnels ) car pour le moment sa reste du "pseudo-parallelisme"

[shenron666]

attention avec directx 11, certains semblent "l'attendre" comme le messie
n'oubliez pas qu'aujourd'hui le rendu est déjà massivement multithreadé au sein du GPU
perso je n'attend rien de directx 11 tout comme il ne falait rien attendre de directx 10 qui, au final, n'est rien d'autre qu'une machine commerciale pour pousser vista devant xp
de là à croire qu'il sera là début 2009, si on parle en semestre, ce sera pas avant juin et il faudra vista

Il faut attendre que le multlithreading soit optimisé a combien de % avant d'être validé, et surtout avez vous une date officiel, estimé, ou une idée personnel de quand est-ce que le premier jeux (*Alan Wake ) pointera le bout de son nez avec une gestion multitreading sur plusieur core ????

le multithreading EST une optimisation
qu'entends tu par "optimiser le mutithreading" dans ce cas ?
des jeux multithreadés il en existe déjà, supreme commander est bien optimisé jusque 3 coeurs
l'avenir du multithread sera lié à l'amélioration des compilateurs et des profileurs afin de faciliter le parallélisme des taches pour le programmeur
pour une date, voir avec madame irma

et le retour au "software rendering" qui, grace à la multiplication des coeurs d'execution, reprendra le dessus sur les pipelines des cartes graphiques rigides, on va devoir se réadapter, OpenCL sera je pense de la partie
le GPU sera un coprocesseur au même titre que la FPU et surtout, les développeurs auront une plus grande liberté dans leur moteur de rendu (fini les triangles ?)