Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bakura

23PARTAGES

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SkYsO
Membre régulier https://www.developpez.com
Le 30/09/2009 à 15:04
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 ^^
0  0 
Avatar de Bakura
Rédacteur https://www.developpez.com
Le 30/09/2009 à 15:08
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.
0  0 
Avatar de SkYsO
Membre régulier https://www.developpez.com
Le 30/09/2009 à 15:28
hum ok merci, donc avec OpenCl on est plus "bas niveau" par rapport à la carte graphique. et donc plus performant ?
0  0 
Avatar de Bakura
Rédacteur https://www.developpez.com
Le 30/09/2009 à 15:34
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 :/.
0  0 
Avatar de SkYsO
Membre régulier https://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 ^^
0  0 
Avatar de ac_wingless
Membre confirmé https://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?
0  0 
Avatar de Bakura
Rédacteur https://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 .
0  0 
Avatar de TanEk
Membre expérimenté https://www.developpez.com
Le 01/10/2009 à 0:10
Quelle est la source de ton quote ?
0  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://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
0  0 
Avatar de TanEk
Membre expérimenté https://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_a...tecture.html):


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