CUDA 3.0 commence à se montrer
Actu suivante
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.
Source : PCInpact
-
Actualité précédente
Microsoft : un café pour accéder à... -
Actualité suivante
Dell sort son Adamo XPS : le plus fin...
- Quel boitier pour une config calculs puissante mais silencieuse ? [Matériel]
- Raytracing VS Rastérisation : le dossier [Les news : vos réactions]
- Les Radeon 4870 et 4890 ont un défaut ? [Les news : vos réactions]
- Larrabee comme PPU [Les news : vos réactions]
- Photoshop (CUDA ou pas CUDA) ??? [Matériel]
Posez votre question sur ce sujet à la communauté !
Sujets relatifs sur le forum
Articles relatifs
-
Lors de l’utilisation du moteur de rendu logiciel, le processeur graphique de vos noeuds de rendu n’auront aucun effet sur les performances ou sur l’image finale. Vos pouvez utiliser un GPU intégré ou une carte graphique que vous auriez sous la main,...
-
Compute Shader Nous évoquions ce secret de polichinelle en conclusion de notre article sur CUDA : Microsoft n’allait pas laisser le marché du GPGPU lui échapper et propose donc son langage pour tirer parti de nos GPU pour autre chose que produire de...
-
Que pouvez-vous nous dire à propos de CUDA en tant qu’architecture par rapport au compilateur CUDA pour C ? CUDA est l’architecture hardware propre à NVIDIA pour l’informatique parallèle. Nous fournissons un ensemble d’outils pour programmer...
Les offres du moment
4 architectures quad-cores à 2,8 GHz
Phenom II X4 chez AMD, Core 2 Quad, Core i5 et Core i7 chez Intel : tous ces processeurs ont des caractéristiques, des architectures et des performances bien différentes, mais quelle hiérarchie se dégagerait-elle à fréquence identique ? Lire la suite
-
Construire un PC de jeu AMD équilibré
Votre carte graphique n'est-elle pas bridée par votre processeur ? Ou au contraire, votre PC ne bénéficierait-il pas d'un GPU plus haut de gamme ? La réponse via l'analyse des performances de plusieurs configurations à processeur AMD sous divers jeux. Lire la suite
-
Core i5 et i3 mobile : enfin la fin des Core 2 Duo ?
Après les Clarksfield (Core i7-920XM et autres), Intel complète aujourd’hui sa plateforme Calpella avec le lancement des Arrandale, une gamme de processeurs dual-core en 32 nm assortis d’une puce graphique intégrée gravée en 45 nm. Lire la suite
- SIEMENS INDUSTRY - MOBILITY - INGÉNIEUR SYSTÈME POSTE DE COMMANDE CENTRALISÉE (H/F)
- SIEMENS INDUSTRY - MOBILITY - INGENIEUR INTEGRATION ET VALIDATION LOGICIEL POUR LES EQUIPEMENTS VIDEO PHONIE (H/F)
- SIEMENS INDUSTRY - MOBILITY - CHEF DE PROJET INFORMATIQUE (H/F)
- SIEMENS IT SOLUTIONS & SERVICES - CONTRÔLEUR DE GESTION / GESTIONNAIRE DE PROJET (H/F)
- SIEMENS HEALTHCARE - WORKFLOW & SOLUTIONS - INGENIEUR DEVELOPPEMENT FRAMEWORK MUMPS (H/F)
- application iphone gratuite
- windows 7 starter
- prix windows 7
- jeux psp telecharger gratuitement
- developpement pas cher
- comment telecharger utorrent
- windows 7 integrale
- emulation wii
- nouvelle wii
- firefox 64
- comparatif core i7
- telecharger jeux psp
- runtime error visual c++
- optimiser vuze
- geforce 8800 gts
- portable 13 pouces
- runtime error
- test athlon x4
- bouygtel email
- intel core i3
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 ?
@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.
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... ;-)
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.. ;-)
c'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.
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...)
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...
Je 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...).
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.
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... :-)