[Open-source][C++/GLSL] GLIP-Lib, API de traitement d'image sur GPU.

Bonjour à tous,

• Nom : OpenGL Image Processing Library (GLIP-Lib)
• Version : 0.7 (en cours de développement vers 0.8)
• Langue : Anglais (mais je peux assurer de l'aide en Français)
• Description : Librairie simple pour construire des pipelines de traitement d'image sur GPU avec OpenGL (>2.0) et GLSL.
• Compatibilité : GNU/Linux (en cours de tests sur Windows, le code est générique et devrait s'adapter à toutes les plateformes disposant d'OpenGL et des extensions nécessaires).
• Nécessite : OpenGL (>2.0), GLSL, un GPU relativement récent (ex : 8800 GTX chez NVidia), CMake pour la compilation, Qt pour les interfaces des exemples.
• Site et Documentation en ligne : http://glip-lib.sourceforge.net/index.html
• Téléchargements : https://sourceforge.net/projects/glip-lib/files/ (préférez le dépôt Git pour le moment)
• Langages : C++/GLSL
• Sources : Disponibles sur Sourceforge : https://sourceforge.net/scm/?type=git&group_id=363201

Le but de cette API est de proposer un ensemble d'outils permettant de construire rapidement un pipeline de traitement de l'image sur architecture GPU, qui soit à la fois portable entre GPUs de différent constructeurs et différents systèmes d'exploitation. Les techniques mises en place relèvent du GPGPU en tirant parti des performances et des optimisations d'un GPU (en utilisant les primitives définies par OpenGL) et en vaforisant ainsi le débit de traitement des flux vidéos (notamment Full-HD). Je n'ai pas voulu forcer l'utilisation ni d'OpenCL, ni de CUDA pour rester au plus près de la gestion "graphique" d'un GPU et d'utiliser les souplesses de gestions proposées par OpenGL (filtering de textures, création automatique de mipmaps, opération de blending, etc.). Il sera cependant bientôt possible d'interfacer du code des ces deux APIs directement depuis un filtre de GLIP-Lib et donc de bénificier d'un évantail d'opérations encore plus large (FFT...).

L'API ne propose pour l'instant que quelques filtres et algorithmes usuels tels que Sobel, Histogrammes, Flou. Il est cependant extrêmement simple d'écrire de nouveaux filtres à partir des spécifications du langage GLSL. Vous pouvez aussi partager vos pipelines avec le projet, je pense créer une bibliothèques sur le site pour l'upload/download de ceux-ci.

Ces pipelines peuvent être à la fois décrit "en dur" dans le code mais aussi chargés depuis un fichier de script en suivant la documentation fournie sur le site. Il devient alors facile de prototyper un pipeline puisque la compilation des Shaders (les programmes de transformations) est effectuée juste avant l'utilisation de ceux-ci, par le driver afin d'assurer une compatibilité et un niveau d'optimisation au plus haut pour le matériel cible et ce processus est indépendant de la compilation du programme en C++.

Les futurs travaux prévus :

• Identification et test des extensions d'OpenGL nécessaires. <en cours>
• Test du mode de transfert rapide CPU/GPU avec des PBOs.
• Développement d'un logiciel graphique pour designer les pipelines.
• Ajout d'outils de diagnostique aux performances. <en cours>

Cordialement,

Intéressant. Je regarderai ça en détail plus tard.

Comment réalises tu la récupération des images modifiées ? Avec glReadPixels ou glGetTexImage ?
Tu as réalisé des benchmarks pour les performances ? Prévu des outils de profiling spécifique pour tester ?

Tout d'abord, merci de votre intérêt.

Pour les images modifiées, j'utilise un simple glGetTexImage, mais je prévois de revenir aux PBOs. Le problème du rapatriement des textures est vraiment le point noir puisque pour maximiser la bande-passante entre la RAM et la VRAM (dédiée au GPU) il faut trouver exactement le bon format utilise par le driver pour stocker les textures. De part mon expérience, j'ai vu des taux de transferts CPU->GPU plafonner a la limite du bus (entre 2.7 et 3Go/s dans mon cas) alors que les retours, en choisissant un format qui "arrange" l'application mais pas le driver, étaient plutôt de l'ordre de 500Mo/s. En utilisant bandwidthTest, un exemple/benchmark de CUDA, on peut vérifier que le bus est bien bi-directionnel et que le rapatriement est donc limite par la conversion de format. J'ai une nouvelle "piste" de format pour du hardware NVidia qui permettrait peut-être de quadrupler ce débit en évitant l'étape de conversion, j'espère pouvoir le tester rapidement.

Il n'y a pas de benchmarks pour le moment. C'est bien entendu prévu mais j'attends de pouvoir vérifier que le code est stable, conforme a la norme d'OpenGL et qu'il n'y ait pas d'opérations superflues. Je suis aussi entrain de parcourir l'OpenGL Registry pour découvrir des extensions ouvrant de nouvelles possibilités. Par exemple, GL_ARB_geometry_shader4 pourrait permettre des opérations de type "scatter" (pour des applications comme la transformée de Hough pour la reconnaissances de formes), GL_ARB_get_program_binary pourrait permettre d'éviter la recompilation des programs par le driver, GL_ARB_shader_atomic_counters permettra d'accéder a des variables globales accessibles en lecture et en écriture a tous les instances de programs, GL_ARB_debug_output pour tester le comportement général de la bibliothèque vis-à-vis du driver et d'OpenGL.

Enfin, je n'avais pas penser aux outils de profilages pour l'efficacité (temporelle) des shaders. Je vais l'ajouter a la liste des choses a faire, merci beaucoup! Pour ce qui est des connections et des architectures, le moteur qui optimise l'exécution des pipelines et leur empreinte mémoire est capable (en théorie, en cours de test) de détecter les erreurs et de lever une exception auquel cas. Ce mécanisme n'est donc disponible qu'a la création d'un vrai pipeline et pas d'un "layout".

Edit : 21 Janvier
Pour l'exemple de l'affichage d'histogramme qui est présenté sur la page principale, je serais de l'ordre de 1.6 milliseconde pour une image 1920x1200 RGB 8bits sur une NVidia GTX 280M (pour ordinateurs portables donc). Pour appliquer l'équivalent d'un filtre de Sobel 3x3 (je calcule en fait les dérivées secondes dans toutes les directions, ce qui est à mon avis plus lent), indépendemment sur chaque canal et de recombiner un résultat en niveaux de gris, cela prend entre 0.3 et 0.5 milliseconde sur la même architecture, pour le même format. Pour faire la mesure, je fais une moyenne sur 100 itérations consécutives, sans pause entre elles et avec des glFlush pour mesurer le temps mis par chaque filtre composant le Pipeline. J'ai tendance à penser que c'est la pire des situations pour le driver. Pour ce qui est de l'écart entre le premier et le deuxième filtre, je voudrais rappeler que le premier filtre utilise comme support une grille de 2.3M points pour pouvoir contrôler la position du résultat grâce au Vertex Texture Fetching (j'avais expliqué cette procédure dans un petit document PDF qui est téléchargeable depuis la section Files du projet sur SourceForge), ce qui est un processus extrêmement lourd et qui est répété trois fois (une fois par canal R/V/B).

J'en profite pour ajouter que je serais reconnaissant d'avoir des retours sur des difficultés d'utilisations, notamment de compilation sur d'autres plateformes. C'est un des points qu'il m'est difficile de gérer et dont j'ai très peu d'expérience pour le moment. Toute suggestion est aussi la bienvenue.

Cordialement,

Bonjour à tous,

La bibliothèque est toujours en cours d'évolution. Après des corrections de bugs mineurs et ajouts/améliorations de quelques fonctionnalités, je prépare le port sur la plateforme Windows 7. Le code en lui même est globalement générique, je n'ai pour l'instant pas de changement à enregistrer, en revanche, les gros points se situent autours des outils de génération du code. Pour l'instant, j'utilise le compilateur MingW.

Pour tester les capacités de GLIP-Lib, j'ai porté une petite application de démonstration depuis GNU/Linux sur Windows. Cette application est téléchargeable à cette adresse : http://sourceforge.net/projects/glip...t.zip/download.

Elle permet de charger un pipeline depuis un fichier et de l'appliquer à une image (RGB + 8 bits). Elle permet d'explorer les différentes sorties du pipeline et de les sauvegarder (le type de l'image est défini par l'extension que vous lui donnez, tout cela est géré par la couche Qt).

Captures d'écrans :
Image originale :

http://www.developpez.net/forums/att...1&d=1328136845

Résultat d'effet_1.ppl :

http://www.developpez.net/forums/att...1&d=1328136845

Image originale :

http://www.developpez.net/forums/att...1&d=1328137164

Résultat d'effet_1.ppl :

http://www.developpez.net/forums/att...1&d=1328137943

Résultat de writingTest.ppl :

http://www.developpez.net/forums/att...1&d=1328137943

Vous pouvez, bien-sûr, écrire vos propres pipelines en vous aidant de ces exemples et de la documentation disponible ici : http://glip-lib.sourceforge.net/ (section Pipeline scripts) et de la documentation du langage GLSL : http://www.opengl.org/documentation/glsl/.

N'hésitez pas à me contacter pour tout problème que vous pourriez rencontrer.

Cordialement,

Bonjour à tous,

GLIP-Lib passe en version 0.8.

• Meilleur gestion des formats de textures pour OpenGL.
• Possibilité de lire depuis des textures compressées (il n'est pas possible de faire un rendu dans une texture compressée).
• Connection automatique à l'intérieur des pipelines via analyse des noms des variables d'entrées/sorties des textures et des ports du pipeline (l'ancien mode de connection peut toujours être utilisé cependant).
• Module TextureCompressedReader, pour lire une texture compressée (depuis le GPU vers la RAM).
• Module TextureCopier pour faire des copies entre textures, via un PBO (peut être utilisé pour compresser/décompresser)
• Modules FFT1D et FFT2D, avec possibilité de recentrage du résultat, transformée inverse, zero-padding à la volée.
• Ajout des mots clefs REQUIRED_FORMAT et REQUIRED_PIPELINE pour pouvoir développer des élements dynamiques : l'application fournit le format qui sera utilisé par ce futur pipeline.
• Correction de bugs mineurs.

La liste des exemples s'enrichit aussi avec, en plus d'ImageTest :

• TestGOL : un simulateur du Jeu de la vie. Les étapes sont intégralement calculées sur GPU.
• TestFFT1D : Application qui trace la transfromée de Fourier 1D d'une fonction et sa reconstruction via la transformée inverse.
• TestFFT2D : L'application reprend les bases de TestGOL et applique une transformée de fourier, puis un filtre passe bas, puis la transformée inverse; cela permet d'extraire une information sur la densité.
• Histogram : Application qui permet de tracer, en sur-impression de l'image l'histogramme des canaux R-V-B de celle-ci.
• TestVideo : L'application permet de charger une vidéo, grâce à l'API Phonon de Qt, et d'appliquer un Pipeline sur celle-ci. L'exemple est fournit avec une implémentation très simpliste de l'algorithme Lucas–Kanade pour l'estimation du flot optique.

Captures des différents programmes :
ImageTest :

http://glip-lib.sourceforge.net/img/screenImage.png

Histogram :

http://glip-lib.sourceforge.net/img/screenHistogram.png

TestFFT2D :

http://glip-lib.sourceforge.net/img/screenFFT2.png

TestVideo :

http://glip-lib.sourceforge.net/img/screenVideo.png

Séquence tirée de Big Buck Bunny, animation sous license Creative Commons, www.bigbuckbunny.org/

Les binaires de tous ces exemples sont disponnibles pour les plateformes Windows à cette adresse : https://sourceforge.net/projects/gli...iles/Examples/.

Pour l'instant, mes tests n'ont porté que sur des cartes NVidia et un Intel Core I7 de deuxième génération (I5-2430M avec Intel HD Graphics 3000. Attention toutefois, sous Linux, Mesa requiert le mode de compatibilité; vous trouverez plus de détails dans la documentation en ligne de la librairie).

Je recherche donc des personnes volontaires, pouvant les tester sur des cartes AMD/ATI. Il suffit pour cela de télécharger les examples depuis la page précédante et de les lancer. Chacun va produire un fichier log.txt que vous m'envoyer ou le reposter ici

UPDATE : Les exemples basiques (TestGOL, TestFFT1D, TestFFT2D) sont fonctionnels, sur les anciennes plateformes AMD/ATI apres ajouts de l'instruction suivante dans tous les shaders (fichiers glsl et dans les pipelines ppl) et du remplacement de tous les textureLod par des texture. Ce test a ete réalisé sur la plateforme suivante : ATI FireMV 2260, Win7 x64, Drivers 8.982.2. Les exemples ImageTest et Histogram ne permettent que de charger un nombre restreint de formats incluant PNG et BMP mais PAS JPEG (mauvaise gestion des plugins Qt). Si vous n'avez pas le SDK de Qt (ou VLC?) il est possible que le programme TestVideo s'arrête brutalement lors de la recherche des codecs disponibles.

Tout retour, suggestion, difficulté d'utilisation, de compilation, d'installation ou de rapport de bug mais aussi d'information de test sur votre matériel sont donc les bienvenus.

Cordialement,

Testé sous XP ca ne fonctionne pas.
Réponse :
windows rendering.cpp; 42 : windows renderer::windowsrenderer - error while creating geometry
hdlGeBO.cpp; 45 OpenGL extension GLEW_ARB_pixel_buffer_objects is required but not avaible on hardware or driver

Semble fonctionner sous Seven par contre pas pour des images jpg, étrange

Merci pour votre contribution!

Pour le message d'erreur sous Windows Xp, comme il le spécifie, il s'agit d'une erreur de compatibilité avec le driver de la carte graphique. Il est aussi possible que l'extension soit manquante/incompatible avec la carte (vieille carte graphique ou du cas d'un PC portable). Mettre à jour le driver peut régler le problème. De quelle carte graphique s'agit-il?

Pour le chargement d'image en JPEG, c'est un bug connu auquel je n'ai pas encore trouvé de solution (il vient d'une mauvaise configuration du projet avec Qt et non de la bibliothèque en elle-même).

Cordialement,

Bonjour,

Je publie une nouvelle version de GLIP-Lib : v0.9. Celle-ci apporte de nombreuses nouveautés s'ajoutant à une restructuration importante du code (mais pas des interfaces).

• Meilleure accessibilité aux variable uniforms, pour effectuer des modifications de paramètres durant l’exécution d'un Pipeline.
• Sauvegarde/restauration de profiles, contenant les valeurs de ces variables.
• Possibilité de déclarer des géométrie depuis les fichier de Scripts, jusqu'à des géométries personnalisées.
• Amélioration du langage de Scripts, de la gestion des ressources et des erreurs.
• Amélioration de la documentation et des exemples fournis (http://glip-lib.sourceforge.net/pages.html).
• Améliorations des interfaces disponibles avec Qt (hors de la librairie).

Mais le plus important est la première version de GlipStudio, l'IDE de GLIP-Lib. Cet outil permet de développer et tester des Pipelines, et de sauvegarder les images traitées, les paramètres utilisés et bien-sûr, le code de ces Pipelines au sein d'un environnement complet.

Télécharger Glip-Studio pour Windows x64.
Pour les distributions Linux, suivez les instructions de cette page.

Visitez la Documentation de GLIP-Lib

http://glip-lib.sourceforge.net/imag...io_4_small.png

Posez vos questions, les problèmes que vous pourriez rencontrer suite à des bugs ou des difficultés d'utilisation et vos suggestions d'améliorations sur la mailing list : http://sourceforge.net/p/glip-lib/mailman/.

Cordialement,