Limite d'un GPU [Résolu]

[GLSpirit]

Bonjour à tous,

J'aimerais réaliser une application effectuant des calculs ( recherche opérationnelle) sur un GPU (nvidia 8800) .
Avant de me lancer dans un dév laborieux, j'aimerais connaître les limites liées au traitement GPU dans ce cas de figure ( dsl si je suis un peu vague sur la finalité de mes dév. ).

Par limite, j'entends limite en terme de fonctionnalités ( traitement impossible à effectuer, traitement inadapté en terme de temps d'exec ... ) , de ressources etc ...

Je m'en réfère donc à votre expérience personnelle, votre vécu, afin de résoudre cette problématique.
Cela pourra me permettre de compléter les avis, opinions d'experts, passionnés avec une recherche sur le net("Google is your friend").

Thanks

[raptor70]

Je n'ai pas trop d'avis la dessus... manque d'expérience ... mais tu veux utiliser les librairies graphiques ( OpenGL et D3D ) ou faire directement du très bas niveau ?

[Ti-R]

Pareil je suis pas expert, mais tu peux regarder du côté de CUDA.
Bibliothèque de NVidia qui est dédié principalement aux calculs sur GPU.

[shenron666]

un GPU c'est massivement parallèle, la première limite qui se présente à mes yeux c'est donc de "simplifier" le traitement à quelque chose de massivement parallélisable pour obtenir un gain dans l'utilisation du GPU

tu envisages l'utilisation de CUDA avec ta 8800 ?
ou tu pars sur du GLSL ? du HLSL ?

[Bakura]

Même s'il y a eu pas mal de progrès sur ce sujet, les GPUs, même récents, ont beaucoup de mal avec les boucles et les branchements conditionnels...

[Laurent Gomila]

Je pense que le seul moyen de savoir exactement ce que tu pourras faire est d'étudier la documentation de CUDA. Sinon ça va rester très vague.

[Kurisu]

Il y a aussi le projet GPGPU qui va dans le même sens que CUDA, ainsi que la lib Sh qui me semblait offrir qqs possibilités dans ce domaine.

Sinon, du côté livre, les ShaderX (à partir du 5, je crois) et GPU Gems (2 et 3) contiennent des chapîtres en traitant.

[GLSpirit]

Envoyé par shenron666

un GPU c'est massivement parallèle, la première limite qui se présente à mes yeux c'est donc de "simplifier" le traitement à quelque chose de massivement parallélisable pour obtenir un gain dans l'utilisation du GPU

tu envisages l'utilisation de CUDA avec ta 8800 ?
ou tu pars sur du GLSL ? du HLSL ?

Je souhaite à priori utiliser CUDA et faire un maximum de traitement en parallèle.
Je ne connais ni GLSL ni HLSL car je n'ai pas encore faire de dév en OpenGl, CUDA etc ...

J'en suis au stade expérimental et essaie de savoir si mon appli en RO (recherche opér.) serait programmable ou en partie programmable sur un GPU.

Je vous remercie pour ces info.

[Mat.M]

Envoyé par GLSpirit

J'en suis au stade expérimental et essaie de savoir si mon appli en RO (recherche opér.) serait programmable ou en partie programmable sur un GPU.

Je vous remercie pour ces info.

A quoi va te servir la programmation GPU ?
La programmation GPU c'est bon pour faire du rendu graphique temps réel des objets 3d des bitmaps...
ce qui n'est pas le cas de la recherche opérationnelle il me semble..
Si ce que tu veux afficher à l'écran nécessite beaucoup de calculs je ne pense pas que la programmation GPU sera vraiment utile...
Parce qu'un CPU central est bien plus sophistiqué qu'un GPU.

le GPU est costaud pour faire beaucoup d'operations vectorielles en parallele. ca peut etre interessant, surtout que pendant ce templs le CPU est libre pour autre chose.

[shenron666]

Envoyé par Mat.M

A quoi va te servir la programmation GPU ?
La programmation GPU c'est bon pour faire du rendu graphique temps réel des objets 3d des bitmaps...
ce qui n'est pas le cas de la recherche opérationnelle il me semble..

les GPU ont beacoup évolué depuis les première geforce
aujourd'hui avec un GPU, on peux faire de l'IA, du calcul de prévisions météo, de la physique, des calculs de fluides, ect

Envoyé par Mat.M

Si ce que tu veux afficher à l'écran nécessite beaucoup de calculs je ne pense pas que la programmation GPU sera vraiment utile...
Parce qu'un CPU central est bien plus sophistiqué qu'un GPU.

et un GPU bien plus spécialisé qu'un CPU
si tu as énormément de calculs à faire, que ceux-ci sont répétitifs, et compatibles avec un système scalaire, le GPU peut être 10x plus rapide que qu'un CPU
avec CUDA par exemple, nVidia a réécrit son compresseur de textures
ça n'affiche rien à l'écran, ça fait juste les calculs de compression, et c'est 10x plus rapide que le programme qui utilise le cpu

avec leur puissance grandissante, dans un futur proche les GPU vont intégrer les supercalculateurs pour les aider dans les calculs scientifiques complexes
pour exemple, un PC équipé de 8 GPUs équivalent à un supercalculateur de 2005 avec 512 CPUs :
http://www.tgdaily.com/content/view/37715/113/

[Mat.M]

Envoyé par shenron666

les GPU ont beacoup évolué depuis les première geforce
aujourd'hui avec un GPU, on peux faire de l'IA, du calcul de prévisions météo, de la physique, des calculs de fluides, ect


et un GPU bien plus spécialisé qu'un CPU
si tu as énormément de calculs à faire, que ceux-ci sont répétitifs, et compatibles avec un système scalaire, le GPU peut être 10x plus rapide que qu'un CPU

D'accord mais l'auteur de ce post, GLSpirit qu'est ce qu'il a à afficher de précisément ?

Il me semble que la recherche opérationnelle d'après le peu que je connaisse et mes vagues souvenirs de cours de BTS Info que j'ai eus c'est essentiellement à base d'algorithmes et d'arbres binaires gener Djikstra..
Est-ce que le langage des GPU par exemple HLSL est-il assez performant et l'architecture de ce genre de technologie assez évoluée pour ce genre d'opération ?
J'ai sous les yeux le SDK de Direct X et la référence de HLSL cela me semble relativement limité ,reste à voir ce que veut faire GLSpirit précisément..

[LeGreg]

Envoyé par Mat.M

D'accord mais l'auteur de ce post, GLSpirit qu'est ce qu'il a à afficher de précisément ?

La programmation générique sur GPU (GPGPU) n'a rien de graphique à part l'utilisation d'un processeur autrement vendu comme processeur graphique pour ses calculs.

La dernière génération de processeurs professionels Tesla de Nvidia (qui embarque des G80 en interne tout comme sur la geforce 8800) est vendu sans sortie vidéo (pas de connecteur VGA ou DVI). Parce que son but n'est pas d'afficher des choses mais de faire des calculs complexes.

Envoyé par Mat.M

Il me semble que la recherche opérationnelle d'après le peu que je connaisse et mes vagues souvenirs de cours de BTS Info que j'ai eus c'est essentiellement à base d'algorithmes et d'arbres binaires gener Djikstra..
Est-ce que le langage des GPU par exemple HLSL est-il assez performant et l'architecture de ce genre de technologie assez évoluée pour ce genre d'opération ?
J'ai sous les yeux le SDK de Direct X et la référence de HLSL cela me semble relativement limité ,reste à voir ce que veut faire GLSpirit précisément..

On ne parle pas de HLSL déjà mais de Cuda, un langage proche du C avec des extensions orientées calcul parallèle qui est compilé pour tourner sur le processeur d'une carte graphique.

Cuda est suffisamment évolué pour accélérer les calculs sur des matrices de taille imposante, être utilisé pour évaluer les risques dans la finance (et par ici), accélérer la simulation des fluides, améliorer la qualité et la vitesse de la reconstruction tomographique (à partir de projections) (également par ici), la prospection (pétrolière, minière et évaluation de sites pour enfouissement de déchets), le repliement de protéines etc.

Bref plus les gens veulent faire de calculs compliqués plus ils ont intérêt à regarder dans les algorithmes parallèles. Et c'est une tendance forte, l'accroissement de la puissance de calcul disponible va entrainer la création de nouveaux besoins en calcul etc..

Tous les algorithmes ne sont pas accélérables par des unités de calcul parallèle, notamment ceux qui ont une forte composante séquentielle (loi d'amdahl) mais :
un calcul dont l'implémentation séquentielle met un temps non négligeable à s'éxecuter mais qui a une alternative parallèlisable, meme si elle parait moins efficace sur le papier (en terme de nombre total d'opérations à réaliser), peut y gagner. Auparavant la tendance pour paralléliser était la création de clusters (ordinateurs identiques reliés en réseau), dans le présent et le proche avenir il y a une tendance à accroître également le nombre d'unités de calcul sur le meme support ("processor dice") ce qui en diminue les coûts.

Boule de cristal : le nombre de cores et leur flexibilité va continuer à augmenter sur les GPUs, le nombre de core va augmenter sur les CPUs (de 2 à 4 actuellement à bientot 16 peut-etre 64 cores) et leur flexibilité ~ ?.

LeGreg

[LeGreg]

Addition : Un article très complet sur le sujet (AcmQueue, le journal de l'ACM) :

http://www.acmqueue.org/modules.php?...pid=532&page=1

LeGreg

[davidly]

Merci beaucoup pour le lien, de plus je ne connnaissais pas ce site.

Envoyé par shenron666

avec CUDA par exemple, nVidia a réécrit son compresseur de textures
ça n'affiche rien à l'écran, ça fait juste les calculs de compression, et c'est 10x plus rapide que le programme qui utilise le cpu

nous avons explosé la vitesse de compression DXTC sur un CPU (simple core) en C++. la qualité etait aussi plus elevée. c'est un comparatif proche du debat Java-C++, c'est a dire assez biaisé pour faire gagner celui qu'on aime le plus

[Ti-R]

Tout dépend du problème, et comment on l'aborde, mais on peut dire une chose, si on combine GPU + CPU, logiquement on devrait aller plus vite qu'avec 1 des 2 supports, ensuite c'est à GLSpirit de tester son algorithme et de le découper comme il le faut pour les 2 systèmes, en utilisant CUDA pour le GPU.

Chaque problème est différent, et dire que tel algorithme est plus rapide sous un CPU ou un GPU dépend largement des personnes qui implémentent (du type de problème aussi) ainsi que du matériel utilisé, tout doit rester comparable, des tests sur une 8800GT n'ont rien de comparable à ceux d'une 6800GT, idem pour un système mono-core ou octo-core.

Dur de répondre pour toi GLSpirit, il va falloir un moment "mettre les mains dans le cambouis" et tester par toi même !

[LeGreg]

Envoyé par screetch

nous avons explosé la vitesse de compression DXTC sur un CPU (simple core) en C++. la qualité etait aussi plus elevée. c'est un comparatif proche du debat Java-C++, c'est a dire assez biaisé pour faire gagner celui qu'on aime le plus

Hey screech, si tu as une implémentation plus rapide n'hésite pas à la soumettre dans cette discussion là bas :
http://developer.nvidia.com/forums/i...wtopic=13&st=0
l'outil de compression de texture tourne aussi sur CPU (et a été pas mal optimisé depuis son introduction) et son amélioration peut bénéficier à tout le monde.

LeGreg

[Mat.M]

Envoyé par LeGreg

On ne parle pas de HLSL déjà mais de Cuda, un langage proche du C avec des extensions orientées calcul parallèle qui est compilé pour tourner sur le processeur d'une carte graphique.

Désolé alors pour la confusion mais tout cela porte à confusion
et on ne sait toujours pas si cela peut profiter efficacement à la recherche opérationnelle.
Pour la Finance je veux bien mais pour peu qu'il yait des entrées sorties comme lectures/écritures bases de données...

[GLSpirit]

Magnifique !
Merci pour toutes ces info. et liens que je vais consulter de ce pas !

Envoyé par Ti-R

Dur de répondre pour toi GLSpirit, il va falloir un moment "mettre les mains dans le cambouis" et tester par toi même !

Oui malheureusement ... je vais devoir expérimenter un certain nombre de choses avant de me lancer dans le dév de mon appli.
L' objectif finale étant pour moi de réaliser une thése et si possible une publication ( on peut toujours rêver ) sur l'utilisation spécifique des GPU en IA / recherche op.

L'application que je voulais réaliser risque de prendre pas mal de temps en terme de dév.
Pour le moment, je me pose 2 questions :
1)Faisabilité : Es-ce que mon appli peut utiliser la puissance d'un GPU
2)Performance : Si oui, le gain en terme de performance sera-t-il intéressant

Pour le moment, je n'ai trouvé aucune publications, rapports sur ce que je désire réaliser (ce qui peut-être bon signe comme mauvais signe ...) .

Malheureusement, je n'ai pas beaucoup de temps de libre pour le moment car je bosse pour une grosse boîte informatique (Accenture)