AMD profite du forum SC15 pour annoncer l'initiative Boltzmann, un ensemble de nouveaux outils dédiés à renforcer sa présence dans le HPC, notamment via un ...
Lire la suite ...

Je vois que ça parle de cudaMemcpy(), ça ça me parle !
 
C'est intéressant de la part d'AMD de proposer une solution semi-automatique pour faire tourner du CUDA sur son hardware, mais ont-ils oublié le plus important ? L'optimisation matérielle.
 
Si CUDA a l'avantage jusqu'ici c'est principalement parce que Nvidia peut optimiser son matériel et son API ensemble, là où OpenCL se destine a tout un tas de matériels et ne peut pas bénéficier du même soin.
 
D'une part, les performances pourraient être bien inférieures, et d'autre part, Nvidia pourra facilement gêner cette initiative en revoyant l'API et les générations futures pour que les GPUs AMD soient à la ramasse en exécution de code CUDA.
 
C'est pessimiste comme suppositions mais ça me parait réaliste.

Intéressant. En fait les dev Cuda galèrent sur Open CL à devoir réapprendre tout. Cuda a attiré au tout début surtout à cause du prix imposé par Nvidia au marché. Plus ça fait payer cher, plus ça attire les devs, comme sur Apple plateforme iOS.
Le problème c'est que les logiciels clés qui font basculer le marché pro en faveur de Nvidia appartiennent ou sont contrôlés par Nvidia même. Notamment les logiciels de rendu "offerts" aux sociétés qui développent des logiciels 3D (comme Autodesk) sous garantie d'usage exclusif de leur solution, mais vendus cher au professionnels en utilisation standalone. Une stratégie d'infiltration et dépendance qu'AMD n'a même pas commencé à mettre en oeuvre. Le marché open source et indépendant, est resté pendant ce temps atone face à l'offre AMD, pourtant nettement plus intéressante et performante au niveau du hardware.
 
Il faut savoir que le milieu pro fait valoir ses dépenses, investissements au moment de la facturation aux clients, notamment publics, qui souvent contrôlent ce marché.
Donc plus c'est cher et innaccessible mieux c'est quitte à avoir moins performant mais plus standard. C'est exactement ce que représente la solution Nvidia et Cuda : solution moins performante (car doit sortir plus vite pour être supportée niveau software au plus vite avant les concurrents), plus chère, plus verrouillée donc moins accessible mais du coup adoptée à bon escient par les devs qui ont envie d'un bon retour financier sur le temps passé à développer.
 
Du coup le coût d'achat chez Nvidia ne compte pas. Leur enjeu c'est de créer le standard haut de gamme.
Du coup AMD, malgré un meilleur hardware, une architecture plus aboutie, doit courir après les standards maison Nvidia, vendre le moins cher possible, faire moins de profits, en espérant un jour faire basculer le marché à son bénéfice. Pour ce faire, il faudrait que le marché stagne au niveau des standards qui à force deviendront les mêmes pour tous les intervenants (AMD tente de pousser dans ce sens), ce que Nvidia ne laissera bien sûr pas faire.
@taronyu26:
Au niveau de l'API on se fiche que Nvidia la modifie. Ce n'est pas elle qui intrinsèquement compte pour faire un portage du code Cuda. Donc ça ne change rien que Nvidia la retouche car ça ne changera pas l'exécution du code porté sur les cartes AMD. Tout au plus Nvidia peut gêner le portage du code Cuda avec les outils AMD fait pour du multiplateforme, et là ils se tireraient une balle dans le pied puisque seules leur carte poserait problème.
 
Au niveau de la traduction d'un langage vers un autre, jamais aucun jugement n'a donné raison à celui qui voulait protéger la possibilité de portage. Bien au contraire. Ce qui est protégé c'est la compilation vers l'exécutable final. Donc si AMD faisait un compilateur Cuda direct, Nvidia pourrait éventuellement s'en plaindre auprès des tribunaux. Encore faudrait-ils qu'ils démontrent qu'AMD a copié ou utilisé du reverse engineering et non réalisé d'après des specs publiques.

Ce que je comprends pas, c'est pourquoi AMD n'accepte pas tout simplement de se faire un runtime CUDA. Il y a déjà LLVM qui supporte CUDA, ils ont juste le runtime à faire...
HIP c'est cool, mais les gens ne se donneront probablement même pas la peine de l'utiliser. (Alors que HSA est une technologie qui apporterait d'énormes gains d'efficacité energétique).
De ce que je vois tous les jours, les gens du HPC veulent juste pouvoir utiliser ¨MPI, OpenMP voire à la limite CUDA. Et la plupart du temps ils ne jurent que par Intel/NVidia...

C'est triste le troll à la deuxième ligne en fait.

@cocto : Sérieusement ? Les dévs seraient attirés par ce qui est cher, et c'est tout ? Et c'est forcément moins performant derrière ? Du grand n'importe quoi.
Comme je l'ai dit, au contraire, Nvidia fabrique le matériel sur lequel son API pourra tourner, et contrôle parfaitement toute la chaine. Alors qu'en OpenCL, on est libre de se tourner vers tout un tas de matériel, ce qui complique l'optimisation au niveau hardware.
Concernant CUDA, ce n'est pas que ça "coût cher" et "est moins performant". Ça n'a pas directement de prix, d'une part, et d'une autre c'est très performant. Si ça attire les développeurs, c'est parce que c'est bien pensé et que ça fait le café. Pour avoir programmé avec CUDA et OpenCL, le premier m'a paru bien plus simple.
Finalement je ne sais même pas pourquoi j'entre dans le débat, vu le beau troll bien gras que tu as posé, tu perds toute crédibilité.

CUDA s'est imposé parce que nVidia est arrivé le premier, et avec un niveau d'abstraction qui visait assez juste : suffisamment de contrôle sans que ça soit rebutant. AMD avait fait des annonces bien avant tout le monde qu'ils donneraient un accès bas niveau à leur GPU, et puis comme d'habitude ça a traîné, et quand c'est enfin arrivé le mal était fait, c'était juste trop bas niveau, on pouvait certes aller chercher les derniers pouillèmes de perf mais à côté de CUDA où on pouvait faire à peine moins bien avec beaucoup moins d'efforts...
 
Restait plus qu'à AMD à se rallier au projet OpenCL, qui s'inspire largement de CUDA, mais avec un petit effet "design by committee" en plus...

L'optimisation matérielle c'est assez marginal en terme d'impact. Il y a pas de raisons qu'un code OpenCL bien écrit soit plus lent qu'un code CUDA.
 
C'est dommage d'ailleurs que CUDA soit si populaire, car on est encore face à une techno propriétaire qui ne profite en rien à l'avancée de l'industrie, mais bon avec Nvidia on a l'habitude.
J'espère qu'un jour tout le monde utilisera des standards ouverts comme OpenCL, OpenGL/Vulkan, AdaptiveSync etc...
Mais bon, ça sera probablement jamais le cas, notamment à cause de Nvidia.

Bien sûr qu'un code OpenCL n'a aucune raison d'être plus lent qu'un code CUDA. Là n'est pas le problème. D'une part Nvidia a été le premier à proposer un écosystème cohérent et robuste, d'autre part un code OpenCL est un poil plus bas niveau qu'un code CUDA runtime. OpenCL est plus proche de CUDA driver.
 
Par contre l'optimisation spécifique au hardware peut avoir un impact énorme, que ce soit au niveau du taux de remplissage des unités de calcul ou de l'efficacité des accès mémoire.

L'immense avantage de CUDA, à l'heure actuelle, est son écosystème. De nombreux logiciels du monde HPC ont un support de CUDA. Quand ce n'est pas le cas, ils ne tournent tout simplement pas sur le GPU (sauf quelques exceptions). Il n'y a pas de raison qu'un code CUDA soit plus performant qu'un code OpenCL sur un GPU NVIDIA si ce n'est qu'en CUDA, il y a les bibliothèques cuBLAS, cuFFT, cuDNN, etc. Il y a aussi CUB ou Thrust. De plus, il y a une quantité impressionnante de présentations sur le développement CUDA et l'optimisation sur NVIDIA.

 
si ça permet un meilleur décodage vidéo x265/264 , je vote pour , c'est pas la fête à ce niveau là avec GPU AMD

A ce sujet, depuis Kepler (ça vaut donc aussi pour Maxwell), Nvidia a remplacé NVCUVENC (qui était l'encodeur basé sur CUDA) par NVENC qui est un encodeur à part et qui exploite la partie matérielle dédiée à l'encodage et au décodage vidéo.
Je ne sais pas ce qu'il en est chez AMD, est-ce qu'ils ont une partie du GPU prévue spécialement pour la vidéo hardware, ou est-ce que c'est traité de manière "classique" comme tout autre kernel ?

 
non , malheureusement , AMD GPU ne traite rien du tout sauf 1 % via opencl , peut-être la Fury ?

Oooh my god. Nvidia a été l'un des premiers à proposer une solution d'utilisation du gpgpu pas trop casse tête pour un dev quand cuda c'est pointé
 
Et ça va être encore sa faute si opencl est pas plus utilisé
 
Ça va être encore la faute à nvidia si une solution payante a avant tout été accessible avant une solution libre
 
Y en a encore qui vivent dans le monde des bisounours ou les les devs qui pondent des solution 'libre' ne doivent vivre que d'amour et d'eau fraiche, que tout doit être gratuit
 
On est pas dans star trek hein ou la monnaie n'existe plus car chacun prend ses responsabilités de vouloir ameliorer la condition humaine
 
On est dans notre 21eme siecle ou tout est bon pour affamer son voisin pour peu de toujours pouvoir plus ammasser de richesse

Pour info, CUDA n'est pas une solution payante. CUDA est en téléchargement sur le site de NVIDIA. La seule chose est que NVIDIA est seul maître à bord quand il s'agit de définir les évolutions de CUDA (un peu comme Microsoft et DirectX).