Bonjour à tous!

Je viens vers vous car je suis étonné du peu d'information sur la technologie ATI stream sur le net.

Je me doute que CUDA est plus performant mais j'ai une HD5850.

Je fais des calculs mathématiques avec ma tour et je voudrai aider mon CPU avec mon GPU pour gagner du temps.

Connaissez vous ati stream et est ce simple à mettre en oeuvre?

Et surtout, est-ce spécifique à une liste de logiciels ou n'importe quel processus gourmand peut être aidé par le GPU avec ati stream?

Bien sur ma carte semble le gérer (en bas a droite):

http://www.amd.com/fr/products/desktop/graphics/ati-radeon-hd-5000/hd-5850/Pages/ati-radeon-hd-5850-overview.aspx

Merci, et bonne journée

PS: je viens ici dés fois qu'il y ait un illuminé qui connaisse bien ça ou cuda....

Bonjour,

Hélas, moi je n'y connais rien. Je peux éventuellement demander à un collègue qui a bossé chez NVidia s'il a de bons pointeurs pour ATI (normalement, il a du surveiller les concurrents quand il était chez NVidia ). Par contre, je ne le vois plus avant demain.

Merci,

C'est le principe qui m’intéresse et je pense que cuda fonctionne à peu près de la même façon. Ce qui m’intéresse est très basique:

Est ce que c'est utilisable pour n'importe quel logiciel qui est gourmand??

J'ai l'impression que si le logiciel ne le gère pas nativement, il faut créé tout un programme avec openCL pour déporter les données sur le GPU, est ce que c'est cela??

Si tu as l'occasion de demander a ton collègue les très grandes lignes je serai ravi sinon pas de problèmes, je m'en passerai...

Bonne fin de journée

j'ai entendu parler de ce truc. mais il te faut un processeur AMD il me semble et qui puisse le supporter aussi.

je dis bien "il me semble"

sinon fait un tour chez amd (vu que ati = amd maintenant) pour voir si y'a pas ce logiciel pour linux.

En très très grossier, je te dirais que tout ce dont tu as besoin, c'est de coder avec la surcouche du C qui va bien (ça semble être openCL dans ton cas), puis de compiler avec les bons outils.

Pour cuda, je sais que c'est accessible pour le grand public. Pour ATI, c'est sans doute le cas aussi mais je ne peux guère être très précis.

dans mes dépots, cuda c'est destiné a nvidia exclusivement.

j'ai trouvé ceci :
http://support.amd.com/us/gpudownload/Pages/sdkdwnld.aspx

Chris, pas banir stp.

Oui, Cuda c'est le framework de Nvidia pour Nvidia.
Il me semble que OpenCL est quand à lui "tout terrain".

aodren: grumpl…

Règle numéro -3 : toujours chercher dans son gestionnaire de paquets d'abord
Règle numéro -2 : quand la règle numéro -3 échoue, demander aux gens de la communauté le nom du paquet
Règle numéro -1 : quand le règle numéro -2 échoue, réévaluer le problème et appliquer la règle numéro 0.
Règle numéro 0 : faire des demandes claires et précises.

Vu comment c'est à la mode, je pense que les outils de bases doivent être packagés dans les meilleures distributions. Par ailleurs, on ne sait pas quelle distribution a spit_team, donc ne balance pas des liens dans le vent comme ça.

oula,
gourmand en CPU ne veut pas dire le GPU est utile. Un GPU ca a une puissance de calcul potentiellement puissante mais c'est bete comme ses pieds.
Basiquement, si tu fais un calcul du genre
for (int i=0; i<BEAUCOUP; i++) a[i] = fonctionsimplede(b[i]);

alors le GPU va bien fonctionner. Sinon ca sert a rien.
Cependant, il y a d'algorithmes qui fonctionne comme ca.
Globalement si tu n'as jamais fait de HPC oublie le calcul sur GPU et contente toi du paquet debian qui va bien.

Des details. Les GPUs de nvidia (les seuls sur lesquels on a mis la main) sont compose de threads blocks. Basiquement, ce sont de gros SIMD. Donc ils executent tous le meme code. Si un jump les fait diverger alors l'execution des deux branches est sequentialisee et les performances s'effondrent.

Apres il y a tout un micmac avec l'access au GPU, les 40 niveaux de memoire ou on peu stocker des choses. Les access sequentiels a la memoire qui fait que tous les codes qui indirige vont avoir des performances mauvaises...

Merci a tous pour vos réponse et ca répond bien a ma 1ere question a savoir: C'est pas simple à mettre en œuvre!

Je vais passer mon chemin sur ce coup la, car mes connaissances sont largement dépassées! merci d'avoir pris le temps de répondre!

Persévère!

En effet si tu est possesseur d'une carte ATI, il te faudra utiliser OpenCL (et même en étant NVidia pour plus de simplicité)

Après pour faire des calculs sur un GPU il faut que la nature des calculs puisse exploiter le parallélisme. Pour cela il savoir si ton programme requiert beaucoup de dépendance (Si le calcul de B nécessite le résultat de A cela pose problème)

La seconde chose qui est difficile à comprendre, c'est de saisir l'architecture du GPU et notamment de sa mémoire. Car un GPU délivre sa puissance si tu comprend comment allouer la mémoire. Tu peut donc utiliser la mémoire local (qui est celle de la carte graphique), la mémoire globale (qui est la mémoire dont tu dispose en barrette de ram sur ta carte mère) En plus de cela tu as des unités de mémoire au sein même des unités de calcules (des registres faisant office de cache).

Commence donc par te procurer le vue de ton GPU sous forme de schéma afin de comprendre les interactions possibles entre les éléments.

Il te faut aussi comprendre la manière dont on définit les Work-Group, les Work-Units etc (en fait ce sont des matrices dont tu peut choisir la taille sous les dimensions XYZ selon le problème que tu aura à résoudre)

C'est très intéressant tu verra!

Tu peut trouver des exemples de code pour comprendre comment on implémente du code pour faire tourner le GPU (Comprend d'ailleurs qu'il te faut rédiger un programme HOST qui tourne sur le CPU et qui appellera un THREAD (un processus) qui lui sera sur le DEVICE (le GPU). C'est donc le CPU qui crée un appel afin de recourir au GPU. Le seul de récuperer le résultat est donc de vider la mémoire locale vers la mémoire globale (or tu sais bien que faire passer des infos par le biais du port PCI engendre des pertes de performance)

C'est la qu'il faut comprendre le fait qu'il faille minimiser les échanges entre GLOBAL et LOCAL. Si ton programme demande trop d'échange tu va faire mouliner les GPUs pour rien (perte de cycle). Il faut donc bien gérer les chaines de travail (la notion de "queue")

Il est vrai que Nvidia communique beacoup plus, en témoigne leurs outils de développement "Parrallel Nsight" http://developer.nvidia.com/object/nsight.html

Si la prog t'aime vraiment ca, télécharge ce qu'il faut sur le site du Khronos Group concernant les spécifications d'OpenCl.

Merci pour cette réponse claire et très intéressante!
Le soucis réside dans le fait que le logiciel que j'exploite est un code de calcul aux éléments finis possédant une bonne dizaine de solveurs différents implémentés. A la vue des équations résolues (méca-flux, thermique, maillage mobile) et de la géométrie, il est impensable de le programmer en direct. Faisable pour des calculs beaucoup plus simples mais on met des milliers d'euros dans un code de calcul c'est pas pour en re-créé un nous même.
En plus le logiciel (comsol pour ne pas le citer) est particulièrement fermé concernant l’accès au code...

Considérant cela, je crois que cela ce complique encore mais merci et je crois que si un jour je doit programmer un code, je regarderai du coté d'OpenCL

Les calculs de physiciens se portent assez bien sur GPU en regle generale. Tout ce qui est PDE, PIC, MxV et MxM se passent globalement plutot bien. Je ne sais pas ou tu travaille et quel type de logiciel tu utilise. Mais je suis sur que tes problemes de parallelisations ur GPU interesseront les gens de HPC de n'importe quel universite. On fait des trucs comme ca a OSU. et ca marche pas trop mal