Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

[MàJ] NVIDIA publie la version finale de CUDA 6

Moins de travail, c'est toujours bon à prendre

[MàJ] NVIDIA publie la version finale de CUDA 6

Le 15 avril 2014 à 17h10

NVIDIA vient d'annoncer officiellement la sixième version de CUDA, qui arrivera début 2014. Au programme, on note l'arrivée de la gestion unifiée de la mémoire, promise de longue date et qui permettra de simplifier le travail des développeurs. Mais quelques autres nouveautés sont aussi au programme.

NVIDIA CUDA 6 NVIDIA CUDA 6

 

« La plateforme CUDA 6 rend la programmation parallèle bien plus simple qu'auparavant, permettant aux développeurs de réduire de manière importante les efforts et le temps passé afin d'accélérer leurs applications grâce aux GPU ». C'est avec cette promesse que commence l'annonce officielle de la nouvelle version de CUDA qui n'arrivera que début 2014.

 

NVIDIA a profité de la fin de la conférence APU13 d'AMD pour faire cette annonce, et devrait en dire plus lors de la SC13 qui va ouvrir ses portes. La grande avancée de CUDA 6 est l'arrivée de la gestion unifiée de la mémoire, qui permet d'aller plus loin que ce qui était permis depuis CUDA 4.0 à ce niveau. En effet, désormais on évite au développeur de gérer l'échange des données entre la mémoire du CPU et celle du GPU pour avoir accès aux données. Celui-ci a toujours lieu, mais il est pris en charge automatiquement. 

 

Une façon différente de faire d'AMD avec hUMA puisque cet échange n'est dans ce cas pas nécessaire, ce qui devrait constituer un avantage en terme de performances au niveau des APU. Il sera intéressant de voir ce qu'il en sera une fois que la prochaine architecture Maxwell sera sur le marché.

 

NVIDIA GTC 2013

 

De nouvelles bibliothèques BLAS et FFT optimisées pour le multi-GPU capables de s'adapter à la présence d'un maximum de huit GPU. Elles seront automatiquement utilisées à la place des versions optimisées pour les CPU lorsque cela sera possible. Les développeurs qui veulent un accès préliminaires peuvent le demander par ici. De nombreux outils de développement seront mis à jour suite à l'arrivée de CUDA 6 qui devrait être dévoilé de manière plus complète dans les jours à venir.

Commentaires (18)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







Adakite a écrit :



mais si je comprends bien, de toute manière il faudra attendre Maxwell pour bénéficier matériellement de ce partage mémoire. Je me trompe ?





Maxwell ce sera autre chose, d’où la dénomination différente d’ailleurs. Là de toutes façons ce n’est pas vraiment une nouveauté dans la pratique, juste une facilité pour le développeur au niveau du code (d’ou la phrase marketing bingo du début)


votre avatar

serait-ce un teaser des GTX 800 ? <img data-src=" />

votre avatar

Si c’est bien fait, ça pourrait faire baisser dramatiquement la consommation mémoire de certaines applis qui doivent maintenir de multiples copies de mêmes blocs de données… Amélioration donc des moteurs de rendu et des pipelines de compression vidéo.

votre avatar

depuis le temps que nvidia nous rabat les oreilles avec la mémoire unifié il était temps qu’ils le sorte avant de passer à la concurrence. <img data-src=" />

votre avatar

je suis pas un pro de la prog… mais une simple classe en CPP qui FAI passer les données de la RAM a la VRAM en vérifiant la synchro ce n’est pas bon ?




  • qui alloue que la ou c’est nécessaire

  • qui copie que quand c’est nécessaire

    etc etc



    je suppute mais c’est pas en gros ça mais directement intégré ?

votre avatar

pardon pour les fautes . Version mobile …

votre avatar



La plateforme CUDA 6 rend la programmation parallèle bien plus simple qu’auparavant, permettant aux développeurs de réduire de manière importante les efforts et le temps passé afin d’accélérer leurs applications grâce aux GPU





Pus simple je veux bien croire mais est ce que c’est vraiment utile ?



Quelqu’un qui cherche a utiliser son gpu, c’est pour les perfs et si y’a un truc qui est lent dans cette histoire : c’est la liaison pcie. Donc j’espère juste que ce sera pas du tout automatique et qu’on pourra toujours gérer ça explicitement si on veut.









Birto a écrit :



je suis pas un pro de la prog… mais une simple classe en CPP qui FAI passer les données de la RAM a la VRAM en vérifiant la synchro ce n’est pas bon ?




  • qui alloue que la ou c’est nécessaire

  • qui copie que quand c’est nécessaire

    etc etc



    je suppute mais c’est pas en gros ça mais directement intégré ?







    c’est intégré dans le compilo, y’aura peut-être un attribut pour le lui indiquer tout de même.

    Enfin là le support, il doit être un peu matériel et passer par les fonctionnalités d’addressage et de mémoire virtuelle du pcie je suppose. SI c’est ça tout ce qui est copie et transfert sont gérer le système mémoire du gpu.


votre avatar







dam1605 a écrit :



Pus simple je veux bien croire mais est ce que c’est vraiment utile ?



Quelqu’un qui cherche a utiliser son gpu, c’est pour les perfs et si y’a un truc qui est lent dans cette histoire : c’est la liaison pcie. Donc j’espère juste que ce sera pas du tout automatique et qu’on pourra toujours gérer ça explicitement si on veut.







Ça permettra de porter directement des bouts de codes sans rien faire. Après si on recherche une énorme accélération, il faudra toujours passer par une optimisation fine des transferts mémoires. Je comprends que c’est juste une facilité de développement, et non un gain en perf. Le hardware, reste le hardware.



Mais bon allouer sur le GPU et gerer les transferts c’est pas le plus compliqué chez CUDA.


votre avatar







lain a écrit :



serait-ce un teaser des GTX 800 ? <img data-src=" />







Au fait … quand est-ce que les Maxwell qualité filtre arrivent autrement qu’en 750 ?


votre avatar







luxian a écrit :



Au fait … quand est-ce que les Maxwell qualité filtre arrivent autrement qu’en 750 ?





Je sais pas <img data-src=" /> j’attend avec impatience leur nouvelle gestion de la VRAM (la VRAM c’est le goulot d’étranglement absolue sur GPU)…


votre avatar

Rassurez-vous je viens d’acquérir une GTX 770, donc la nouvelle gamme sortira forcément assez vite pour me dégoûter de pas avoir attendu un mois de plus.

votre avatar







Emralegna a écrit :



Rassurez-vous je viens d’acquérir une GTX 770, donc la nouvelle gamme sortira forcément assez vite pour me dégoûter de pas avoir attendu un mois de plus.





<img data-src=" /> Toi aussi tu sais que toute action de ta part déclenchera des foudres hostiles pour ridiculiser tes choix.











Pareil

<img data-src=" />


votre avatar







Emralegna a écrit :



Rassurez-vous je viens d’acquérir une GTX 770, donc la nouvelle gamme sortira forcément assez vite pour me dégoûter de pas avoir attendu un mois de plus.





<img data-src=" /> attention, il y a une nouvelle gamme dans 6 mois /breaking news <img data-src=" />



Clair que ça sert à rien d’attendre, faut prendre la carte qui a le meilleur rapport perf/prix à un moment donné! Et puis franchement, seules les cartes ultra HDG sont dépassées aussitôt.


votre avatar

Mouais, de toute façon CUDA est spécifique à NVidia et en 2014 ça n’a d’intérêt que pour ceux qui sont prisonniers de leur code en CUDA et ceux qui ont des contrats à gros sous avec NVidia. Aujourd’hui on utilise OpenCL, point barre, les API proprios vont crever comme elles le méritent.



A chaque fois c’est pareil de toute façon : douze vendeurs débarquent avec leurs solutions exclusives qu’il veulent imposer au reste du monde contre redevance à gros sous et deux ans plus tard ça finit avec un standard (et quand même des gros sous du fait de ces brevets logiciels inutiles de m….).











ragoutoutou a écrit :



Si c’est bien fait, ça pourrait faire baisser dramatiquement la consommation mémoire de certaines applis qui doivent maintenir de multiples copies de mêmes blocs de données… Amélioration donc des moteurs de rendu et des pipelines de compression vidéo.





Pas du tout, les données seront toujours copiées par le pilote. La haute latence du bus PCIe (en microsecondes) interdit tout travail direct et de toute façon les CPU seraient mauvais avec de la VRAM et les GPU mauvais avec de la RAM.









Birto a écrit :



je suis pas un pro de la prog… mais une simple classe en CPP qui FAI passer les données de la RAM a la VRAM en vérifiant la synchro ce n’est pas bon ?




  • qui alloue que la ou c’est nécessaire

  • qui copie que quand c’est nécessaire

    etc etc



    je suppute mais c’est pas en gros ça mais directement intégré ?





    Si c’est ça, directement intégré. La différence c’est que aujourd’hui les données à copier étaient fournies à l’initialisation du bidule (tu lançais un programme sur un GPU en lui filant en même temps les données à traiter) et que les résultats étaient recopiés à la fin dans l’autre sens. Donc il n’y avait de toute façon pas de mécanisme pour gérer manuellement ces transferts.


votre avatar



En effet, désormais on évite au développeur de gérer l’échange des données entre la mémoire du CPU et celle du GPU pour avoir accès aux données. Celui-ci a toujours lieu, mais il est pris en charge automatiquement.





C’est seulement une facilité pour le dev, ca n’améliore en rien les performances.



Et quand on voit le niveau de controle dont on a besoin pour faire un algo vraiment rapide, on retombera rapidement vers une gestion a la main des transferts mémoire.

Mais pour maquetter rapidement un truc, c’est cool.


votre avatar







Marvellou a écrit :



C’est seulement une facilité pour le dev, ca n’améliore en rien les performances.





Si. Imagine une classe matrice que l’on utiliserait avec deux multiplications enchaînées :

M1 = A * B

M2 = M1 * C



Entre les deux multiplications les données vont inutilement revenir au CPU et ce dernier devra à son tour les renvoyer pour les besoins de la seconde multiplication. Le seul moyen aujourd’hui d’éviter ça c’est de créer un code spécial pour enchaîner deux multiplications. Impossible de conserver l’encapsulation.


votre avatar



Les développeurs qui veulent un accès préliminaires peuvent le demander par ici.





mais si je comprends bien, de toute manière il faudra attendre Maxwell pour bénéficier matériellement de ce partage mémoire. Je me trompe ?



Du coup, je vois déjà moins l’intérêt de donner l’accès tant qu’aucun GPU Maxwell n’est sur le marché. Ca sera au passage intéressant de voir quelle politique Nvidia va avoir sur la question du FP64 des GM110 (je suppose que la nomenclature ne changera pas) parce que c’est quand même la déception sur la génération Kepler. Surtout que AMD avec sa 7970 propose quelque chose des très correct et ce même pour le grand public; même si la Titan reste sur ce point “encore” intéressante….mais chère la vache!

votre avatar







HarmattanBlow a écrit :



Si. Imagine une classe matrice que l’on utiliserait avec deux multiplications enchaînées :

M1 = A * B

M2 = M1 * C



Entre les deux multiplications les données vont inutilement revenir au CPU et ce dernier devra à son tour les renvoyer pour les besoins de la seconde multiplication. Le seul moyen aujourd’hui d’éviter ça c’est de créer un code spécial pour enchaîner deux multiplications. Impossible de conserver l’encapsulation.







On va pas rentrer dans le détail ici, mais si ta matrice M1 est calculée par sur le GPU, elle est allouée une fois pour toute sur le GPU, et restera dispo pour plusieurs kernels différents. Pas besoin de passer par le CPU. rien n’empêche de manipuler des pointeurs de mémoire GPU dans ton code CPU, et donc dans ta classe.


[MàJ] NVIDIA publie la version finale de CUDA 6

Fermer