Discussion :

[poukill]

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!!

[themadmax]

Le traitement d'image temp réel en C++ est possible, cela depand de la taille de la video a analysé et aussi de la complexité de ton traitement. Parfois il faut ecrire des algo en ASM pour optimisé (si cela est possible). Le nouveau truc à la mode est aussi d'utilise le GPU.
Pour ce qui est de l'affichage il existe des lib portable (SDL). Mais il faut savoir que l'affichage prend boucoup de temp, et il faut parfois utiliser des outils plus pres de la machine ( DirectX, OpenGL...)
Je crois pour un projet d'une durée longue, il est difficile d'estimer la rapidité du code. Fait rapidement des maquettes de ton prog pour savoir si l'ordre de gradeur est acceptable.

[JolyLoic]

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.

[poukill]

Pour l'instant, je n'ai aucune idée des traitements à effectuer.
C'est sur que dans un premier temps, je vais plutôt m'occuper des algos à développer...

Le but ici est de voir quels sont les outils qui peuvent être à ma disposition.
J'ai déjà utiliser un peu la SDL, mais pas Qt, ni WxWidget.

Pour le temps réel, une lib pas trop gourmande serait la bienvenue!
A moins que le GPU prenne le relais. J'imagine que pour l'affichage graphique, l'utilisation du GPU serait un plus, mais est-ce différent alors comme manière de programmer?

Merci !

[poukill]

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.

D'accord Loïc pour la séparation traitement et affichage.

Ensuite, je ne pense pas être dans le temps réel pur, à compter le nombre de cycles de calcul... Je pênse que le temps réel mou fera l'affaire, je ne suis pas à la milliseconde...

[Mat.M]

Tu parles de SDL je trouve cette API très lente voire plus par rapport au simple GDI parfois sous Windows.
SI tu veux des performances faut accèder à des API natives comme Direct X ou simple GDI sous Windows je ne recommande pas trop les "wrappers"
Et puis l'OS a son importance comme le dit Loic Joly.
Vaut mieux un OS véritablement temps réel comme par exemple QNX

[buzzkaido]

Moi je dirais comme les autres :

- si tu as une contrainte forte sur le temps réel => OS temps réel, y'a que ça

- si tu as une contrainte "molle" sur le temps réels => au mieux un linux specialement optimisé, au pire un windows spécialement optimisé (un minimum de services qui tournent...)

Dans le deuxieme cas, que tu soit sous windows ou linux :

- un processus haute priorité pour le traitement, avec des algos bien pensés, bien optimisés, avec pour les parties les plus critiques un peu d'assembleur

- un processus faible priorité pour l'affichage, si possible avec le choix entre 2 ou 3 tailles/qualités d'affichage (pour accelerer si besoin). Pour l'affichage, rien de plus simple et de plus rapide que le GDI (à mon avis) si tu souhaites uniquement afficher des images (pas de calcul 3D...)

En tout cas, si ton but est la vitesse et pas l'ergonomie, evites les grosses bibliotheques graphiques qui vont t'ajouter des centaines de lignes de codes dont tu n'as rien à faire pour avoir juste une fenetre avec une image et un bouton "start"

Dans tous les cas, rien ne t'empeche d'utiliser une carte à DSP pour booster le tout, ou alors d'utiliser les fonctions specifiques du GPU pour accelerer le traitement sur les images.

Par exemple (je suis pas à 100% sur, mais en gros) :
Mettons que dans ton traitement temps réel tu ai besoin d'appliquer un filtre 9x9 sur ton image, tu peux utiliser directX pour ça. Du coup, si la carte graphique sait appliquer des filtres 9x9, c'est elle qui va le faire, et c'est autant de ressources economisées sur le CPU....

[Mat.M]

Moi je dirais comme les autres :

- si tu as une contrainte "molle" sur le temps réels => au mieux un linux specialement optimisé, au pire un windows spécialement optimisé (un minimum de services qui tournent...)

Il faut un XP embedded ; sur un Windows normal c'est pas possible de faire tourner des services au minimum sinon l'OS va difficilement tourner correctement.
A faire le rapprochement avec un Vista excessivement gourmand

-

Par exemple (je suis pas à 100% sur, mais en gros) :
Mettons que dans ton traitement temps réel tu ai besoin d'appliquer un filtre 9x9 sur ton image, tu peux utiliser directX pour ça. Du coup, si la carte graphique sait appliquer des filtres 9x9, c'est elle qui va le faire, et c'est autant de ressources economisées sur le CPU....

eh non : l'intérêt de Direct X c'est si tu veux afficher une succession d'images très rapidement comme pour un jeu vidéo.
Si tu veux appliquer un filtre ce qui requiert du temps CPU et non carte graphique parce que tu ne sollicites pas la carte alors l'intérêt de Direct X sera quasi nul.
Pour appliquer un filtre sur des images il faut faire des calculs qui font intervenir de la trigo et autres ce que la carte graphique ne sait pas forcément faire...
je crois cependant qu'il ya quelques cartes graphiques qui peuvent calculer des transformations de Fourrier utilisées notamment pour la compression/décompression JPEG...
A chaque fois quand on pense Direct X ( voire Open GL) il faut penser carte graphique et accélération graphique.

[buzzkaido]

Ben moi je croyais que lorsque l'on utilisait des fonctions directX, ça utilisait au maximum les ressources matérielles (cartes d'acceleration), et que donc il suffisait de mettre une carte graphique qui booste et d'utiliser directX pour avoir des operations graphiques qui boostent...

Et puis des fonctions trigo pour des filtres ? plutot du matriciel, non ?

Les GPU ne savent pas faire de trigo ? comment ils calculent les rotations en 3d, alors ?

Enfin, j'disait ça comme ça, mais je ne m'y connait pas des masses en GPU.

Par contre, si tu cherches un peu sur le WEB, y'a different projets qui permettent d'utiliser les capacités des GPUs pour faire du traitement mathématique... en vu d'accelerer des calculs scientifiques, par exemples !

Et oui, parcque quoi qu'on dise, un bon GPU c'est puissant presque comme un CPU, et ça fait toujours des registres, des additionneurs, des multiplicateurs, des bus... en plus ! Autant les utiliser !

(au passage, y'a meme des essais pour utiliser la puissance de la carte graphique pour des logiciels de son : on envoit des samples audio dans la carte graphique, on lui fait faire des calculs dessus, on recupere le resultat... ça parait n'importe quoi, mais la carte ne triate que des données, elle ne fait pas de difference entre audio et image, et comme des GPU font des FFT, par exemple...)

Bien sur, tout ça ne sert à rien si t'as une carte graphique à 20 euros... mais dans le cadre d'un setup particulier pour u projet particulier, autant bien choisir son matériel !

[Charlemagne]

Je prends la conversation au rebond...

Est-ce que quelqu'un connait des tutoriels/exemples de programmation GPU? (en particulier la FFT et la multiplication de matrices).
Quelqu'un a-t-il des benchmarks? (histoire de comparer CPU et GPU)

[HanLee]

Tu connais ce site http://www.gpgpu.org/ ?

Une comparaison, par exemple (trouvée sur le site) : http://gamma.cs.unc.edu/LU-GPU/

[Mat.M]

Ben moi je croyais que lorsque l'on utilisait des fonctions directX, ça utilisait au maximum les ressources matérielles (cartes d'acceleration), et que donc il suffisait de mettre une carte graphique qui booste et d'utiliser directX pour avoir des operations graphiques qui boostent...

Et puis des fonctions trigo pour des filtres ? plutot du matriciel, non ?

Oui tu as raison pour les calculs 3d mais pas pour les filtres.
Direct X ne sait en rien faire des calculs et utiliser l'accélération graphique pour tout ce qui est matriciel et filtres.
Direct X via Direct 3d ne sait que
*créer des objets 3d sous formes de sommets et plaquer des textures
*calculer les éclairages nécessaires
*afficher une scéne 3d
Pour exploiter les GPU il faut directement programmer en ASM ou bien utiliser des biblios pour.
Je crois que les derniers CPU de chez Intel ( j'ai dit CPU pas GPU ) ont des instructions ASM pour calculer par exemple des FFT.
Pas de mystêre pour optimiser tu seras obligé de passer par de l'ASM éventuellement ou bien prendre VTune d'Intel

Bien sur, tout ça ne sert à rien si t'as une carte graphique à 20 euros... mais dans le cadre d'un setup particulier pour u projet particulier, autant bien choisir son matériel !

Il y a peut-être certaines cartes graphiques professionnel et onéreuses qui permettent de traiter des images en temps réel

[Laurent Gomila]

Direct X ne sait en rien faire des calculs et utiliser l'accélération graphique pour tout ce qui est matriciel et filtres.
Direct X via Direct 3d ne sait que
*créer des objets 3d sous formes de sommets et plaquer des textures
*calculer les éclairages nécessaires
*afficher une scéne 3d
Pour exploiter les GPU il faut directement programmer en ASM ou bien utiliser des biblios pour.

Enfin, ça fait quand même un bail que :
- Les GPUs se programment, via les shaders (on peut donc leur faire faire beaucoup de choses autre qu'afficher des triangles)
- Les shaders ne se programment plus en ASM, mais avec des langages proches du C

[nicroman]

En fait un GPU ne fait rien de tout ca vraiment:
* créer des objets 3d sous formes de sommets et plaquer des textures
* calculer les éclairages nécessaires
* afficher une scéne 3d

Un GPU est un CPU optimisé pour le calcul matriciel (4x4 dimensions) en flottant.
Jusqu'à DX7 ce calcul se limitait a des opérations fixes.
Depuis DX8 (et je ne parle pas de DX10), ces calculs sont entierement programmables.

Ensuite, que les données sur lequelles portent le calcul soient des coordonnées spatiales, des couleurs de texture, ... c'est juste un type d'utilisation.

Il existe aussi une autre partie du GPU très interessante: le rasterizer... un truc qui sait automatiquement découper une ligne (ou un triangle) en petits bouts avec une division gratuite au passage

En même temps, une fonction trigonométrique n'est ni plus ni moins qu'un produit vectoriel (sin) ou un produit scalaire (cos). Mais il faut penser au problême mathématique sous forme géometrique pour bien s'en rendre compte.
Et toutes les cartes graphiques sont des brutes en produits scalaire.

On pouvait déjà faire une simili FFT avec un simple plaquage de texture à l'époque de DX7, sans shader.

Maintenant avec les shaders (surtout unifiés), c'est encore plus simple.

Le seul inconvéniant, c'est récupérer les informations... RAM->GPU se fait très très vite, mais l'inverse est une véritable horreur ! Genre, 80ms juste pour récupérer un buffer !
Autant dire que c'est inacceptable pour du temps réel. A moins que le seul but soit d'afficher les données à la fin, auquel cas, il suffit de ne pas sortir de la carte graphique

[poukill]

Tout d'abord merci à tous pour vos réponses...

Si je dois résumer vos remarques, je dirai dans mon cas:

1) Je suis dans du temps réel mou, avec des contraintes de temps pas encore trop bien définies. Le dévelloppement pourra être sous Windows, par contre je dispose de puissantes machines qui tournent sous Unix pour l'exécution...
-> Le Programme doit donc être portable (i.e les librairies aussi)

2) Cela éliminerai donc les lib graphiques natives de Windows. Qt ou SDL avec un processus de basse priorité serait-il une bonne solution?

3) Vous me conseillez de laisser la partie affichage à la carte graphique, en utilisant au max le GPU...

4) La gestion des processus : avec Boost par exemple???

Merci à tous encore pour votre aide !

[Charlemagne]

Tu connais ce site http://www.gpgpu.org/ ?

Une comparaison, par exemple (trouvée sur le site) : http://gamma.cs.unc.edu/LU-GPU/

Merci.
Oui, j'ai trouvé ce site juste après avoir posté mon message. Il semble que ce soit le site de référence pour la programmation GPU. J'ai survolé quelques docs, c'est intéressant, mais en tant que débutant la dedans la quantité d'information fait un peu peur...

Je connais pas bien l'algorithme LU, ni l'implémentation qui en a été faite dans ATLAS. Je connais bien mieux l'implémentation de multiplication de matrice d'ATLAS, ou l'implémentation FFTW. Bref j'ai encore du mal a me faire une idée des perfs des GPU.

Sinon, on m'a vanté l'outil suivant, comme étant le "meilleur actuellement"
http://graphics.stanford.edu/projects/brookgpu

J'accepte tout tutoriel/exemple/conseil pour m'initier aux GPU... Merci

[JeitEmgie]

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!!

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)


… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…

[poukill]

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)


… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…

Je sais bien que ma question est vague...
Cependant, les réponses qui me sont apportées ici me sont très utiles pour éliminer des pistes.
Le projet ici est beaucoup plus conséquent que tout ce que j'avais vu à présent. Je pars de pas grand chose (bcp à défricher !!), et mes connaissances en développement sérieux et propre restent largement à parfaire, notamment sur du temps-réel (mou ici) multi-tâches

Beaucoup d'habitués ici connaissent bien que moi les outils disponibles, ainsi que les différentes façons d'attaquer mon problème.

Je peux quand même donner plus de précision :

image : 320 * 240
Période d'échantillonnage : 20 ms
Durée du film : 30 secondes environ

La détection d'événements anormaux (algos pour l'instant complètement indéfinis, c'est le but du projet) devra permettre de stopper l'expérience (asservissement sur un circuit physique)

Voilà, j'espère être plus précis!

[Mat.M]

- Les shaders ne se programment plus en ASM, mais avec des langages proches du C

Oui je sais c'es le C graphique mais je voulais parler d'optimisations des calculs en ASM pas parler de programmer directement la carte

[poukill]

Juste une dernière question alors:

Quelle méthode utiliser pour du Multithreading (un processus pour l'affichage, l'autre pour les calculs), afin que le code soit portable?
Boost est-il une bonne idée?

Merci