Le NVIDIA GT300 supportera le C++ nativement

Au lieu de quelques extensions au C.

Le 2009-09-30 14:15:06, 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

Discussion forum

15 commentaires

SkYsO
Membre régulier

Une question peut être un peu bête : OpenCl c'est quoi la différence avec OpenGL ?
Le fait que OpenCl soit plus proche de C ?
j'ai cru lire aussi que c'était fait par nvidia ?

désolé pour ces questions un peu noob peut être ^^

le 30/09/2009 à 15:04
Bakura
Rédacteur

nVidia fait CUDA. OpenCL est portable sur les cartes AMD et nVidia (mais je crois qu'une bonne partie est basée sur CUDA quand même).

La différence entre OpenGL et OpenCL est qu'OpenCL facilite le GPGPU. OpenGL s'utilise dans un contexte purement graphique. Tu peux faire du GPGPU avec OpenGL en passant par les shaders mais c'est peu pratique. OpenCL permet de développer des programmes proches du C exécutés sur ta carte graphique, directement dans ton application, sans la contrainte associée à l'utilisation des shaders.

le 30/09/2009 à 15:08
SkYsO
Membre régulier

hum ok merci, donc avec OpenCl on est plus "bas niveau" par rapport à la carte graphique. et donc plus performant ?

le 30/09/2009 à 15:28
Bakura
Rédacteur

Oui tu es un peu plus bas niveau. Pas spécialement plus performant, je crois même un peu moins (à confirmer), mais disons que tu gagnes vraiment en possibilités.

J'ai pas encore trop pu m'y plonger, mais la programmation GPU est assez compliqué, notamment au niveau de la gestion de la mémoire si tu veux des performances décentes.

Lorsque ces langages (OpenCL, CUDA) n'existaient pas, pour faire de la programmation GPGPU on procédait souvent ainsi :

- On envoyait les données dans tes textures.
- On exécutait des shaders qui effectuait des calculs pour chacune des données en dessinant un quad et en enregistrant les résultats dans d'autres textures.
- On récupérait les données écrites dans d'autres textures.

Comme tu peux le voir, texture/shader... tout ceci est très orienté "affichage graphique" et ce n'était pas forcément adapté aux types de calcul effectués. Avec ces langages, ce concept de shader/texture disparait au profit de calculs bien plus génériques, mais en contrepartie il revient au développeur de gérer correctement la mémoire, et ça c'est vraiment pas facile :/.

le 30/09/2009 à 15:34
SkYsO
Membre régulier

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 ^^

le 30/09/2009 à 16:08
ac_wingless
Membre confirmé

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?

le 30/09/2009 à 16:15
Bakura
Rédacteur
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 :
```
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 .
le 30/09/2009 à 16:59
TanEk
Membre expérimenté

Quelle est la source de ton quote ?

le 01/10/2009 à 0:10
LittleWhite
Responsable 2D/3D/Jeux

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

le 01/10/2009 à 0:28
TanEk
Membre expérimenté
Envoyé par LittleWhite

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_a...tecture.html):

THE NEXT GENERATION CUDA ARCHITECTURE, CODE NAMED FERMI
THE SOUL OF A SUPERCOMPUTER IN THE BODY OF A GPU
le 01/10/2009 à 1:07

Poster une réponse