alors, dans l'ordre, et sous reserve de corrections par des gens plus qualifiés que moi* :
1/oui, on peut faire n'importe quel type de calcul. Avec CUDA par exemple (openCL j'ai regardé de très très loin, mais de ce que j'ai vu ca devrait etre pareil), tout le côté pipeline graphique est caché, meme si tu peux interagir un peu avec openGL côté CPU (j'ai pas trop regardé ca). Tu vas programmer ce que Le langage ressemble très fortement au C, avec quelques mots clés en plus pour dire ce qui est sur GPU ou sur CPU, et gerer la hierarchie mémoire (que tu gères de manière explicite). Niveau prog effective, c'est comme du C : tu peux boucler, appeler des fonctions, ... . Alors par contre à la réflexion je sais pas si ca gere les pointeurs de fonctions - je n'en ai pas eu besoin -, comme tout est inliné dans le noyau (équivalent du main() d'un prog C). Et après, tu appelles ton noyau depuis un prog (C ou C++) presque comme une fonction normale, tu précises juste comment tu répartis chaque tache sur le GPU (je te laisse te référer au guide de programmation de CUDA - très bien fait, trouvable dans le SDK - pour plus de détails).
2/ Tout peut être calculé, mais d'un autre côté, seuls une partie des problèmes peut être traités efficacement par le GPU. Typiquement, les GPUs ne sont pas du tout adaptés aux algos purement séquentiels avec une seule donnée à traiter à travers de nombreuses étapes. Le mieux, c'est quand tu veux N résultats (N grand) d'une même fonction (ne bossant pas forcément sur les mêmes données, heureusement ^^). Dans ce cas, ton noyau contiendra le code d'une tâche. tu peux aussi faire des opérations où tu ne veux qu'un seul résultat, pour des fonctions de type "rédux". Si les données de base sont très grosses, le gain est vraiment notable aussi. Bon après des fois des algos qui apparemment ne s'y pretaient pas peuvent être adaptés, c'est au cas par cas.
3/Si j'ai bien compris, le Larrabee se programmera comme un GPU, avec du vectoriel en plus. Après, peut-etre qu'ils proposeront plusieurs niveaux : un niveau "facile", ca sera du openCL (threading et SIMD géré automatiquement), et un niveau "bas niveau", où tu te feras ton threading toi-meme et exploitera le SIMD toi-même. N'étant pas devin et ne bossant pas sur le Larrabbee, j'attend de voir ^^. Dans tous les cas, ca sera par du parallélisme massif qu'on en tirera le mieux (plus y a de taches, plus on peut cacher la latence des accès mémoires)
4/ben la CUDA zone donne un bon apercu...je l'utilise pour du rendu par lancer de rayons, mais des gens l'utilisent en dynamique des fluides, en electrodynamique, en rayonnement, ... en gros, dès que c'est intensif et qu'on veut plein de résultats d'un même calcul de base.
les algos qui en tirent le plus parti
*parce qu'il y en a toujours, loi 1 de l'humanité ^^
[^] # Re: Un peu précipité, non ?
Posté par tarlack . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 10.
1/oui, on peut faire n'importe quel type de calcul. Avec CUDA par exemple (openCL j'ai regardé de très très loin, mais de ce que j'ai vu ca devrait etre pareil), tout le côté pipeline graphique est caché, meme si tu peux interagir un peu avec openGL côté CPU (j'ai pas trop regardé ca). Tu vas programmer ce que Le langage ressemble très fortement au C, avec quelques mots clés en plus pour dire ce qui est sur GPU ou sur CPU, et gerer la hierarchie mémoire (que tu gères de manière explicite). Niveau prog effective, c'est comme du C : tu peux boucler, appeler des fonctions, ... . Alors par contre à la réflexion je sais pas si ca gere les pointeurs de fonctions - je n'en ai pas eu besoin -, comme tout est inliné dans le noyau (équivalent du main() d'un prog C). Et après, tu appelles ton noyau depuis un prog (C ou C++) presque comme une fonction normale, tu précises juste comment tu répartis chaque tache sur le GPU (je te laisse te référer au guide de programmation de CUDA - très bien fait, trouvable dans le SDK - pour plus de détails).
2/ Tout peut être calculé, mais d'un autre côté, seuls une partie des problèmes peut être traités efficacement par le GPU. Typiquement, les GPUs ne sont pas du tout adaptés aux algos purement séquentiels avec une seule donnée à traiter à travers de nombreuses étapes. Le mieux, c'est quand tu veux N résultats (N grand) d'une même fonction (ne bossant pas forcément sur les mêmes données, heureusement ^^). Dans ce cas, ton noyau contiendra le code d'une tâche. tu peux aussi faire des opérations où tu ne veux qu'un seul résultat, pour des fonctions de type "rédux". Si les données de base sont très grosses, le gain est vraiment notable aussi. Bon après des fois des algos qui apparemment ne s'y pretaient pas peuvent être adaptés, c'est au cas par cas.
3/Si j'ai bien compris, le Larrabee se programmera comme un GPU, avec du vectoriel en plus. Après, peut-etre qu'ils proposeront plusieurs niveaux : un niveau "facile", ca sera du openCL (threading et SIMD géré automatiquement), et un niveau "bas niveau", où tu te feras ton threading toi-meme et exploitera le SIMD toi-même. N'étant pas devin et ne bossant pas sur le Larrabbee, j'attend de voir ^^. Dans tous les cas, ca sera par du parallélisme massif qu'on en tirera le mieux (plus y a de taches, plus on peut cacher la latence des accès mémoires)
4/ben la CUDA zone donne un bon apercu...je l'utilise pour du rendu par lancer de rayons, mais des gens l'utilisent en dynamique des fluides, en electrodynamique, en rayonnement, ... en gros, dès que c'est intensif et qu'on veut plein de résultats d'un même calcul de base.
les algos qui en tirent le plus parti
*parce qu'il y en a toujours, loi 1 de l'humanité ^^