Le NVIDIA GT300 supportera le C++ nativement
Au lieu de quelques extensions au C.

Le , par Bakura, Rédacteur
Comme vous le savez, le mois de septembre a vu l'apparition de la nouvelle carte d'AMD, la Radeon HD5870. La plupart des sites spécialisés l'ont déjà testé, et malgré les remarques de certains qui étaient déçus des performances (notamment sur Clubic.com), je trouve que cette carte est vraiment performante. Grosso modo, elle fait jeu égal avec la HD4870X2 alors qu'il s'agit d'une carte mono-GPU. Les performances ont donc doublées d'une génération à l'autre, ce qui est vraiment pas mal, je trouve. En attendant, je prédis que la carte à succès sera sans nul doute la HD 5850, comme c'était le cas sur la génération précédente.

Reste à connaître la réponse de NVIDIA à AMD, en l'occurrence le GT300. Il semble que le caméléon ait suivi la stratégie de la génération précédente, en sortant un GPU monstrueux mais qui va encore une fois coûter bien plus cher que l'équivalent d'AMD. J'avoue ne pas comprendre exactement cette stratégie. Ma Radeon HD3870 fait un boulot admirable, même sur les jeux actuels, je ne vois pas dans quels cas quelqu'un pourrait être tenté à débourser beaucoup plus pour une GT300 alors que la HD5850 offrira des performances excellentes !

Tout ça pour dire que quelques informations ont commencées à filtrées concernant le GT300, et c'est particulièrement intéressant, puisque visiblement, le GT300 supportera nativement... le C++ !

Fermi architecture natively supports C [CUDA], C++, DirectCompute, DirectX 11, Fortran, OpenCL, OpenGL 3.1 and OpenGL 3.2. Now, you’ve read that correctly – Fermi comes with a support for native execution of C++. For the first time in history, a GPU can run C++ code with no major issues or performance penalties and when you add Fortran or C to that, it is easy to see that GPGPU-wise, NVIDIA did a huge job.


Reste à savoir dans quelles proportions ce "support" fonctionnera. Sera t-il possible d'écrire des classes, des boucles... et faire en sorte que tout soit exécuté directement sur le GPU ?

Dans tous les cas, si cela s'avère vrai, on peut se demander quel peut-être l'avenir d'OpenCL et CUDA ? Qu'en pensez-vous ?

EDIT : source http://www.nvidia.com/content/PDF/fe...Whitepaper.pdf


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


 Poster une réponse

Avatar de SkYsO SkYsO - Membre régulier http://www.developpez.com
le 30/09/2009 à 16:08
Hummm ok !
Merci pour toutes ces précisions.

je pense que c'est très intéressant mais pas encore accessible pour moi tout ça. En tout cas je suis content d'avoir pu en discuter un peu ^^
Avatar de ac_wingless ac_wingless - Membre confirmé http://www.developpez.com
le 30/09/2009 à 16:15
Parfaitement bien résumé Bakura

Une petite subtilité avec DX10 qui a changé quand même pas mal de choses pour le GPGPU: au lieu du mode de programmation DX9 (exposé par Bakura), on peut utiliser dans DX10 des "stream outputs" permettant de faire circuler de façon arbitraire des données dans des unités flottantes non seulement totalement à l'intérieur du GPU (ce qui évite le goulet d'étranglement PCIe), mais aussi sans passer par des textures (ce qui permet de travailler directement sur des structures bien plus générales que ce qui nous est imposé par les formats de pixels). Par contre, les Geometry Shaders (ou "GS", qui sont nécessaires à l'utilisation des stream outputs) ont tout un tas de contraintes. Ces contraintes sont paradoxalement plus gênantes pour les applications graphiques que pour les applications générales, ce qui fait que les utilisateurs les plus agressifs des GS sont dans le monde du GPGPU. Malgré tout, les GS restent "orientés fragments", même si on se place cette fois directement au niveau intéressant en GPGPU, à savoir des vertex (définissables de façon très souple et donc bien adaptés à des données arbitraires nécessaires en GPGPU), et non pas au niveau des pixels comme avec le modèle DX9.

Je suis impatient d'examiner ce que NVidia mijote. Où se trouve la découpe SIMD/MIMD? (j'imagine qu'à l'intérieur d'un même "shader cluster" on est en SIMD... ou non?). Si on parle de compilation C++ directement en instructions GPU, comment la seule bibliothèque C++ véritablement innovatrice pour le HPC many-cores, à savoir TBB, sera-t-elle supportée par Intel sur ces GT300, puisque cela en ferait alors un projet très dangereux pour Larrabee?
Avatar de Bakura Bakura - Rédacteur http://www.developpez.com
le 30/09/2009 à 16:59
Je suis impatient d'examiner ce que NVidia mijote. Où se trouve la découpe SIMD/MIMD? (j'imagine qu'à l'intérieur d'un même "shader cluster" on est en SIMD... ou non?). Si on parle de compilation C++ directement en instructions GPU, comment la seule bibliothèque C++ véritablement innovatrice pour le HPC many-cores, à savoir TBB, sera-t-elle supportée par Intel sur ces GT300, puisque cela en ferait alors un projet très dangereux pour Larrabee?

Oui, de toute façon Larrabee j'y crois moyen... Il va avoir le cul entre deux chaises. Le raytracing pourrait en tirer parti mais j'ai l'impression qu'il y a beaucoup de recherches sur le raytracing sur GPU conventionnels et qu'on devrait arriver à quelque chose de bien dans ce domaine.

J'y connais pas grand chose en programmation GPU, et je n'ai aucune idée de la découpe SIMD/MIMD. A suivre ^^. En tout cas c'est très excitant. Et on se met à rêver que :

Code : Sélectionner tout
1
2
3
 
for (int i = 0 ; i != 5000 ; ++i) 
    Function ();
Soit automatiquement exécuté sur le GPU, sans aucune autre gestion de notre part .
Avatar de TanEk TanEk - Membre expérimenté http://www.developpez.com
le 01/10/2009 à 0:10
Quelle est la source de ton quote ?
Avatar de LittleWhite LittleWhite - Responsable 2D/3D/Jeux http://www.developpez.com
le 01/10/2009 à 0:28
Ce serait bien que tous les newsers du forum je veux dire, rajoute systématiquement la source du début de la conversation. Juste pour que l'on puisse se faire notre propre idée de la qualité de la source et aussi pour chercher un peu plus loin.

En tout cas, s'il il n'y a plus besoin de CUDA ou autre bibliothèque qui nécessite de l'apprentissage avec leur C++ ça serait cool. Attendons de voir la suite
Avatar de TanEk TanEk - Membre expérimenté http://www.developpez.com
le 01/10/2009 à 1:07
Citation Envoyé par LittleWhite  Voir le message
Ce serait bien que tous les newsers du forum je veux dire, rajoute systématiquement la source du début de la conversation. Juste pour que l'on puisse se faire notre propre idée de la qualité de la source et aussi pour chercher un peu plus loin.

En tout cas, s'il il n'y a plus besoin de CUDA ou autre bibliothèque qui nécessite de l'apprentissage avec leur C++ ça serait cool. Attendons de voir la suite

CUDA permet deja de faire presque tout le C++ il manque juste :
  • le polymorphisme
  • les appels recursifs


Je pense donc que ce sera simplement la prochaine version de CUDA qui enlevera simplement ces limites, il faudra tout de meme bien comprendre l'architecture des GPUs et les acces memoires, mais c'est normal, n'oublions pas que nous parlons de HPC.

D'ailleurs on peut lire sur le site de NVIDIA (http://www.nvidia.com/object/fermi_architecture.html):

THE NEXT GENERATION CUDA ARCHITECTURE, CODE NAMED FERMI
THE SOUL OF A SUPERCOMPUTER IN THE BODY OF A GPU

Avatar de deadalnix deadalnix - Membre chevronné http://www.developpez.com
le 01/10/2009 à 3:14
Citation Envoyé par TanEk  Voir le message
  • le polymorphisme
  • les appels recursifs

La metaprogramation (je suis un grand fan).
Les foncteurs (Je vois pas bien l'intérêt sur GPU mais sait-on jamais, quelqu'un de plus créatif que moi pourrait en faire usage).

Sinon, il y a des pointeurs de fonctions/fonctions virtuelles en CUDA ?

Ceci dit, pour revenir au sujet, ça semble prometteur ce truc la (bien plus que larabee et sa grande absence à l'IDF). Je suis impatient de voir les premiers usages qui en seront fait (sparse voxel octree ?).
Avatar de TanEk TanEk - Membre expérimenté http://www.developpez.com
le 01/10/2009 à 3:28
Citation Envoyé par deadalnix  Voir le message
La metaprogramation (je suis un grand fan).
Les foncteurs (Je vois pas bien l'intérêt sur GPU mais sait-on jamais, quelqu'un de plus créatif que moi pourrait en faire usage).

Sinon, il y a des pointeurs de fonctions/fonctions virtuelles en CUDA ?

J'aurai du etre plus general: aucun pointeur de fonction (donc pas de polymorphisme qui est base sur ca). Sinon t'es sur pour la meta-prog ? CUDA gerait bien les template il y a un bon petit moment (je les avais utilise en decembre).
Avatar de deadalnix deadalnix - Membre chevronné http://www.developpez.com
le 01/10/2009 à 4:31
Si tu les as utilisées, il doit bien les gérer. Je suis loin d'être un spécialiste CUDA, alors j'ai bien pu me tromper.

En tout cas, il manque pas mal de choses quand même
Avatar de deadalnix deadalnix - Membre chevronné http://www.developpez.com
le 01/10/2009 à 10:17
Avatar de ac_wingless ac_wingless - Membre confirmé http://www.developpez.com
le 01/10/2009 à 10:21
On commence à en savoir plus... en première lecture, pour le GPGPU qui m'intéresse professionnellement, la plus grosse nouveauté est la possibilité d'avoir plusieurs programmes (qu'ils appellent "kernels") exécutables en même temps, contrairement aux G80/GT200. C'est quelque chose qui ne gène pas en application graphiques, mais était particulièrement pénalisant pour les problèmes plus généraux.
Si on ajoute à ça l'ECC, le modèle mémoire uniforme, etc, c'est vraiment un truc sensationnel pour le HPC!! Reste à savoir si c'est bien pour les jeux... Moi, je m'en fous
Offres d'emploi IT
Ingénieur développement logiciel bas niveau (H/F)
PARROT SA - Ile de France - Paris (75000)
Traffic Manager
AMETIX - Ile de France - Paris (75000)
Ingénieur de développement Java/J2EE - H/F
Omniciel - Provence Alpes Côte d'Azur - Aubagne

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique 2D - 3D - Jeux : LittleWhite -