Se connecter avec
S'enregistrer | Connectez-vous

CUDA 3.0 commence à se montrer

Par - Source: PCInpact | B 7 commentaires

La prochaine version du SDK CUDA, la version 3.0, commence à se montrer. Disponible uniquement pour le moment chez quelques développeurs (qui ont reçu un e-mail contenant les informations pour le télécharger), ce SDK améliore le support de l'OpenCL et prend en charge les cartes Fermi.

Dans les améliorations de la technologie elle-même, notons :

• Gestion de la double précision
• Interopérabilité entre OpenCL et OpenGL pour une meilleure performance d'affichage
• Récupération de la Compute Capability via cl_nv_device_attribute_query
• Possibilité de contrôler les optimisations de compilations via cl_nv_compiler_options
• Support des images OpenCL pour un filtrage meilleur et plus rapide
• Support des opérations atomiques 32 bits
• Support des Bytes Addressable Stores
• Support de la révision 1.0.48 des spécifications OpenCL de Khronos
• Support des headers OpenCL de Khronos du 1/11/2009

Dans le SDK et le ToolKit, on retrouve les nouveautés suivantes :

• Interopérabilité entre le pilote CUDA et le Runtime buffer, ce qui permet aux applications utilisant l'API des pilotes CUDA d'utiliser également utiliser des librairies du Runtime CUDA C
• Une nouvelle version du Runtime CUDA C (CUDART) pour un débogage en mode émulation
• Support C++ (héritage des classes et templates) afin de faciliter la vie du développeur
• Nouvelle API unifiée pour Direct3D et OpenGL avec permettant :
- L'interopérabilité des textures OpenGL
- L'interopérabilité de Direct3D11
• Support du débogage matériel de cuda-gdb pour ceux qui utilisent l'API du pilote CUDA
• Nouvel outil de vérification de la mémoire disponible au sein de cuda-gdb et en tant qu'outil à part entière
• Les versions des librairies du CUDA Toolkit sont désormais indiquées, permettant aux applications d'exploiter une version précise ou de supporter plusieurs versions
• Les noyaux C/C++ de CUDA sont désormais compilés en respectant le format ELF

Pour les futures cartes Fermi, annoncées mais pas encore disponibles, on retrouve :

• Le support natif du 64 bits
• Le Multiply Copy Engine
• La gestion des erreurs ECC
• Le Concurrent Kernel Execution
• Le débogage matériel de Fermi via cuda-gdb

Toutes ces nouveautés devraient être disponibles publiquement d'ici quelques semaines, mais des développeurs actifs ont donc déjà accès à ces nouveautés. Rappelons que la technologie CUDA est pour le moment disponible en version 2.3, sous Linux, Windows et Mac OS X, et qu'elle permet d'utiliser des outils comme C pour CUDA, Fortran pour CUDA, etc., à travers les processeurs de flux des cartes GeForce (depuis la 8e génération), dont NVIDIA a récemment changé le nom en core CUDA.

Commentaires
Interroger un expert

Votre question aux experts de la catégorie Les news : vos réactions du forum

Exemple : Android, ordinateur portable, usb, disque dur

Cette page n'accepte plus de commentaires
  • delphi_jb , 9 novembre 2009 17:45
    nvidia amerliore son api propriétaire ainsi que la comptabilité avec l'openCL...

    moi ce qui m'interesse, c'est que Fermi ayant une vrai architecture memoire (cache L1, L2), on a acces au C++ maintenant.

    mais alors la ou ca blesse mechant, c'est le support des flotant en 64 bits. 2 cycles pour traiter des opération avec des floats 64 bits, comme sur un CPU !!


    mais que va donner le graphisme ?
  • Serious Gilles , 9 novembre 2009 19:02
    @delphi_jb: oui ça serait pas mal que nvidia en dise plus pour les devs...

    Accès au C++, oui mais comment ? Pour moi il y aura tjrs un model de data parallelisme à respecter (threadgroup, dispatch etc).
    Et je pense pas que fermi soit capable d'executer n'importe quelle fonction c++ (genre qui tire sur iostream) vu que fermi pourra pas faire d'IO.
  • delphi_jb , 9 novembre 2009 19:55
    non evidement il est clair que fermi doit se conformer au maximum potentiel de son architecture. mais je crois que pour les IO, si fermi ne les prend pas en charge, ca switchera automatiquement sur le CPU. enfin, c'est une supposition... ;-)

    Citation :
    Accès au C++, oui mais comment ? Pour moi il y aura tjrs un model de data parallelisme à respecter (threadgroup, dispatch etc).

    c'est clair que Nvidia aurait pu nous mettre une liste plus complete sur le sujet. Mais de prime abord, pour créer une application orienté compression video (par exemple), on aura bien a disposition une suite d'instruction fonctionnel, basé sans doute sur des modele probablement mais bon, ca c'est le parralélisme d'execution des thread qui veut ca.. ;-)
  • Afficher les 7 commentaires.
  • Serious Gilles , 9 novembre 2009 21:40
    delphi_jbc'est clair que Nvidia aurait pu nous mettre une liste plus complete sur le sujet.


    A priori d'après B3D, fermi n'a pas de tesselator, est-ce mandatory pour dx11 ? (car si tu regardes l'enum D3D11_FEATURE ça n'y figure pas, alors que le support des doubles, du MT oui, qui eux sont optionnels). Bref une inconnue à ce niveau.
    Tout comme les rasterizers/ROPs, on ne sait pas si il y aura du hw dédié (à mon avis oui mais bon).

    Du côté d'intel c'est guerre mieux, j'ai vu des rumeurs comme quoi LRBni n'est plus d'actualité, mais ça serait plutôt x86+AVX.
  • delphi_jb , 9 novembre 2009 22:25
    Citation :
    A priori d'après B3D, fermi n'a pas de tesselator, est-ce mandatory pour dx11 ? (car si tu regardes l'enum D3D11_FEATURE ça n'y figure pas, alors que le support des doubles, du MT oui, qui eux sont optionnels). Bref une inconnue à ce niveau.


    Ati avait une unité de tesslation depuis je crois les serie 2000 ou 3000 mais qui est resté inexploité. Je dirai que ce n'est pas obligatoire. Je crois que la tesselation passera par les unités programmable. enfin, j'ai pas été farfouiller le web sur le sujet mais c'est une impression. En tout cas, si la feature de dx11 n'en a pas besoin, alors je vois pas pourquoi il en faudrai absolument une quand on sait qu'on a une carte graphique avec un potentiel de calcul sur les flotant 32 bits de 3Tflops, on peut bien en dédier un peu pour la tesselation.

    Qui plus est, la seul triche en 3D qui permet d'avoir un relief presque aussi beau que du displacement mapping, c'est le parralax + ambian occlusion.
    Seulement, ce dernier est plus lourd que le displacement mapping ! +/- moitié moins...)

    Citation :
    Du côté d'intel c'est guerre mieux, j'ai vu des rumeurs comme quoi LRBni n'est plus d'actualité, mais ça serait plutôt x86+AVX.


    en fait, l'avx est "serait" plus performant que les instruction larrabee sur les instruction de vectorisation (en autre en doublant la taille des registre de 128 a 256 bits) et en plus, contiendrai des intructions sur 4 opérandes (faudra qu'on m'explique pourquoi...)



    enfin, la programmation pure n'est pas vraiment de mon ressort mais je crois qu'INTEL s'est laissé surprendre par nvidia et sa carte, il faut le dire, dédié coprocesseur plutot que graphique. (en attendant des news...)

    a force de dévelloper de nouvelle instruction, d'appliquer ceux ci, de se rendre compte que finalement, le produit visera le milieu de game,.... Larrabee n'en finira pas de rester dans leur carton.

    parceuqe l'avantage de ce dernier par rapport a fermi, en gpgpu, est l'apport natif du X86.


    wait and see...
  • Serious Gilles , 9 novembre 2009 22:49
    delphi_jbJe crois que la tesselation passera par les unités programmable.

    Ben oui pour le hull shader et le domain shader, ça c'est sur que c'est géré par des unités programmables (vu que c'est du shader). Mais t'as aussi une partie qui est fixed et qui est sensée être implémentée en hard ! (j'ai vu ça dans des specs techniques ms, mais impossible de les retrouver...).

    delphi_jb
    en fait, l'avx est "serait" plus performant que les instruction larrabee sur les instruction de vectorisation (en autre en doublant la taille des registre de 128 a 256 bits) et en plus, contiendrai des intructions sur 4 opérandes (faudra qu'on m'explique pourquoi...)enfin, la programmation pure n'est pas vraiment de mon ressort mais je crois qu'INTEL s'est laissé surprendre par nvidia et sa carte, il faut le dire, dédié coprocesseur plutot que graphique. (en attendant des news...)a force de dévelloper de nouvelle instruction, d'appliquer ceux ci, de se rendre compte que finalement, le produit visera le milieu de game,.... Larrabee n'en finira pas de rester dans leur carton.parceuqe l'avantage de ce dernier par rapport a fermi, en gpgpu, est l'apport natif du X86.wait and see...


    le x86 je vois pas trop l'intérêt pour les devs 3D. Sauf si intel désire faire reconnaitre les 24/32 (?) cores x86 de larrabee par l'OS, et donc offloader des process du système (NT, ou unix) dessus, tels des cores x86 normaux. Reste que pour que ça soit efficace il faudrait que Larrabee soit sur la même puce que le CPU (donc une sorte de fusion), partage le même espace d'adressage etc etc.

    Et ça on y est pas encore. N'empeche que ça pourrait être efficace d'avoir un systeme avec quelques fat cores x86 (bcp de cache, OOO) pour tout ce qui est serial et le legacy, et une myriade de petits cores x86 simple pour tout ce qui est massivement parallele.

    A mon avis c'est vers ce quoi se dirigent amd, intel et nvidia.
  • delphi_jb , 10 novembre 2009 10:38
    Citation :
    le x86 je vois pas trop l'intérêt pour les devs 3D


    c'est ca le truc justement, c'est que larrabee a été vanté plus comme coprocesseur massif que comme carte 3d. il y aura plein de perf pour les application de calcul mais la partie graphique sera principalement... émulé !

    c'est clair qu'un jeu d'instruction x86 ne sert a rien pour dévelloper 3d mais ca pourrait apporter un plus pour des moteur indépendant du style physique et/ou qui sait, des moteurs IA indépendant qui interragissent avec les jeux.


    voila pour moi le principal atout du X86... :-)