Discussion :

[themei]

Je sais bien, mais si la mémoire est sur la carte c'est pour des raisons de performances. Si le GPU avait un emplacement du style CPU et utilisait donc la ram, ça poserais problème. D'ailleurs, il n'y a que sur les cartes bas de gamme qu'on fait appel à la RAM. Sur les autres cartes, on a de la mémoire dédiée en grosse quantitée et très rapide.



C'est vrai que c'est impressionnant pour un CPU. Mais en puissance brute pour une utilisation massivement parallèle, il n'y a rien d'impressionant par rapport aux cartes graphiques. Une petite radeon 4850 à 80€ fournit 1 TFlop en simple précision.

Faut pas oublier le moteur video, ça le CPU le remplace mais vive la consommation. Bref on pourrai dire qu'un jour les CPU aurait une unité dédié ou quoi mais bon c'est partir dans une spirale infernale a ce rythme là.

Et encore pire, tout ce qui est boulot du ROP, tout ce qui est FSAA/Filtrage & co, c'est ultra rapide sur un GPU où tout est cable, et ultra lent sur un CPU.

Au final si c'est pour devoir integrer plein de morceaux du GPU dans le CPU, et fait une puce de 5 milliard de transistor qui fait 10cm² ca sert a rien. :o

[supertonic]

Effectivement, celà paraît difficile de se passer d'un proc spécialisé aujourd'hui pour la 3D en temps réel. Mais je prie pour que ce jour arrive enfin. Cela permettrai vraiment de libérer la création (en se passant d'api si on le souhaite). Et puis imaginer, ajout d'un 2ieme cpu qui doublerai les perfs

[slylafone]

Je sais bien, mais si la mémoire est sur la carte c'est pour des raisons de performances. Si le GPU avait un emplacement du style CPU et utilisait donc la ram, ça poserais problème. D'ailleurs, il n'y a que sur les cartes bas de gamme qu'on fait appel à la RAM. Sur les autres cartes, on a de la mémoire dédiée en grosse quantitée et très rapide.

La Xbox 360 dispose de 512Mo de RAM partagée (CPU / GPU). Ça n'a pas l'air de poser de problème...

[B.AF]

Pour avoir testé Cuda entre autres, ce qui pose pb n'est pas la taille, mais la bande passante. Cuda est sur beaucoup de méthodes numériques intéressant et très puissant, mais il y a un goulet d'étranglement sur les données à transférer.

De même, aujourd'hui, les processeurs sont peut être multi-core, mais combien de softs en tire avantage ?

Hormis le dev en c++ et pas systèmatiquement, ce sont des pb de développement nouvelles, et très basses techniquement.

Et pourtant, cela peut changer l'informatique demain.

Dois-je prendre un service cloud et augmenter mes cycles ?
Dois-je prendre un grid computing ?
Dois-je prendre du parallel computing ?
Dois-je prendre une api et des GPU ?

Ce sont de beaux pb d'architecture à terme, mais au moins un peu d'fun, ca fera pas de mal!

[yamashi]

Cuda est sur beaucoup de méthodes numériques intéressant et très puissant, mais il y a un goulet d'étranglement sur les données à transférer.

C'est une erreur de conception de ta part dans ce cas.
L'idée de rassembler CPU et GPU en une unité est infaisable, l'architecture diverge bien trop de plus l'utilité elle aussi est trop différente pour trouver un juste milieu.
Pour ceux qui ont étudiés le fonctionnement d'un CPU et le fonctionnement du GPU vous savez que la gestion de la mémoire est tellement différente qu'il est quasi impossible de pouvoir faire une sorte d'hybride.
De même un CPU est conçu pour avoir une puissance de calcul brute sur une suite d'opération alors que le GPU est conçu pour avoir une puissance de calcul brute sur des opérations parallèle ce qui implique une gestion très différente des unité de calcul.
Si vous parlez des core CELL il faut parler des Tesla qui eux montent a 400GFlops en double précision, et pas des cartes grand publiques (et oui qui a un CELL dans son PC ici ? ).
Puis n'oublions pas le fort potentiel qu'ont les GPU a bosser ensemble, si on met 2 Tesla, on obtient 800Gflops, sans perte de puissance et ceux jusqu'à des dizaines voir centaines de GPU (qui sont au passage de plus en plus utilisés pour les cluster HPC, gains de place, moins de consommation, généralement plus simple a utiliser) .

Pour l'accélération via GPU, ça utilise les shader, il n'y a pas d'unité dédiée à la physique sur les cartes graphiques.

Biensur que non... l'accélération PhysX sur GPU est basée sur CUDA...

Le calcul de gravité est il inclus dans le PPU?

C'est quoi cette question ? v = a.t , y a pas besoin de faire une unité spécial pour calculer ca et encore moins besoin d'un moteur comme PhysX pour faire des calculs si peu couteux... Abstiens toi de poster ce genre de questions...

[B.AF]

C'est une erreur de conception de ta part dans ce cas...

Je te parle de l'utiliser pour faire autre chose que de la 3D et du jeu.

Je trouve et y compris ta derniére phrase que tu as une façon un peu abrupte de t'adresser.

Heureusement que beaucoup ont fait l'impossible, sinon, on serait probablement même pas en train de frotter des silex...

[yamashi]

Je te parle de l'utiliser pour faire autre chose que de la 3D et du jeu.

Oui merci, c'est mon boulot au passage...
Il faudra attendre CUDA 3.0 pour les block "cohérent" qui permettront de ne plus avoir a vraiment se soucier justement du bottleneck dont tu parles.
Mais jusqu'ici j'ai travailler sur plusieurs gros projet sous CUDA et on a jamais eu de problème avec la latence, il suffit d'avoir un bon rapport arithmetique/memoire.
C'est sur que si tu envoie d'énorme matrices pour faire une addition, tu vas pas aller loin... (exemple extrême bien sur)

[ac_wingless]

Yamashi, je trouve aussi que vous abordez le sujet de façon trop rapide. Aujourd'hui, il y a des soucis évidents de passage de données au travers de PCIe par rapport à un environnement de travail ne mettant pas en œuvre de processeurs graphiques (ce qui est le sujet). Il ne faut pas les nier, et dire que "C'est une erreur de conception de ta part dans ce cas." est au mieux désobligeant: on a des téraflops contre des gigabits/s, il faut donc biaiser la conception pour en tenir compte, et c'est précisément un frein à l'adoption généralisée des GPU. Je rappelle que c'est bien l'objet de cette discussion ("Les processeurs graphiques sont-ils voués à disparaître ?"), et donc la remarque de B.AF me parait parfaitement pertinente.

Pour en revenir au sujet, nous utilisons des GPUs depuis 2005 (GeForce 7) dans le domaine de l'embarqué, pour des tâches n'ayant aucun rapport avec les jeux. Nous avons du bâtir un tissu de compétences pour utiliser ces bestioles au mieux, et ce n'est pas simple. Pire pour nous que la faible puissance en double précision, les modèles de programmation sont extrêmement bridés, même avec DirectX 10. L'utilisation de CUDA permet de simplifier un certain nombre de choses, mais CUDA est un peu le Python des GPUs: pour vraiment essorer la bête, il faut malheureusement des shaders, et alors les efforts de programmation pour des tâches généralistes sont presque ridicules par rapport à la complexité demandée.

Après ces quelques années d'utilisation intense des GPUs, mon espoir est que se dessine un sous-ensemble de besoins plus généralistes que les applications 3D, et que les GPUs le prennent en compte dans de futures versions. DirectX11 est un nouveau pas dans la bonne direction, après DirectX10 qui permettait déjà grâce aux geometry shaders de faire circuler des calculs dans le GPU sans passer par des décodages de render targets (modèle DX9). J'avais perdu tout espoir dans OpenGL, mais depuis quelques temps ils semblent mettre les bouchées doubles pour se rattraper, donc à surveiller aussi. Je n'ai cependant pas d'expérience avec OpenGL 3.0 ou OpenCL.

Je pense que la direction prise par Larrabee est moins facile à adopter par la communauté. J'ai du mal à imaginer comment un modèle de programmation de type C++ (ou Java ou autre, par opposition à la programmation "orientée fragment") pourrait exploiter à fond ces processeurs. On peut dire qu'Intel est conscient du défi, et se donne des moyens. J'ai eu l'occasion de discuter de vive voix avec un développeur Intel en charge du futur de la TBB (en gros, c'est l'effort d'Intel pour populariser les "many-cores" par opposition aux "multi-cores"), et les pistes qu'ils suivent sont très intéressantes. Malheureusement, si vous pensiez que C++ était compliqué, attendez de voir la TBB 3.0...

Pour résumer, je pense que les GPUs resteront "orientés fragment" (pour simplifier: très nombreuses tâches parallèles étanches avec synchronisation brutale par durée d'exécution fixe), et qu'ils seront plus généralistes. Une fois le goulet d'étranglement PCIe 2.0 résolu, je vois bien des API comme OpenCL et DirectCompute les rendre utilisables pour tous les programmeurs.

[moldavi]

Bonjour.

Ce sont deux technologies différentes. D'un côté on cherche l'optimisation d'un seul coeur, de l'autre on fait fonctionner 126 coeurs en parallèle. Chacune de ces technologies a été développé par rapport à des exigences différentes.

Il me semble facile de dire qu'il suffirait à Intel de mettre 126 pentiums en parallèle pour écraser les GPUs next generation... Il ne l'ont pas fait, deux technologies, deux différences, deux expériences.

L'avenir est à la parallélisation (mon avis). Le premier qui sort l'architecture Tip-Top pour les développeurs gagne. Je ne suis pas visionnaire alors "Wait and See".

[deadalnix]

Il ne l'ont pas fait, deux technologies, deux différences, deux expériences.

Ils l'ont bien fait. Ça s'appelait larabee. Ça consommait une demi centrale nucléaire pour afficher la même chose qu'avec une autre carte, tout en coutant les yeux de la tête à produire.

Malgré sont grand potentiel, comme nous l'a bien montré intel, ils ont décidé d'annuler le machin. Sans doute par peur d'écraser le marché . . .

[moldavi]

Bonjour.

Les avis sont mitigés à propos de "Larabee".

[deadalnix]

En fait mitigé, c'est bien faible comme mot. Plus personne n'y croit, même pas intel, qui a arrêté de nous bassiner avec son raytracing de la mort à toutes les occasion.