Reprise du message précédent :
Une question toute bête :$, pourquoi faut-il utiliser un compilateur spécifique ? Il n'aurait pas pu donner accès à leur carte graphique via un ensemble de librairie et langage C standard ?

Futur ingénieur, l'anglais doit pas etre bloquant pour toi.
Pour les EDI tu peux utiliser Eclipse par exemple : http://lifeofaprogrammergeek.blogs [...] pment.html ou bien XCode sour Mac OS X (un gars de chez NVidia se trimballe un plugin xcode en signature sur les forums, faut que je retrouve le lien)
 
 

 
Cuda permet de sortir du binaire pour la carte graphique OU BIEN du code C adaptable sur n'importe quel CPU multicore. Qui plus est, Cuda est un esnsemble d'extensions au C standard, extensions non prises en charge par les compilos classiques comme GCC. D'ou le compilateur NVCC.

Stop la touchette, tu confonds avec RapidMind
CUDA c'ets pour les GPU point.
 

Qui n'est qu'un vulgaire preprocesseur+linker de mauvaise qualité. Mais bon, NVIDIA n'ets pas connu pour ecrire des compilos propres.

 
C'est faux. Lis la doc de NVCC. Un peu plus attentivement que ce que tu as du faire jusqu'a present
 
NVCC génère du code PTX ou du code C tournant sur CPU multicores, en utilisant l'option -multicore
 
Et evite d'employer ce ton condescendant avec moi, je n'ai absolument pas de lecons a recevoir.

 
Et avec OpenCL la donne change niveau compilateur? JE veux dire ça s'interface toujours avec du C et il faut toujours un compilateur + EDI particulié ou il faut juste linker une lib?  
 

Bon et bien, au moins, j'aurais eu un lundi matin productif. Ca date de la SDK2.1 ???

Et toi apprends à prendre les choses au second degré
et évite ce genre de phrase à deux balles, personne ici n'a de leçon à recevoir

Je sais pas trop, mais ca sent encore le mammouth indigeste. Le modèle d'exécution de ces archis est bon mais les outils proposent tous un modèle de programmation foireux.
OpenCL c'est quand même juste du CUDA multi-plateforme, rien de transcendant

Faites vous un bizous

Arf c'est pas encore pour moi tout ça alors.  
Vivement qu'on en soit à une simple lib à la manière d'OpenGL.

 
C'est pas trop ça qu'il faut mais des outils avec un degré de granularité suffisant pour masquer ces histoires de warp/block/threads etc.

 
Non, ca date d'avant mais je suis plus si c'etait dans la 1.0

 
Bon ben je vais taper sur mon thésard pour pas avoir fait son travail de biblio

Ne jamais cogner sur les thésards

bon et en terme de gain ? ca donne quoi le -multicore ?

aucune idee mais je vais tester ca dans pas longtemps, je suis en train de porter un code Matlab de simulation d'écoulements multiphasiques en cuda

J'ai pas regarde en detail les differents documents a propos d'OpenCL. Mais comme il y a differentes architectures, je suppose que les binaires resultants de la compilation d'OpenCL ne sont pas compatible entre eux ? Dans les specification d'OpenCL, il est question d'online/offline compiler.
Dois-je en deduire que si on veut lancer notre programme sur une architecture inconnue, on doit alors fournir les sources et le programme sera alors compile au plus tard a l'execution ?

Pour info, l'option multicore est prévue pour cuda 2.1 et n'est pas dispo dans cuda 2.1 beta.
 
;o)
 
Peace ^^

 
En OpenGl, les shaders GLSL sont compilés par les drivers, y'a pas de compilateur offline et de binaire standardisé permettant de l'obfuscation. C'est toujours une des grosses critiques face au D3D qui a standardisé du byte code.
 
Si il y a une notion d'offline compiler, on devrait alors avoir des spécifications de machine virtuelle & de byte code cross-vendor (sauf si ils ont évités de se mouiller en ne spécifiant pas de byte code collant au langage). Maintenant je sais pas j'ai pas zieuté plus que ça.

en tout cas cette philosophie est pourrie, si leur surcouche n'est pas excellente, ca ne prendra pas... Et quand on ne sait pas ce qu'on fait précisément, on ne peut pas tirer parti du meilleur potentiel de ces chips. Mais leur archi est "secrete"... Super pour la standardisation. Mais en fait, un seul modèle ressortira et les proces graphiques seront bientôt agencés de manière beaucoup plus similaire, là on se refait le coup de l'archi vectorielle. Bouarf.

 
Clairement. Et si openCL se contente de renommer CUDARunKernel en CLRunKernel, l'utilité es nul.
Il faut un modèle de prog de haut-niveau et masquer à l'utilisateur les rouages de ces bestioles.

Je plussoie et là je serais fan.

La je suis pas sur de comprendre, l'avantage d'OpenCL c'est sa portabilite multi-architecture + syntaxe C + compilation. Et la vous semblez vouloir avoir la maitrise totale de votre plateforme.
Sachant que les architectures sont independantes, vous prechez donc plus pour avoir des "applications" non portable mais rapide ?
 
La vision d'Intel semble repondre a vos attentes (lien que j'avais laisse sur la premiere page Intel: CUDA will be just a 'footnote' in computing history) ‘Our approach to this has been to not force programmers to make a radical architectural shift,’ explained Gelsinger, ‘but to take what they already know – this IA-compatible architecture – and extend the programming model to comprehend new visual computing data-parallel-throughput workloads, and that’s the strategy that we’re taking with Larrabee.’

le probleme c'ets "syntaxe C" : le C n'est pas fait pour exprimer proprement du massivement parallele scalable.

 
coté OpenCl, si le bytecode est propriétaire, y'a pas vraiment de portabilité.

Ben si le code source.

T'as déjà fait du D3D ?

 
si c'est à moi que tu parle, pour la première partie de ta réponse, hé bien c'est tout le contraire, je pense justement que le language doit abstraire le matériel avec un standard pour être entièrement portable. C'est la base dans un environnement multi-archi
La stratégie d'intel est la bonne ; cependant, on peut penser que leurs tentatives passées n'ont pas été fructueuses, par exemple l'hyper threading.
 

 
D'autres languages sont bien meilleurs, effectivement. Fortran par exemple est concu dès le départ pour cela, et la dernière norme commence à prendre en compte des éléments de parralélisme massif. A noter qu'on recommence le coup d'il y a 20 ans, donc on ne part pas de rien car la réflexion a été bien amorcée. La difficulté, c'est surtout d'arriver à coupler les deux modèles, le CPU et le GPU, qui ne sont pas faits pour faire le même type de tache. En fait, cela ridiculise un peu la position du pdg de nvidia qui ne croit qu'au gpu (même si actuellement, ils se remettent au développement d'un chip x86 ).
 

 
bytecode, c'est une représentation finale du code, mais si gcc inclue un backend gpu ca sera gratuit et puissant. Par exemple c -> représentation intermédiaire -> assembleur ici c'est openCL -> compilo amd/intel/nvidia -> bytecode. Le truc c'est que comme je l'ai dit, les archis sont très complexes à maitriser et pas adaptées à tous les workloads.
 
Parler de larabee est en effet intéressant, car intel tente de démontrer que les x86 sont scalable. C'est très intéressant, mais plutôt faux pour le moment.
 

 
toutafé
 

 
techno proprio non standardisée = beurk.
donc c'est valable pour les jeux, uniquement, et zindowz de surcroit
 
 
En dernier lieu, il faut penser que :
 
1 - on ne peut pas tout reprogrammer pour ces gpus : le temps de produire une optimisation poussée, que la prochaine archi rend cette optimisation obsolète. A remarquer que ca permet de déporter une partie du travail à l'externe, c'est la philosophie amd mais ils sont revenus dessus (initiative CTM)
 
2 - on doit avoir un standard type opencl portable et stable
 
3 - ce standard doit répondre aux attentes des programmeurs (besoins)
 
4 - ca doit être clair, limpide, efficace, pas usine à gaz, peu cher, avec des outils libres.
 
Pas mal de conditions à remplir  

 
techno proprio non standardisée = beurk.
 
Bin oui mais non.
Le D3D utilise du bytecode standardisé contrairement à l'OpenGl et à l'OpenCl.
Que le D3D soit sous la houlette de microsoft ou sous la houlette d'un groupe de travail avec des participants qui cherchent leur interêt propre, ça change pas grand chose. Ce qui compte c'est l'approche technique.
Si pour toi un driver OpenCl qui bouffe du bytecode PTX dans le cas d'un driver nVidia (et donc autre chose chez les autres), c'est ouvert et standardisé, on a pas le même vocabulaire.

 
je pense sans offense que nous n'avons, comme je l'ai dit, pas les mêmes exigences quand à la programmation. Moi je veux du code portable qui marche, basé sur une spec claire. Toi, tu veux optimiser à mort dans des jeux avec des shaders. Parce qu'autrement, les shaders d3d ne servent à rien.
 
Perso, pouvoir programmer un gpu c'est pas donné à tout le monde, vectorisation oblige, donc les outils proprio pour la conversion sont un passage obligé. Les trucs pas génériques qui font gagner 5% dans les coins, mouef.
 
Faut aussi comparer par rapport au x86 qui est standardisé, l'archi des gpus ne l'est pas et c'est tout le problème, t'aura jamais accès aux specs pour programmer direct.
 
En même temps, bytecode ou assembleur, je vois pas la différence, personne ne code plus en assembleur sauf cas très précis et limité.
 
Donc comme je l'ai dit je suis d'accord avec toi la dessus, c'est pourquoi j'ai dit "quand on aura un backend gcc qui compilera pour les gpus".
 
a+

encore récemment, on a developpé des algos ici ou la différence de speed-up entre GPU et quad X86+SSE2 etait d'à peine 4 ... Comme quoi

 
Ce que je veux dire pour moi la spec claire et -complète- c'est la spec qui défini le bytecode en accord avec le langage. Hors ni l'OpenGl ni apparement l'OpenCl n'ont défini leur bytecode de shader/kernel respectifs. Que le D3D soit dispo uniquement sous windows c'est un fait problèmatique, que tu doive passer chaque compilo offline de constructeur en est autre aussi lorsque tu veux distribuer que du binaire.  
ça n'a rien a voir avec les performances, ça a bien avoir avec la portabilité et le verrouillage d'une api par un vendeur de matériel.
l'OpenGl en a souffert et c'est dur à digérer de voir que le groupe de travail de l'OpenCl n'en ait pas pris conscience.

C'est pas en rapport avec la vision par ordinateur, mais je m'intéresse à CUDA dans le but d'implémenter un moteur de recherche sémantique basé sur l'algo LSA ( http://fr.wikipedia.org/wiki/Analy [...] ue_latente ), exploitable par un intranet en php. La principale difficulté de l'algo (en codage et perfs) est le calcul de la SVD sur une grosse matrice (plusieurs milliers de lignes par plusieurs milliers de colonnes), inenvisageable en PHP mais réaliste avec en .exe en C surtout si c'est du parallélisé sur GPU. J'ai regardé un peu l'avancée de ce qui existait pour CUDA et j'ai juste trouvé MAGMA qui serait plus ou moins un portage de la lib Lapack en CUDA mais je n'ai pas trouvé d'info sur l'avancée de ce projet.
 
En gros, dans l'idéal, je recherche un soft en CUDA qui calcule une SVD et qui prend en paramètres en ligne de commande un fichier (en csv par ex) contenant la matrice sur laquelle il faut calculer la SVD et qui me donne sortie dans un ou plusieurs fichiers le résultat de la SVD. Est-ce que ça vous dit qq chose? C'est pas dans mes habitudes de demander du code tout fait, mais coder une SVD (performante!), en + sur CUDA, c'est pas à la portée de tout le monde ...
 
Merci par avance si vous avez des infos là-dessus

les gens de Barcelona SuperComputing bosse sur ce genre de truc.
C'est pas trivial et malheureusement, je pense pas que CUDA-Lapack soit bien avancé.

Tu irais aussi vite en utilisant un LAPACK tuné pour ton archi (mates du coté de atlas en SSE2 par exemple) car 1000x100 ca reste ridicule comme taille surtout pour une GPU.

merci pour l'info, je vais regarder. Mais j'ai dis "plusieurs milliers de lignes par plusieurs milliers de colonnes" : du genre 20000x5000.  
 
L'algo LSA nécessite une SVD (calculée de temps en temps quand le nb de nouveau documents indexé a augmenté significativement, donc peut être fait le soir) mais pour une requête d'un utilisateur, faut faire le produit de la requête de l'utilisateur (convertie en matrice ligne) avec la matrice contenant les n premiers vecteurs propres de la SVD puis faire le cosinus entre le vecteur résultat avec chaque vecteur associé aux documents indexés dans la base (le vecteur est calculé de la même façon au moment de l'indexation du document dans la bd) et trouver les documents qui ont un cos proche de 1 si possible ou > à un seuil donné.
 
J'ai donc besoin que le calcul de ses comparaisons en cos et du produit matriciel se fasse dans un temps raisonnable pour l'utilisateur (de l'ordre de qq secondes) sur mon serveur qui est basé sur un AMD Opteron(tm) Processor 252 (2,59 GHz).

20000x5000 dense ou sparse ?
LAPACK a un support pour les sparse de tête

plutôt sparse je pense puisque les lignes représentent les mots d'un lexique (plus précisément, des lemmes d'un lexique + des termes spécifiques au contexte technique pour lequel le moteur sera élaboré) et les colonnes les documents indexés. L'intersection d'une ligne avec une colonne représente le tf-idf du lemme pour le document.

sparse sur GPU ca risque d'etre tendu

ah, pourquoi? Je précise que je suis pas un grand matheux, donc désolé si la raison peut paraître évidente...

les GPU sont surtout faites pr des calculs data-parallel dense ... Le structures de stockage sparse implique généralement des espaces méméoires plus petit, disjoint e moins pratique à manipuler

Je vois ce que tu veux dire. Mais là, tu parles de structures de stockages optimisées pour des matrices "particulières" (ici, sparse). Or, on peut les représenter aussi bêtement sous forme de lignes/colonnes comme les matrices "normales" (dense, donc). Et de ce fait, ça pourra marche avec un GPU. Maintenant, est-ce que ça va être efficace en perfs, ça j'en sais rien.
Par ailleurs, je cherche pas forcément à faire du CUDA pour ma SVD et mon calcul de produit matriciel. Je veux juste que le temps de calcul soit rapide pour l'utilisateur. Si avec un bon prog en C ça marche sur mon type de CPU et que ça va supporter la croissance des documents indexés, ça me va. Mais, à tord peut-être, j'ai plus l'impression que du calcul parallèle sur un GPU supportera mieux la montée en charge...
 
Ca ne rentre pas en ligne de compte dans notre discution mathématique, mais je précise que le moteur que je souhaite développé soit sous licence GPL, une sorte de Lucene mais sémantique et pas juste basé sur des mots-clés.

Il me semble que dans Gpu Gems 2 ils en parlent, en utilisant une indirection avec une texture et quelques subtilités en plus pour conserver une localité décente, c'est pas aussi efficace que du dense mais ça reste ptêtre intéressant.