Discussion :

[martin1975]

J'ai comme l'impression que la question du pour ou contre du multitâche dans les jeux vidéo n'a plus lieux d'être, puisque c'est une réalité sur les consoles et même sur PC depuis longtemps. Cela avait timidement commencé en fournissant, avec la PSone, par exemple, des processeurs spécialisés dans certaines tâches (comme le rendu de triangles). En parallèle, les PC s'y sont mis avec des cartes 3D de plus en plus puissantes. Désormais, les cartes 3D PC permettent d'exécuter du code arbitraire, non seulement limité à la 3D.

Les consoles de dernière génération, je pense à la PS3 et la Xbox 360, sont intéressantes et proposent deux approches légèrement différentes, bien que très hautement multi-tâches.

Sur la Xbox 360, nous avons des processeurs généralistes pouvant exécuter chacun 2 tâches en parallèle, en plus d'une carte 3D qui peut elle même être programmée de sorte à pouvoir exécuter pour ainsi dire tout type de calcul.

Sur la PlayStation 3, nous avons plusieurs processeurs généralistes destinés à gérer l'ensemble des tâches d'un jeu, y compris l'affichage et le son. De ce fait, le multitâche est une réalité permanente dans le cadre d'un moteur 3D, par exemple, si l'on peut tirer un maximum de puissance de la console.

Maintenant, la question que l'on devrait se poser est de savoir comment on peut tirer toute la puissance de ces machines multi-cœurs, notamment en désynchronisant l'ensemble des tâches exécutées par le jeu, et pas uniquement la seule tâche 3D.

Depuis peu, après quelques années d'absence du jeu vidéo, je m'y remets. Mon premier réflexe est de me limiter à un moteur de jeu très synchrone, désynchronisant juste le rendu, le délaissant à la carte 3D. Cependant, mes productions en cours n'ont pas l'ambition des block busters du moment. En revanche, dans un proche avenir, je devrais tenter de désynchroniser l'ensemble des tâches de mes jeux pour tenter de tirer partie des différentes configurations possibles chez les joueurs. En effet, les machines bi-cœurs deviennent banales chez les joueurs, et les machines quadri-cœurs arrivent peu à peu. Il serait dommage de n'utiliser qu'une infime partie de la puissance de calcul de ces ordinateurs avec pour seul prétexte la simplicité de développement (qui n'est pas nécessairement un simple prétexte quand le budget est serré).

[Fraggy]

J'ai comme l'impression que la question du pour ou contre du multitâche dans les jeux vidéo n'a plus lieux d'être, puisque c'est une réalité sur les consoles et même sur PC depuis longtemps.

le multicore est une réalité, on est tous d'accord.
par contre, de savoir si le multithread peut apporter qq chose... c'est une autre histoire...
Disons que si la programmation multithread fonctionne facilement et linéairement sur les futures processeurs massivement multicoeur, la question n'a pas lieu d'être effectivement.

Mais programmer parallèle pour le jeu vidéo c'est un enfer :
- faut se former et ne pas être bête/flemard, ca prend du temps
- le code en lui même est difficile a appréhender (faire "tourner" plusieurs threads en parallèle dans sa tête pour développer n'est pas à la portée de tout le monde)
- il génère des bugs, difficile à comprendre, à pister et à corriger (non déterminisme du code)
- il faut (et c'est le pire) revoir tous le code existant. (si on veut vraiment des perf)
- les jeux sont bloqué à x3 (x5 pour les optimistes/fous) quelques soit le nb de coeurs...
la question se pose : faut il programmer multithread et se prendre la tete avec du code inbitable et non maintenable ? ou faut il innover sur l'interface Homme/Machine, sur les scenarii, la qualité graphique etc... pour des wii ou des consoles portables ?

Mon premier réflexe est de me limiter à un moteur de jeu très synchrone, désynchronisant juste le rendu, le délaissant à la carte 3D.[...]. En revanche, dans un proche avenir, je devrais tenter de désynchroniser l'ensemble des tâches de mes jeux pour tenter de tirer partie des différentes configurations possibles chez les joueurs.

C'est effectivement le premier réflexe classique (modèle fonctionnel). Ce model n'ira pas au dela de 3x, malheureusement.

La deuxième étape c'est d'utiliser massivement des algorithmes paralleles. par exemple le ray casting. L'utilisation d'un moteur 3D de ce genre peut occuper facilement 8/12 coeurs, une IA distribuée aussi, de même un moteur de physique devrait aussi se paralléliser. C'est le passage au modèle de parallélisation basée sur les données.

Non seulement c'est complexe (90% de la difficultée que je décris ci avant viens de là) mais en plus de cela on se trouvera vite limité en performance !!!

La question reste ouverte à mon sens

[LeGreg]

La deuxième étape c'est d'utiliser massivement des algorithmes paralleles. par exemple le ray casting. L'utilisation d'un moteur 3D de ce genre peut occuper facilement 8/12 coeurs, une IA distribuée aussi, de même un moteur de physique devrait aussi se paralléliser. C'est le passage au modèle de parallélisation basée sur les données.

Euh la référence au ray casting.. Par rapport à quoi ? La rasterisation ? Il faut réviser tes classiques :/.

Sinon, sur PC, par exemple, dans quelques temps il sera possible d'exploiter mieux le parallélisme du processeur PC de base (dual, quad, bientot octo voire hexadeca) en faisant faire le tracé d'une scène complexe en sous parties indépendantes :
http://jeux.developpez.com/tutoriels/directx11/

LeGreg

[Fraggy]

Euh la référence au ray casting.. Par rapport à quoi ? La rasterisation ? Il faut réviser tes classiques :/.

pas compris ce que tu veux dire.
tu veux dire que le ray casting ne se parallélise pas ?
http://fr.wikipedia.org/wiki/Raycasting

[LeGreg]

pas compris ce que tu veux dire.
tu veux dire que le ray casting ne se parallélise pas ?

par opposition à quoi ? j'imagine que tu l'opposes à la rasterisation ?

[Fraggy]

par opposition à quoi ? j'imagine que tu l'opposes à la rasterisation ?

tj pas compris ce que tu veux dire !!!

Le ray casting peut tendre vers du vrais ray tracing si tu le distribues sur de multiple coeurs. c'est tout ce que je voulais dire
Dans le cadre d'un (futur) processeur 256 coeurs ça peut aider à utiliser une partie des 251 coeurs qui ne font rien quand le jeu tourne...

[LeGreg]

tj pas compris ce que tu veux dire !!!

j'abandonne

[shenron666]

Cela avait timidement commencé en fournissant, avec la PSone, par exemple, des processeurs spécialisés dans certaines tâches (comme le rendu de triangles).

attention avec PSX/one PS2/two
elles sont multiprocesseur mais chacun est spécialisé dans son domaine (les E/S, l'affichage) et c'est très restrictif (les développeurs ont mis plus de 6 ans pour en exploiter quasi pleinement les capacités)

ces copncoles sont comparable à un PC monocoeur avec une carte graphique (avant geforce pour la psone, geforce pour la ps2)

Sur la Xbox 360, [...] une carte 3D qui peut elle même être programmée de sorte à pouvoir exécuter pour ainsi dire tout type de calcul.

bien que les shaders soient unifiés, le GPU xenos de la xbox360 n'est pas capable de faire du GPGPU

Sur la PlayStation 3, nous avons plusieurs processeurs généralistes destinés à gérer l'ensemble des tâches d'un jeu, y compris l'affichage et le son.

le cell c'est 1 CPU généraliste avec SMT 2 voies (2 coeurs virtuels, équivalent à l'Hyperthreading) et 7 SPU (specialised processing unit)

- les jeux sont bloqué à x3 (x5 pour les optimistes/fous) quelques soit le nb de coeurs...

tu as vu ça où que l'on est limités à x3 voire x5 ?
ton expérience personnelle ?
la réalité actuelle ?
désolé mais je ne vais pas dans ton sens car :
- les moteurs massivement multithreads ne sont pas encore là
- les machines grand public actuelles sont limitées à 4 coeurs
- les outils de développement ne sont pas optimisés
- vu les possibilités, on n'en est même pas à 1% de réflexion sur le sujet

la question se pose : faut il programmer multithread et se prendre la tete avec du code inbitable et non maintenable ?

le code multithread n'est ni inbitable ni non maintenable, surtout quand on sait soi même programmer en multithread
les problématiques ne sont pas les mêmes mais si le code est bien fait on évite de les rencontrer
la difficulté c'est d'obtenir un gain de perfs le plus proche possible du nombre de coeurs à disposition

Non seulement c'est complexe (90% de la difficultée que je décris ci avant viens de là) mais en plus de cela on se trouvera vite limité en performance !!!

c'est parceque tu cherches à paralléléliser les taches indépendamment que tu seras limité en performances
mais pas à x3 ou x5, tu iras bien au delà, mais ce sera plus lent (x10 sur 15 coeurs par exmple)

Euh la référence au ray casting.. Par rapport à quoi ? La rasterisation ? Il faut réviser tes classiques :/.

c'est clair, le raycating faire partie de l'histoire ancienne, pas du futur
paralléléliser wolfenstein c'est bien beau mais le résultat restera plat comme de la 2D / fausse 3D

tracé d'une scène complexe en sous parties indépendantes :
http://jeux.developpez.com/tutoriels/directx11/

je suis très perplexe face à tout le barratin commercial autour de directx11 et sa parallélisation du rendu
de là à dire que je n'y crois pas il n'y a qu'un pas
j'attendrais de voir les gains réels avant d'être convaincu
si c'est comme directx10 ça risque pas de voler très haut

[TanEk]

pas compris ce que tu veux dire.
tu veux dire que le ray casting ne se parallélise pas ?
http://fr.wikipedia.org/wiki/Raycasting

Il veut dire que l'intérêt du raytracing n'est pas dans sa parallélisation (car la rasterisation actuellement utilisée sur les GPUs est massivement parallèle, et d'ailleurs plus facilement parallélisable sur les architectures actuelles par rapport au raytracing) mais dans la résolution de problèmes qui sont complexes à résoudre en rasterisation (genre les réflections). Donc en gros il veut dire que tes propos n'ont aucun intérêts sur ce point.

c'est clair, le raycating faire partie de l'histoire ancienne, pas du futur
paralléléliser wolfenstein c'est bien beau mais le résultat restera plat comme de la 2D / fausse 3D

Heu, en quoi le raycasting est plus 2D / fausse 3D par rapport à la rasterisation ? La rasterisation donne les mêmes résultats qu'un raycasting. Je crois que vous êtes en train de vous emmêler les pinceaux.

[Fraggy]

tu as vu ça où que l'on est limités à x3 voire x5 ?
ton expérience personnelle ?
la réalité actuelle ?
désolé mais je ne vais pas dans ton sens car :
- les moteurs massivement multithreads ne sont pas encore là
- les machines grand public actuelles sont limitées à 4 coeurs
- les outils de développement ne sont pas optimisés
- vu les possibilités, on n'en est même pas à 1% de réflexion sur le sujet

mon expérience personnelle et la réalité actuelle
les qq moteurs en production sont entre x2 et x3. D'autres sont en dev (qui font du raytracing sauce raycasting, je m'explique plus bas) et ceux la iront probablement vers 5x sans certitude d'aller au dela...
y a des workstations à 12 coeurs déjà :p sans être grand public ça permet de faire des tests de perf.

le code multithread n'est ni inbitable ni non maintenable, surtout quand on sait soi même programmer en multithread
les problématiques ne sont pas les mêmes mais si le code est bien fait on évite de les rencontrer
la difficulté c'est d'obtenir un gain de perfs le plus proche possible du nombre de coeurs à disposition

ca ne semble pas etre l'avis des pratiquants :p les dev qui sont en plein dedans s'arrache les cheveux...
Note que j'ai développé un moteur de parallélisation pour le JV et je te rejoins à 100% : mon code est parfaitement "bitable" !!!
Si tu veux des perfs tu es tenté de paralléliser tout ce qui est parallélisable (ce qui est le mal absolu). Dans le même temps tu fous le bordel avec des locks a n'en plus finir...

mais pas à x3 ou x5, tu iras bien au delà, mais ce sera plus lent (x10 sur 15 coeurs par exmple)

Je suis d'accord sur tes chiffres. par contre les moteurs actuels et les algo actuel ne le permettrons pas. Les méthodes aujourd'hui c'est parallélisation fonctionnelle + data. ça n'ira pas loin en perf, pas plus de 5 selon mes estimations et celles d'autres sont encore moins optimistes...

c'est clair, le raycating faire partie de l'histoire ancienne, pas du futur
paralléléliser wolfenstein c'est bien beau mais le résultat restera plat comme de la 2D / fausse 3D

le moteur graphique software c'est l'avenir
oublie le ray casting, je vous ai enduit en erreur, dsl...
j'aurais du employer le terme de "rayTRACING software", l'idée est de faire faire les calculs de rendu d'une partie du jeu sur le processeur principal... Tu sature la carte graphique avec des super décors de la lumière des ombres, des particules etc ... et tu utilises le processeur multicoeurs pour faire le rendu des personnages (juste un exemple de répartition entre GPU/CPU).
Voir Goodbye GPU (interview de Tim Sweeney, EPIC Game)
http://arstechnica.com/gaming/news/2...-interview.ars

Évidemment sur un 4 coeurs faire du ray tracing c'est idiot (niveau résultat graphique) mais sur un 256 coeur ? tu distribues tes besoins de calcul graphique entre un moteur de rendu software (en raytracing donc) et ta carte graphique !!!
-> tu utilises avantageusement les coeurs mal utilisés par ton jeu.

[Fraggy]

Heu, en quoi le raycasting est plus 2D / fausse 3D par rapport à la rasterisation ? La rasterisation donne les mêmes résultats qu'un raycasting. Je crois que vous êtes en train de vous emmêler les pinceaux.

j'aurais pas du utiliser ce terme, désolé.
le ray casting est plus généralement une version optimisé (en vitesse) du raytracing.
l'une des pistes de la parallélisation consiste a tendre vers du raytracing temps réel calculé sur le processeur principal, quand celui ci disposera de suffisamment de coeurs.

[TanEk]

le moteur graphique software c'est l'avenir
oublie le ray casting, je vous ai enduit en erreur, dsl...
j'aurais du employer le terme de "rayTRACING software", l'idée est de faire faire les calculs de rendu d'une partie du jeu sur le processeur principal... Tu sature la carte graphique avec des super décors de la lumière des ombres, des particules etc ... et tu utilises le processeur multicoeurs pour faire le rendu des personnages (juste un exemple de répartition entre GPU/CPU).
Voir Goodbye GPU (interview de Tim Sweeney, EPIC Game)
http://arstechnica.com/gaming/news/2...-interview.ars

Évidemment sur un 4 coeurs faire du ray tracing c'est idiot (niveau résultat graphique) mais sur un 256 coeur ? tu distribues tes besoins de calcul graphique entre un moteur de rendu software (en raytracing donc) et ta carte graphique !!!
-> tu utilises avantageusement les coeurs mal utilisés par ton jeu.

Encore une fois tu mélanges les choses. Ce qui est dit dans cette interview c'est que l'architecture des GPUs et des CPUs est en train de se rejoindre : l'un arrive à exécuter du code de plus en plus généraliste, l'autre arrive à exécuter de plus en plus d'instructions en parralèle (de plus en plus de coeurs, je rappelle que pour le moment, les derniers GPUs ont entre 200 et 300 coeurs en gros, c'est loin des prochains 8 ou 16 coeurs pour les CPUs...).

Mais il semblerait dans la pratique que les GPUs gagnent la bataille du massivement parallèle généraliste. Voir par exemple mon annonce d'un moteur de raytracing exécuté sur GPU par NVidia. Les GPUs sont déjà capable de faire ça bien mieux que le CPU.

Et contrairement à ce que tu crois, actuellement c'est plus le CPU qui est une limitation dans les PCs que le GPU en terme de calcul brut (d'où le passage du calcul de physique sur le GPU avec PhysX par exemple dans Mirror's Edge). Toi tu fais le constat inverse de la réalité : beaucoup de calculs faits sur CPUs sont migrés sur GPUs et non l'inverse car les jeux deviennent de plus en plus CPU bound. Et c'est tellement le cas, que pour éviter au GPU d'attendre trop longtemps les instructions du CPU, que DirectX 11 veut être multi-threadé : pour envoyer le maximum d'instructions possibles au GPU en utilisant le plus de coeur possible (Greg, corrige-moi si je dis une bêtise).

En bref : oui on tend de plus en plus dans du rendu "software" dans le sens où on veut de plus en plus tout contrôler et personnaliser (par les shaders, par le GPGPU) mais on y tend vers un paradigme de calculs vectoriels qui a l'heure actuelle n'est pas du tout adapté à l'architecture CPU mais marche très bien sur GPU. Oui on va peut-être aller à une fusion du GPU et du CPU (architecture unifiée, le shader 4.0 dit architecture unifiée ça ne vous fait pas tilt ? Le GPPGPU a été permis car une uniformisation de l'architecture du GPU a eu lieu permettant de faire du calcul généraliste vectorisé), mais non, ce ne sera pas le CPU qui exécutera le rendu software mais bien le GPU. Là est ton incompréhension sur l'interview comme beaucoup de gens le font : ils entendent software forcément ça veut dire CPU car programmable. Non, le GPU est maintenant fortement programmable. D'ailleurs tu peux écrire un programme et l'exécuter entièrement sur le GPU en C++ (j'exagère bien sûr, mais pas tant que ça). A part le polymorphisme et le récursif, tout le reste : les templates, l'héritage, tout ça ça marche déjà sur la dernière version de CUDA (avec quelques bugs parfois, d'où la non officialisation de la chose, on va dire que c'est de l'alpha ).

Voire peut-être pour très longtemps, personnellement je pense qu'il y aura toujours une partie généraliste CPU et une partie calculs vectorisés massivement parallèles GPUs qui communiqueront, le langage de programmation s'occupant de faire abstraction des deux. D'ailleurs le langage CUDA le fait très bien déjà. Le seul truc qui est encore embêtant c'est les copies de données entre la mémoire vive du CPU et celle du GPU. Je parierais ma main que la prochaine étape de fusion sera une abstraction des copies de données en mémoire dans un langage (CUDA, OpenCL, autre) voire même la même mémoire vive utilisée pour le CPU et le GPU (comme ça l'est d'ailleurs déjà fais parfois dans les portables) au prix d'une responsabilité ajoutée au programmeur de contrôler les accès mémoires par le CPU et le GPU sur une même zone mémoire.

[Fraggy]

Encore une fois tu mélanges les choses. Ce qui est dit dans cette interview c'est que l'architecture des GPUs et des CPUs est en train de se rejoindre

oui, se rejoindre pour donner une plateforme utilisable en C++ seulement. il précise d'ailleurs que ce qui compte pour lui c'est le langage, un seul langage pour tous ce qu'il y a à faire...
Il indique que ce qui l'intéresse c'est que le truc qui va exécuter son code marche en C++, que ce soit une carte graphique ou un cpu (ou les deux)
"Whether that runs on NVIDIA hardware, Intel hardware or ATI hardware is really an independent question. You could potentially run it on any hardware that's capable of running general-purpose code efficiently. "

un autre article un peu plus clair : http://www.jeuxvideo.fr/tim-sweeney-...tu-128998.html
"Tim Sweeney va plus loin en parlant d'un éventuel retour au « rendu software » afin de se passer de cartes graphiques surpuissantes... Clairement l'élément qui, lorsqu'il sert à faire vendre des systèmes Triple-SLI, fait le plus grand tort au jeu vidéo sur PC d'après le président d'Epic."

C'est pas parce que Sweney est un ponte que c'est forcement ce qui va arriver !!! Je dis juste que "certains" s'essayent au moteur 3d software pour utiliser des monstres a 96 coeurs comme larabee !!!!!
Après que ça en fasse bondir plus d'un, c'est normal...

je rappelle que pour le moment, les derniers GPUs ont entre 200 et 300 coeurs en gros, c'est loin des prochains 8 ou 16 coeurs pour les CPUs...).

Attention, 200 et 300 c'est du marketing, le CPU n'est pas loin derriere. et Larabee va passer carrément a la vitesse supérieure
"A GPU vendor quoting a "240 cores" is actually referring to a 15-core chip, with each core supporting 16-wide vectors (15*16=240). This would be roughly comparable to a 15-core Larrabee chip." (toujours sweenney dans les commentaires)
http://rebelscience.blogspot.com/200...rogeneous.html

Mais il semblerait dans la pratique que les GPUs gagnent la bataille du massivement parallèle généraliste.

Les avis sont partagés. selon nvidia larrabee va se faire exploser (normal, hein). d'autre disent le contraire...
J'ai l'impression que niveau puissance c'est kiifkif. L'avantage est a larrabee qui semble être un système plus généraliste. En gros si tu fabriques une console avec un larabee (tout seul, sans processeur classique) dedans tu as une sorte de PC quasi normal !!! donc ya bon
Perso je vote pour larabee et le moteur 3D software !

Et contrairement à ce que tu crois, actuellement c'est plus le CPU qui est une limitation dans les PCs que le GPU en terme de calcul brut (d'où le passage du calcul de physique sur le GPU avec PhysX par exemple dans Mirror's Edge). Toi tu fais le constant inverse de la réalité : beaucoup de calculs faits sur CPUs sont migrés sur GPUs et non l'inverse car les jeux deviennent de plus en plus CPU bound.

Pourquoi est on limité par le CPU ?
Pourquoi est il trop faible par rapport au GPU ?
Pour moi c'est le passage au multicoeur qui empeche d'utiliser correctement les CPU modernes(cf les difficultés de codage multithread !).
Tous les 18 mois le processeur double son nb de coeurs. Mais n'est pas plus utilisé qu'un 2 coeurs a cause des difficulté de parallélisation. Dans le même temps les cartes graphiques doublent également de puissance (normal, voir la loi de moore). par contre pas de pb d'utilisation de puissance vu que le parallelisme c'est "naturel".
Ce qui explique que le GPU fait de plus en plus de taf au final...le transfert est simplement statistique !!!

Vincent

[TanEk]

Attention, 200 et 300 c'est du marketing, le CPU n'est pas loin derriere. et Larabee va passer carrément a la vitesse supérieure

Les derniers "GPUs" Tesla spécialisés pour le GPGPU font plus de 1 teraflop/s de calcul en double précision avec une bande passante dépassant les 100 Go/s pour la mémoire, ça écrase complètement les derniers i7 qui ont une puissance qui ne dépasse pas les 100GigaFlop/s (ptetre que si, j'en sais rien mais en voyant large je suis presque sûr que ça dépasse pas les 300 GFlop) en utilisant du SIMD sinon divisez par 4 (et encore là je parle en simple précision, en double c'est pas 100 GFlop mais 50) et l'accès à la mémoire qui est loin d'être à 100 Go/s mais plus de l'ordre de 15 Go/s. C'est vraiment à prendre avec une grosse fourchette, si des personnes on des chiffres précis n'hésitez pas, c'est juste pour se donner un ordre de grandeur.

Les avis sont partagés. selon nvidia larrabee va se faire exploser (normal, hein). d'autre disent le contraire...

Intel n'a pas l'expertise de NVidia là-dessus et le problème ne vient pas du nombre de coeurs ou de leur puissance mais bien de l'accès aux données (architecture très particulière qui n'est pas adapté pour du calcul "généraliste"). Comme je l'ai dis plus haut, un nouveau paradigme entre dans la programmation c'est celui d'algorithmes dis vectorisables. Et ceci ne s'implante que sur des architectures spécialisées pour ça qui devront être proches de celles des GPUs et qui n'ont pas les mêmes besoins (surtout au niveau de l'accès mémoire et de la gestion de cache) que les calculs généralistes (logique du logiciel) qui sont plus adaptés sur une architecture dite CPU. Au final on peut voir le SIMD sur le CPU comme une toute pitite carte graphique, un embryon. Si on arrive à rapprocher la communication entre les deux architectures, rien ne dit qu'ils ne pourront pas être sur un même chip (comme intel vient d'intégrer directement le contrôleur mémoire dans le CPU).

Perso je vote pour larabee et le moteur 3D software !

Juste pour être sûr qu'on s'est bien compris : un moteur 3D software est actuellement implantable sur GPU.

Pourquoi est on limité par le CPU ?
Est il trop faible par rapport au GPU ?

On va dire que le GPU va parfois 100 fois plus vite pour du calcul vectoriel adapté à l'architecture du GPU et dans tous les cas plus de 10 fois plus vite même en utilisant la toute puissance du CPU (multi-thread et SIMD)... et ça va empirer pour encore au moins 2 ou 3 ans (depuis maintenant 6 ans environ l'avancée en puissance de calcul sur des flottants est linéaire sur les CPUs et exponentielle sur les GPUs).

[Fraggy]

Les derniers "GPUs" Tesla spécialisés pour le GPGPU font plus de 1 teraflop/s de calcul en double précision avec une bande passante dépassant les 100 Go/s pour la mémoire, ça écrase complètement les derniers i7 qui ont une puissance qui ne dépasse pas les 100GigaFlop/s

L'intérêt de larabee réside dans ça faculté a être proche d'un processeur classique qui accepte de faire du C++ standard (j'espère aussi que ça va dans cette direction...)
que les cartes graphiques soit plus puissante (ou pas, je tiens pas partir sur ce terrain) ne change rien : si on peut faire du code 3D sur un processeur généraliste, c'est plus simple pour les développeurs et on peut faire des algo qui jusqu'à présent était dans les cartons... (en gros, les cartes graphiques, sont rapide mais restrictive)
En gros, si larabee permet de faire tourner du C++ normal efficacement (c'est pas gagné) les moteurs 3D software vont devenir legion, plus facile a codé, plus souple.
Sans compter qu'il peuvent tj délégué au GPU certains calculs que la carte graphique à l'habitude de faire.

Intel n'a pas l'expertise de NVidia là-dessus et le problème ne vient pas du nombre de coeurs ou de leur puissance mais bien de l'accès aux données (architecture très particulière qui n'est pas adapté pour du calcul "généraliste").

tu parles de l'architecture de larabee ? Qui n'est pas adapté pour du calcul généraliste ?

Pour moi Larabee ce sera un flop tel qu'il est prévu.

la guerre entre proGPU et proCPU a commencer il y pas mal de temps déjà... celui qui gagnera c'est celui qui sera utilisé : si larabee malgré ces défauts devient généraliste, les développeurs vont arrêter de ce prendre la tête avec plusieurs langages, plusieurs bibliothèques... c'est tentant de faire que du C++, mais en plus de ca y a plein d'algo qu'on peut pas faire sur les GPU.
Enfin c'est de moins en moins vrais...

Juste pour être sûr qu'on s'est bien compris : un moteur 3D software est actuellement implantable sur GPU.

oui mais tu ne peux pas tout faire... Certaines choses restent implémentable uniquement sur un processeur généraliste


-------------
Désolé d'avoir balancé sans citer de sources que certains se lancent dans des moteurs 3D softwares en utilisant du ray casting sur les futurs processeurs multicoeurs !!!
Quand a savoir si c'est une bonne idée ou pas, l'avenir nous le dira !
quand a Sweeney, il y crois dur comme fer : http://www.tgdaily.com/content/view/36436/118/1/1/

Une source pour dire que la parallélisation de jeu vidéo c'est pas gagner...
Ce graphique en dit long sur le pb de parallélisation des jeux vidéo (article complet : http://www.acclib.com/2009/02/cinebe...i7-240209.html)
Il s'agit des gains de performance sur un corei7 de plusieurs applications. on mesure le gain de perf entre 1 coeur et 2 coeurs, puis entre 2 et 3 coeurs, jusqu'a 4 coeurs...

Voir les courbes verte et grise...

Vincent

[Matthieu Brucher]

Les derniers "GPUs" Tesla spécialisés pour le GPGPU font plus de 1 teraflop/s de calcul en double précision avec une bande passante dépassant les 100 Go/s pour la mémoire, ça écrase complètement les derniers i7 qui ont une puissance qui ne dépasse pas les 100GigaFlop/s (ptetre que si, j'en sais rien mais en voyant large je suis presque sûr que ça dépasse pas les 300 GFlop) en utilisant du SIMD sinon divisez par 4 (et encore là je parle en simple précision, en double c'est pas 100 GFlop mais 50) et l'accès à la mémoire qui est loin d'être à 100 Go/s mais plus de l'ordre de 15 Go/s. C'est vraiment à prendre avec une grosse fourchette, si des personnes on des chiffres précis n'hésitez pas, c'est juste pour se donner un ordre de grandeur.

Faut arrêter de se faire bouffer par le marketing tout de même. Expérience professionnelle, on tire moins de 10% de la puissance des GPU dans une application scientifique simple.
Le GPU et le CPU sont tellement différents qu'on ne peut pas leur faire faire la même chose. C'est comme quand on dit que la PS3 est la meilleure dans le Folding@Home. Il y a une partie où elle excelle, et la partie où le processeur est tellement limité que ça ne sert à rien, les x86 sont bien plus performants (puisque le processeur du Cell est un PPC duquel on a retiré une partie de l'intelligence).

Intel n'a pas l'expertise de NVidia là-dessus et le problème ne vient pas du nombre de coeurs ou de leur puissance mais bien de l'accès aux données (architecture très particulière qui n'est pas adapté pour du calcul "généraliste"). Comme je l'ai dis plus haut, un nouveau paradigme entre dans la programmation c'est celui d'algorithmes dis vectorisables. Et ceci ne s'implante que sur des architectures spécialisées pour ça qui devront être proches de celles des GPUs et qui n'ont pas les mêmes besoins (surtout au niveau de l'accès mémoire et de la gestion de cache) que les calculs généralistes (logique du logiciel) qui sont plus adaptés sur une architecture dite CPU. Au final on peut voir le SIMD sur le CPU comme une toute pitite carte graphique, un embryon. Si on arrive à rapprocher la communication entre les deux architectures, rien ne dit qu'ils ne pourront pas être sur un même chip (comme intel vient d'intégrer directement le contrôleur mémoire dans le CPU).

On retourne en arrière, c'est ça ? L'ensemble des algorithmes vectorisables est encore plus petit que cleui des algorithmes parallèles. Et à part le compilateur qui s'en occupe automatiquement, je ne veux pas avoir à m'en occuper personnellement vu la complexité des codes que j'affronte tous les jours.

[shenron666]

quand je parle de multithreader un moteur de jeu, je ne fait pas du tout allusion au moteur graphique mais à tout ce qui est à côté, à l'heure actuelle il est impossible de multithreader le moteur graphique efficacement

Larrabee n'est pas encore sorti et il n'est pas prévu avant l'année prochaine au mieux
et les GPU vont perdurer encore un moment
Larrabee devrait avoir un avantage très sérieux face aux GPU, il est généraliste
les GPU ont un très gros défaut, il gèrent très mal les boucles et les conditions (if, switch, for...) et la chute de performances est énorme
certes cela ne peux que s'améliorer mais d'ici à ce que ça se généralise on a encore au moins 3 années je pense, comme on dit "l'histoire se répète", il suffit de regarder les différentes version de directx pour voir qu'aucune n'a été réellement exploitée en moins de 3 ans après sa disponibilité
normal, un éditeur ne va pas sortir un jeu que seuls 5% des acheteurs potentiels seront capables de faire tourner

les GPU sont massivement parallèles parcequ'ils s'y prêtent aussi
les parallélisme est simple comparé à un CPU qui est intégralement généraliste
notez également que "multithreading" ne signifie pas systématiquement "lock"
il y a des structures lock-free et des systèmes atomiques qui permettent d'éviter de systématiquement locker une donnée pour la synchroniser
une autre méthode consiste également à répartir les taches intelligemment, chaque thread travaillant sur sa partie sans empiéter sur l'autre

au risque de me répéter, on en est aux balbutiements du développement multithread et les méthodes pour l'exploiter efficacement en fonction de la situation sont nombreuses
d'ici à ce qu'on ait ne serai-ce que 32 coeurs physiques dans un CPU grand public (hors Larrabee qui est considéré comme un GPU), on a encore quelques années qui vont s'écouler

Heu, en quoi le raycasting est plus 2D / fausse 3D par rapport à la rasterisation ? La rasterisation donne les mêmes résultats qu'un raycasting. Je crois que vous êtes en train de vous emmêler les pinceaux.

le raycasting et la rasterisation concerne 2 techniques très différentes
déjà le raycasting ne travaille pas sur des formes polygonales mais uniquement sur des plans et son intérêt repose là dessus
ou alors tu parles seulement de résultat visuel ? auquel cas je comprend ta remarque

[Djakisback]

Salut,
je suis ce sujet depuis quelques temps et je me pose 2 questions suite aux informations données :

- Si on tend vers des systèmes utilisant au maximum le GPU est-ce qu'au final on ne va pas tendre vers des Chipsets vidéo ce qui a priori permettrait d'augmenter la vitesse de transfert des données ? Car à l'heure actuelle est-ce que la vitesse du PCI-Express, par exemple n'est pas un problème ?

- Si on parallélise certaines tâches, comme par exemple le calcul des effets spéciaux de type fumée, eau, etc., en partant sur des systèmes autonomes, est-ce qu'on ne va pas tendre vers des rendus "non-déterministes" (pas sûr du terme ^^) ?. Ce que je veux dire, c'est que la même scène ne donnera pas le même résultat lors de deux exécutions différentes, bien qu'a priori ça ne soit pas un problème en soi ? car je me trompe peut-être mais il me semble que le temps alloué à chaque thread n'est pas forcément toujours le même à chaque cycle ? (après réflexion, je pose quand même la question mais le "problème" ne devrait pas se poser car les calculs doivent se faire sur le temps écoulé)

[Matthieu Brucher]

les GPU ont un très gros défaut, il gèrent très mal les boucles et les conditions (if, switch, for...) et la chute de performances est énorme
certes cela ne peux que s'améliorer mais d'ici à ce que ça se généralise on a encore au moins 3 années je pense, comme on dit "l'histoire se répète", il suffit de regarder les différentes version de directx pour voir qu'aucune n'a été réellement exploitée en moins de 3 ans après sa disponibilité
normal, un éditeur ne va pas sortir un jeu que seuls 5% des acheteurs potentiels seront capables de faire tourner

les GPU sont massivement parallèles parcequ'ils s'y prêtent aussi
les parallélisme est simple comparé à un CPU qui est intégralement généraliste
notez également que "multithreading" ne signifie pas systématiquement "lock"
il y a des structures lock-free et des systèmes atomiques qui permettent d'éviter de systématiquement locker une donnée pour la synchroniser
une autre méthode consiste également à répartir les taches intelligemment, chaque thread travaillant sur sa partie sans empiéter sur l'autre

Pas mieux.

[TanEk]

Faut arrêter de se faire bouffer par le marketing tout de même. Expérience professionnelle, on tire moins de 10% de la puissance des GPU dans une application scientifique simple.

Ceci m'intéresse. Peux-tu me donner l'exemple de ton application qui n'arrive pas à utiliser plus de 10% de la puissance du GPU ? Mais bon tu ne peux pas en faire une généralité. Pour tout ce qui est opérateurs morphologiques en traitement d'image, calculs en imagerie médicale, rendu volumique, simulation du marché économique, résolution de systèmes linéaires, calcul de FFT, etc. on en est pas à consommer 10% du GPU.

On retourne en arrière, c'est ça ? L'ensemble des algorithmes vectorisables est encore plus petit que cleui des algorithmes parallèles. Et à part le compilateur qui s'en occupe automatiquement, je ne veux pas avoir à m'en occuper personnellement vu la complexité des codes que j'affronte tous les jours.

Peut-être bien que l'ensemble des algorithmes vectorisables est très petit, mais dans une application multimédia, la majorité des calculs à faire sont des calculs vectorisables d'où la nécessité, comme tout le monde le sait, d'avoir une carte graphique (ne serait-ce que pour afficher les infos à l'écran). Intel l'avait bien compris en faisant le SSE sur un processeur qui est un processeur généraliste donc qui devrait être adapté pour des calculs qui se rencontrent le plus souvent.

Juste pour être sûr qu'on s'est bien compris : un moteur 3D software est actuellement implantable sur GPU.

oui mais tu ne peux pas tout faire... Certaines choses restent implémentable uniquement sur un processeur généraliste

Justement, les seuls trucs qui ne sont pas faisables (je dirais même plus, qui ne doivent pas être faits) sur GPUs peuvent se faire en parallèle sur CPU si on utilise les bons algorithmes de rendu. Ce n'est pas une limitation en soit mais presque un avantage (on répartit équitablement les charges sur les deux processeurs). Le seul soucis peut venir du bus de communication et c'est là où des améliorations devront être faites à l'avenir.

la guerre entre proGPU et proCPU a commencer il y pas mal de temps déjà... celui qui gagnera c'est celui qui sera utilisé : si larabee malgré ces défauts devient généraliste, les développeurs vont arrêter de ce prendre la tête avec plusieurs langages, plusieurs bibliothèques... c'est tentant de faire que du C++, mais en plus de ca y a plein d'algo qu'on peut pas faire sur les GPU.
Enfin c'est de moins en moins vrais...

Je suis tout à fait d'accord avec toi. Le problème du Larabee c'est que ça prendra autant de place qu'un GPU. Que ça sortira au plus tôt en 2010 et que ça aura des perfs pour du rendu 3D d'une carte graphique de 2006 (au mieux 2008) et que ça sera cher et que ça pompera 600 à 700W. Voilà le soucis. C'est cher, ça bouffe de l'énergie... Et le seul truc en plus : on pourra coder plus facilement certains algos. Et comme tout le monde le sait, c'est le JV qui fait la loi sur le GPU et les développeurs sur JV sont vraiment très bons. Je ne pense pas qu'ils accepteront de telles perfs et un tel coût en sachant qu'ils peuvent faire la même chose sur GPU (architecture qu'ils connaissent mieux, n'oublions pas que ce sont des spécialistes du GPU qui font le JV) en se prenant à peine un peu plus la tête et en ayant des gains en perfs bien plus importants. Ca va faire comme les PPU qui ont été bouffés par NVIDIA (bien sûr tout ceci est très subjectif et n'est que mon avis personnel sur la situation ).