Les processeurs graphiques sont-ils voués à disparaître ?

Le , par Katleen Erna, Expert éminent sénior
Les processeurs graphiques sont-ils voués à disparaître ?

Selon Tim Sweeny, CEO fondateur de Epics Game (moteurs Unreal Tournament), le processeur graphique serait à inscrire sur la liste des espèces menacées.

La technologie OpenCL (Open Computing Language) est le résultat du mariage entre une API et un langage de programmation dérivé du C. Elle a été crée pour faciliter la programmation de l'intersection entre les CPU (de plus en plus parallèles) et les GPU (de plus en plus programmables).

Mais alors que la technologie Grand Central (qui simplifie le développement multithread) semble être bien absorbée, la technologie OpenCL pose, elle, de très gros problèmes de par l'éloignement géographique entre le processeur graphique (relégué à la terminaison d'un port PCI Express) et la mémoire centrale. Dans ce cas, le transfert mémoire des données nécessaire au calcul coûte énormément de temps et d'argent, et il faudra alors évaluer si le processeur est plus interessant en termes financiers par rapport à la parallélisation des calculs.

En effet, bien qu'il soit extrêmement puissant pour les calculs parallèles, le processeur graphique est en général assez mauvais pour les tests. Comment vaincre ce problème, d'autant plus lorsque l'on ne connaît pas la complexité des calculs qui seront à effectuer (ce qui est fréquent pour les projets de haute performance) ?

Si l'on se penche pour prendre le pouls de ce marché, on s'aperçoit que NVIDIA y est leader, talonné à distance respectueuse par Intel (dont la puissance des processeurs graphiques ne rivalise pas encore avec ceux du "maître" mais des innovations sont en route - implémentation de traitements graphiques et d'architectures superscalaires).

NVIDIA serait donc logiquement le premier à pâtir de cette situation qui pourrait malmener ce marché dans sa globalité.

Source : L'étude de Tim Sweeny

NVIDIA réussira-t-il à se sortir de cette mauvaise passe simplement en incorporant des processeurs graphiques dans des ARM ?

ATI se plaçant juste après NVIDIA en terme de performances, et appartenement à AMD qui serait en mesure d'instaurer un traitement graphique dans ses processeurs, pourrait-il doubler NVIDIA et lui prendre sa place de leader ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de supertonic supertonic - Membre habitué http://www.developpez.com
le 14/09/2009 à 16:13
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
Avatar de slylafone slylafone - Membre habitué http://www.developpez.com
le 15/09/2009 à 13:28
Citation Envoyé par Isukthar  Voir le message
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...
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 15/09/2009 à 17:27
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!
Avatar de yamashi yamashi - Membre habitué http://www.developpez.com
le 16/09/2009 à 19:22
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...
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 16/09/2009 à 21:25
Citation Envoyé par yamashi  Voir le message
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...
Avatar de yamashi yamashi - Membre habitué http://www.developpez.com
le 16/09/2009 à 22:19
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)
Avatar de ac_wingless ac_wingless - Membre confirmé http://www.developpez.com
le 24/09/2009 à 11:54
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.
Avatar de moldavi moldavi - Membre émérite http://www.developpez.com
le 22/01/2010 à 22:05
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".
Avatar de deadalnix deadalnix - Membre chevronné http://www.developpez.com
le 22/01/2010 à 23:10
Citation Envoyé par moldavi  Voir le message
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é . . .
Avatar de moldavi moldavi - Membre émérite http://www.developpez.com
le 26/01/2010 à 12:53
Bonjour.

Les avis sont mitigés à propos de "Larabee".
Avatar de deadalnix deadalnix - Membre chevronné http://www.developpez.com
le 26/01/2010 à 13:53
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.
Offres d'emploi IT
Développeur java j2ee H/F
Sogeti France - Ile de France - Paris (75000)
La DCC recherche un volontaire en solidarité internationale enseignant en informatique h/f
DCC (Délégation Catholique pour la Coopération) - Congo-Kinshasa - Kinshasa
Stage Conception fonctionnelle (H/F)
Atos Technology Services - Provence Alpes Côte d'Azur - Nice

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil