Emporte Une Vache !!!

Farewell Blogger, here I come dotclear (ouf)

2006-11-06T23:28:00.000+01:00

J'ai enfin l'occasion (le temps) de migrer mon "blog" ailleurs, en un endroit plus sûr, mien, moins pénible et moins lourd...

Me voila ainsi à l'adresse suivante désormais :

http://www.touisteur.info/dotclear

au plaisir...

Touisteur au Caire

2006-09-07T17:14:00.000+02:00

Retour sur Cairo

J’ai repris l’Ada, après 6 mois de travaux forcés en Java (il faut bien travailler pour son diplôme). En jetant un regard neuf sur mon travail en Ada, je me suis rendu compte que j’avais pris de mauvaises approches pour beaucoup de projets… J’ai donc décidé de reprendre mes activités sur :

Cairo-Ada et l’intégration GtkAda

Un générateur de binding OpenGL/Ada automatisé

Mon parseur iCalendar

Et je me suis laissé tenter par beaucoup d’idées que j’ai commencé à implémenter avec plus ou moins de succès : binding Qt4, générateur automatique de binding C/C++… Sujets d’autres posts.

Le progrès le plus important pour l’instant est au niveau de Cairo, et son intégration à GtkAda. A l’époque j’utilisais gtkcairo, un widget C trouvé dans l’arbre de sources de cairo… où l’on pouvait récupérer une surface Cairo et dessiner dessus. J’avais bindé ce widget comme indiqué dans la documentation de GtkAda et j’étais assez satisfait du résultat. Mais il était totalement non portable, et surtout impossible à compiler sous windows… Et non maintenu. C’était une impasse, mais je m’en satisfaisais.

L’autre solution, celle explicitée dans cet article dans le GNOME Journal est qu’en GTK+ 2.8 il suffit d’appeler gdk_cairo_create pour récupérer une surface Cairo et dessiner dessus à l’intérieur d’un widget… Mais GtkAda était lié à la version 2.4 de GTK+…

Du nouveau sur GtkAda !

Récemment, j’ai appris que GtkAda était passé à la version 2.8, et bindait désormais la version 2.8.* de GTK+. Un grand pas pour l’humanité. J’ai donc facilement bindé les fonctions gdk_cairo* dans un package Gtk.Cairo_Integration. Ainsi, on peut désormais reprendre l’article et implémenter sans problème la partie Cairo et au lieu d’appeler en C :

gdk_cairo_create()

On notifiera au début de notre paquetage qu’on veut utiliser le package Gtk.Cairo_Integration :

with Gtk.Cairo_Integration;

Et pour récupérer la surface (dans le handler de l’événement Expose), il nous faudra déclarer une constante (une variable fera aussi l’affaire) de type Gdk_Window et récupérer le Gdk_Window du widget courant (l’exemple est sur Gtk_Drawing_Area) :

Win : constant Gdk_Window : Gtk.Drawing_Area.Window(Widget);
Cr : Cairo.Cairo_Object;
begin
Cr := Gtk.Cairo_Integration.Cairo_Create(Win);
-- do your drawing stuff
-- ...
Cairo.Destroy(Cr);

Rien de bien compliqué, et aucun dépaysement pour les développeurs Cairo/GTK+ existants. La même chose, dans un vrai langage :-D. Vrai, c’est un peu verbeux, mais Gtk.Cairo comme nom de package entrait en conflit avec Cairo (tout court), le nom du package du binding Cairo...

Le package Cairo_Integration est un binding du fichier gdkcairo.h et toutes les fonctions s’y trouvant sont bindées. Je travaille encore pour intégrer tout cela à la chaîne de compilation de GtkAda, afin de produire un patch utilisable.

Le gros problème désormais reste de nettoyer le binding Cairo… Il reste beaucoup de fonctions mal ou pas bindées, et surtout toute l’API est en un seul package/fichier… difficile à maintenir, mais je réfléchis à un découpage similaire à celui de la documentation mais j’ai encore quelques soucis avec la gestion des types et des packages enfant... Une solution viendra peut-être.

Une fois ce découpage effectué et les fonctions bindées correctement (il manque le binding des fonctions concernant SVG et libsvg par exemple…), je vais faire un patch pour les sources de GtkAda (je ferais un checkout avant) et verrais bien si Act le prend =o).

Mon grand espoir est de parvenir à porter la fameuse horloge de MacSlow ou de produire un widget de qualité graphique comparable.

Outils de travail avec Ada.

2006-09-06T22:32:00.000+02:00

Note : cet article date de Mathusalem et je doutais un peu de son intérêt, mais ça fait toujours du bien de rappeler qu'il y a des excellents outils en Ada et qu'il s'agit d'un langage extrêmement ouvert.

En réponse à une remarque désobligeante, voire trollesque, d’un ex-ema-C-sien qui perd la boule à faire du Cpp, je tiens à dire que les outils disponibles pour Ada sont nombreux.

Tout d’abord au niveau des éditeurs et IDE

On a d’abord Gnat Programming System (GPS), distribué par AdaCore. Environnement de développement tout intégré, il permet, au-delà de l’édition de code de bonne facture, de gérer des projets, de débugger en ligne, de visualiser les dépendances entre paquetages, entre types, etc… Il est extensible en python (il me semble) et dispose déjà d’un certain nombre d’extensions.

On a aussi XEmacs, l’outil presque ultime pour tout faire. Il dispose d’un mode Ada : coloration syntaxique, templates pour coller des blocs de code, indentation correcte, commentaires… Et j’en oublie sûrement, et je ne m’en sers sûrement pas assez bien pour savoir tout ce dont il est capable. Au-delà de ce mode Ada, on dispose de toutes les fonctionnalités d’emacs : recherche, remplace, buffer de compilation, des milliers d’options, découpage de l’écran à souhait (C-x 1 ou 2 ou 3). De même je suis sûr de passer à côté de certaines options. Mais l’environnement emacs est extrêmement riche pour le développeur, et le logiciel en lui-même est très stable, et je n’ai jamais aucune crainte de perdre des sources non enregistrées à cause d’un crash d’emacs.

On peut même trouver, et j’ignore si c’est installé de façon générique, un mode qui transforme emacs en IDE pseudo-GPS, avec plusieurs fenêtres à gauche de l’écran (parcours de répertoires, buffers ouvert, listes des fonctions/types/paquetages/tasks d’un fichier…). Cela s’appelle ecb il me semble. Très pratique quand un fichier source commence à gonfler en taille et qu’on n’a pas forcément envie de le découper « mieux » tout de suite…

Pour les malades du poignet et ceux qui veulent éviter un syndrôme du canal carpien et au passage perdre aussi en productivité (feeding the trolls), il y a aussi un mode Ada pour vim fonctionne bien aussi avec Ada, et il me semblait qu’à une époque KDevelop proposait vaguement de créer des projets Ada…

Aonix et Act, deux des plus grands acteurs du monde Ada se sont lancés dans la course au plug-in pour Eclipse. J'avoue être tenté aussi, bien que ce soit du Java... Mais ça me remettrait un peu dans les cours de compilation... hum... changeons de sujet...

En réalité, un éditeur avec coloration syntaxique est en général suffisant avec Ada, car la pièce maîtresse de la chaîne de développement Ada est pour moi le compilateur GNAT (je ne connais pas les autres). J'avais déjà fait l'apologie de ce compilateur, mais il ne cesse de m'étonner. Le refactoring n'est d'aucune difficulté avec GNAT. Modifiez, compilez, notez les erreurs, reportez les modifs au lignes où les erreurs ont été découvertes. 95% du temps c'est suffisant. Je ne travaille pas avec des projets de 1,5 millions de lignes de code, mais on m'a affirmé qu'avec un projet bien découpé et la compilation séparée (suprématie d'Ada !), c'était tout aussi agréable et simple. L'outil bienvenu serait plutôt lié à la complétion =o) mais là encore XEmacs fait un travail honorable.

Les quelques petites fonctionnalités supplémentaires valent-elle le bloat monstrueux d'Eclipse et l'investissement de 5000USD pour un simple plug-in ?

Les outils de compilation et test

GNAT est un excellent compilateur. Il passe les tests ACATS, est maintenu par certains des meilleurs experts en compilation et Ada (grand fan de Robert Dewar, ses explications sont toujours rayonnantes de concision et de richesse... ok je m'emporte mais quand même, chapeau), et supporte déjà une très grande partie des fonctionnalités d’Ada 2005, en avance.

Par contre, GNAT est désormais GPL (et non plus GMGPL) pour qui ne paie pas le support Act. Cela signifie qu’à moins d’utiliser une version Gnat Pro récupérée ou un Gnat-GCC. (GMGPL veut encore dire que le code est libre, donc copiable, récupérable, diffusable… c’est juste que la GPL rend GPL le code qu’on compile avec le runtime. GMGPL, ou la licence runtime de gcc veut dire que le runtime peut être utilisé sans causer le passage d’un code qui l’appelle en GPL.

Au-delà ce ça, Act livre aussi une version de gdb qui tourne avec GNAT. Avant GCC4.0 et le passage à Ada2005, on pouvait encore travailler avec le gdb de base de gcc, semble-t-il. En attendant que la transition soit terminée, on peut utiliser le gdb fourni par Act, ainsi donc que les outils graphiques qui vont bien, ddd et gvd.

Pour les tests de performance, gprof fonctionne bien avec GNAT, et oprofile est très pratique et peut annoter du code Ada (extrêmement pratique). J'ai déjà fait l'apologie de KCachegrind sur ce blog, alors je me retiendrai.

Les bibliothèques

On trouvera en Ada tout ce qu'il faut pour créer des interfaces graphiques, lire/écrire du XML, intégrer (oui intégrer) un serveur/client HTTP, client POP/Jabber/LDAP, et pour peu qu'on soit intéressé par des applications distribuées, on a le choix : l'annexe E d'Ada95 (génial) et un ORB CORBA (on aime ou n'aime pas, mais c'est disponible). Tout cela de façon portable, partout où GNAT est disponible.

Je passe sur les capacités de liaison vers les langages C, C++, Cobol, qui permettent de récupérer des anciennes bibliothèques et de les réutiliser (mot-clé en Ada), ou de se binder aux dernières nouveautés (Cairo par exemple, ou encore Qt4).

Ce qu'il manque

Ce n'est ici qu'un avis.

Je suis d'abord très très tenté par un générateur automatique de bindings. J'ai regardé et codé pendant quelques heures pour une sortie Ada et Swig paraît un bon point de départ. De mon côté je me penche sur une solution plus simpliste pour le C et le C++ (encore un projet perso jamais commencé jamais fini =oD).

Un plug-in Eclipse avancé avec complétion intéressante, intégrée à GNAT et ses conseils =o), liaison avec le C/C++ automatisée et transparente (il suffit de cliquer-déposer un .so avec les .h correspondants par exemple... aucune idée précise), des capacités de refactoring à la java, une gestion avancée du développement temps-réel embarqué, des assistants de code puissants permettant d'effectuer les opérations pénibles en un clin d'oeil. Et des aides pour l'utilisation de PolyOrb, l'intégration "transparente" de GNADE et tous ces outils qui font d'Eclipse un vrai environnement intégré dont on supporte la lenteur parce qu'il apporte tellement... Ah, évidemment open-source ce plug-in =oD. Que la communauté Ada puisse exprimer ses besoins en les développant =oD.

Cairo-Ada-Gtk... doesn't talk about beer

2006-09-06T21:40:00.000+02:00

Note : j'ai écrit cet article en février mais jamais pris le temps de le publier. Comme j'en prépare un autre sur Cairo, je me suis dit qu'un peu de contexte ferait du bien ^^.

Récemment (depuis 3-4 mois) je me suis intéressé à Cairo, parce que j’ai vu que GTK+/Gnome avait déjà migré dessus, et que les exemples pour faire des dessins étaient jolis et simple ET ressemblaient énormément à OpenGL. En plus - et c’est surtout ça qui m’enthousiasmait – Cairo était prévu pour être accéléré par la carte graphique et grâce à Glitz, être « posé » par-dessus OpenGL, un peu (mais pas exactement) à la façon de MacOS X (dites Ten, comme dirait un certain enseignant hype que je ne citerai pas).

Travail sur Cairo

L’API ayant l'air très simple à binder, j’ai voulu travailler en Ada, dans un environnement qui me plaisait (pas de C, pitié). J’ai réussi rapidement à binder toutes les fonctions nécessaires pour « porter » les snippets d’exemples disponibles dans la documentation de Cairo. Le binding est on ne peut plus simpliste, j’ai pris les types C, ai transposé les pointeurs en records nulls… et c’est tout. J’aurai pu (et du) aller plus loin, et proposer comme pour PyCairo ou rCairo, ou même Gtkmm (C++), une implémentation « orientée objet », mais la flemme et l’envie de coder par-dessus mon binding ont pris le dessus. Ce sera pour plus tard...

L’utilisation la plus courante de Cairo aujourd’hui est dans les interfaces graphiques (il est quasiment fait pour ça). Le problème étant que l’implémentation d’une UI à partir de Cairo la plus courante est GTK+. Du C. Et pas du C classique, « normal » et « assembleur de haut niveau »-like. Non, du C qui émule des fonctionnalités objet. Via les GObjects et autres jolies fonctionnalités. J’avoue qu’on finit par s’y habituer, mais lire le code source de GTK+, ce n’est pas une sinécure pour un débutant et/ou médiocre en C. Comme disait un de mes anciens collègues « c’est le genre de trucs qui doit bien marcher selon la doc et dans lequel tu dois pas à avoir à mettre les mains ». Les macros sont assez difficiles à suivre intuitivement (sans lire la documentation détaillée), et j’ai vite eu la tête qui explosait.

Pourquoi si dur, alors que tous les programmeurs Gnome et GTK+ y arrivent sans problème. Mais c’est que je n’ai pas dépareillé de mon idée de faire ce projet Cairo en Ada. Il fallait donc que j’insère Cairo dans GtkAda… La voie la plus simple eut été que GtkAda ait suivi l’API Gdk (on va dire une sous-couche de Gtk+), là où est implanté le lien Cairo. A priori, les développeurs de GtkAda sont restés à Gtk+2.6 ou inférieur, et Cairo a été ajouté à la 2.8.

Un widget maison...

Tant pis, dommage, recherche d’une autre piste. Avant de l’intégrer dans GTK, Cairo avait fait l’objet d’une implémentation dans un widget nommé GtkCairo, trouvable en fouillant sur le site de Cairo (décidemment, beaucoup de « Cairo » dans ce post…). Ne connaissant absolument rien de la façon d’écrire un widget en Gtk+ et encore moins en GtkAda, j’ai lu la doc et le code source de plusieurs widget GtkAda, et ai fini, par tâtonnements et segfaults successives (oui ça a beau être de l’Ada, quand on lie avec du C…) par obtenir :

un widget fonctionnel, sous la forme d’une horloge. Le fond provenant de l’article sur le GNOME Journal à propos de Cairo : Screenshot, Article
puis une autre horloge (provenant du tutoriel Cairo de GTKmm). Screenshot, Article
et enfin d’un widget d’animation d’attente infinie… alla MacOsX mais de loin… de Très Loin… Screenshot

Plusieurs problèmes alors : c’est LENT ! et ça prend toutes les ressources ! Et le code est pénible et lourd (pas factorisé, peu de fonctions, beaucoup de copier-coller « pour que ça marche »).

Au fur et à mesure que ma connaissance de GTK+ s’améliore, je mets un timeout bien plus raisonnable et apprends à ne redessiner que lorsqu’on a besoin… Et les horloges semblent beaucoup plus rapides. Tout va pour le mieux.

J’ai ainsi continué de m’enfoncer dans l’API Cairo et de la binder au fur et à mesure. Trop d’un coup et le découragement serait venu. Je ne bindais que ce dont je me servais (et en général, toutes les fonctions qui étaient autour).

Prémices d'appli de calendrier

Fort de mon « expérience » joyeuse et fier d’avoir implémenté un widget Cairo en Ada – pour être modeste « bindé du code C », j’ai commencé à développer ce qui m’intéressait. Un widget de calendrier/emploi du temps…

j’étais, et suis toujours impressionné par iCal
j’ai utilisé assez longtemps les journaux de KOrganizer/Kontact/KPim pour avoir décidé d’implémenter un début de lecteur iCalendar en Ada (sujet d’un futur post ?).
C’est simple à dessiner et à modéliser, et c’est très graphique et inspirant.
J’avais déjà quelques « mock-ups » d’interface… vraiment basiques et laids. Je les partage… Si quelqu’un arrive à en tirer autre chose qu’un bon rire

Après quelques heures/soirées de code, j’avais obtenu un premier jet, ressemblant peu à mes mockups… Je dirais presque "heureusement" La progression en quelques jours :

Le tout début : la grille, et les débuts d’eventbox. On voit les dégradés partout, l’alpha-blending et l’anti-aliasing en pleine action…
un jour plus tard, changé d’avis sur les dégradés trop poussés dans les event-boxes, ajouté des titres avec une couleur différente et un dégradé sur la police
quelques heures après, fait en sorte que les textes des titres rentrent toujours dans le titre des event-boxes (dommage que l’hyphénation ne soit pas gérée toute seule =o)). Désolé pour le blasphème, les paroles d’un morceau que j’écoutais à ce moment…
un meilleur choix de couleurs, encore un effort sur les polices (peu visible), et surtout refactoring important (la nuit dessus)...
10 jours plus tard, après une pause « aaaah je suis allé super loin dans un projet pour une fois, aaaaaah… » de découragement, j’ai décidé d’ajouter une méthode pour dessiner des info-boxes, pour décrire en contexte les événements… Pas si évident qu’il y parait. En fonction des coordonnées pointées, on doit choisir la base de la flèche, et une largeur sympa et éviter les angles droits… Bref, au bout de 3-4 heures d’arrachage de cheveux (manque de concentration surtout), on obtenait ce genre de petites boites.

En pause

J’ai mis le projet en pause depuis, entre autre par fainéantise, et aussi parce qu’un de mes camarades codeur fou s’est mis lui aussi à coder un calendrier en Qt… Très vite, très très très vite. Du genre à rendre mes progrès « fulgurants » de 2-3 semaines comme 20 minutes de travail pour lui =o). C'était vraiment du beau travail, avancé et joli... Du coup, j’ai reporté mon attention sur d’autres projets. D’autres projets dont je parlerai peut-être plus tard. =o).

Mais, en attendant, j’ai continué d’implémenter mon infobox vide, et sur un de ces autres projets jamais finis, ça donne quand même envie.

Le prochain article à propos de Cairo parlera des nouveautés et progrès au niveau du binding =o).

Six mois de cours^Wtorture (1/2)

2006-09-06T16:50:00.001+02:00

Long Time No See

Je n'avais pas posté ici depuis 1/2 siècle , le moment est venu de recommencer un peu. J'ai entre temps brouillonné quelques articles plus ou moins intéressants et je ne vais pas les jeter. Mais avant de poster tout cela, parlons un peu de mon activité durant ces 6 derniers mois...

Mon stage s'est plutôt bien terminé, mon travail a été considéré comme très satisfaisant et ma connaissance des shaders et des technologies 3D a fait un bond conséquent, ainsi que mes compétences en matière de développement, de réflexion et de conception... Le chemin reste long bien sûr. Pour ne rien gâcher, j'ai été très bien noté et rémunéré. Un très, très bonne expérience donc, et cerise sur le gâteau, en Ada...

Je m'étais promis de continuer le développement des projets que j'avais commencés en entreprise et personnellement en Ada : un binding OpenGL et un binding Cairo/GTK+. Le second recevra les honneurs de plusieurs articles très bientôt (le temps de la mise en page) et le premier un peu plus tard. Malheureusement, comme d'habitude mon enthousiasme a été quelque peu écrasé sous la masse de travail des études qui ont repris. J'ai rapidement mis de côté le plaisir du développement Ada personnel pour la "joie" du développement Java forcé.

Parce que voila, le dernier langage pour la pédagogie et pour simplifier les corrections d'exercices, c'est Java. Le thème global des trois projets Java à rendre était cependant toujours frais dans ma tête : Graphisme et Visualisation d'Information étaient à base d'OpenGL. L'un était un exercice de modélisation du campus de la fac' où j'étudie, et les deux autres consistaient en deux applications/composants de visualisation d'informations.

Je vais me contenter de parler du projet de Graphique, et continuerai au prochain article sur la Visu...

Le projet Graphique

La consigne était de modéliser un minimum de bâtiments de mon campus, les voies de circulation, des voitures pour s'y déplacer, un ciel et un sol, et des buttes à l'aide de courbes de béziers, une caméra qui va bien et quelques optimisations (graphe de scène...). Jusque-là, rien de bien pénible ou de surprenant. Le hic, c'est qu'il fallait utiliser Java pour s'interfacer avec OpenGL, via le désormais fameux JOGL. Ce dernier est une usine à gaz et a rendu le développement de ce projet extrêmement pénible et laborieux. La lenteur, la complexité induite par Java/Swing par rapport à une application Ada ou C++ correspondante a rendu le travail sur ce projet une corvée. Pour ma part j'en ai effectué le moins possible graphiquement, me contentant d'aider mes trois courageux (http://blog.gmo-web.info/) binômes (http://jbamassy.blogspot.com) dans leur quête vers la compréhension d'OpenGL et des petites absurdités, incompatibilités, incohérences quotidiennes...

Je m'étais affecté aux tâches de gestion de caméra et de la partie optimisation.

La caméra

J'ai mis un temps fou à créer une caméra qui au final ne fonctionnait pas correctement, mais permettait de se déplacer simplement dans la scène. Dans la recherche du Graal de la caméra j'ai découvert les joies de la gestion de la pile de matrice OpenGL, et ai beaucoup joué avec pour obtenir des mouvements et transformations de façon plus intuitives et pratiques que les transformations classiques. Ainsi, au lieu de reprendre un code de quaternions que je ne comprenais qu'à moitié, j'ai préféré implémenter une caméra un peu originale. Au final, elle était plus que compliquée à réutiliser et absolument inmaintenable, mais ce que j'ai appris ici m'a beaucoup servi pour la phase optimisation.

L'idée était qu'au lieu de donner (position + 3 angles d'Euler) ou un quaternion pour décrire la position et direction de la caméra, j'ai utilisé le contexte courant et appliquait mes transformations directement sur la matrice de caméra courante. Pour ceux qui l'ignorent, dans OpenGL quand on applique une transformation (glRotate, glTranslate, etc.) celle-ci est considérée comme la première transformation effectuée, à l'origine... Donc si vous vous éloignez de l'origine et que vous appliquez une rotation ensuite, OpenGL va d'abord faire la rotation, puis la translation. Pour un débutant en Graphique c'est parfois rebutant, mais j'ai l'habitude depuis le temps.

Le problème est que je souhaitais que la transformation soit effectuée à partir de l'endroit et de l'orientation où se trouvait la caméra. Je voulais l'opération habituelle dans le sens opposé (la multiplication de matrices n'est pas commutative). Après bien des batailles contre le systèmes de matrices d'OpenGL (que j'ai quasiment toutes perdues), j'ai découvert par exemple que les matrices y sont stockées dans le sens différent du sens commun (en maths (en france)): en colonnes/lignes... Ensuite j'ai du appliquer mes magnifiques capacités de calcul et de repérage dans l'espace pour rater complètement toutes les transformations que je tentais, jusqu'à ce que me vienne l'idée (bien tard) de m'imaginer la caméra comme un objet, un point... J'ai fini par trouver des solutions, à grands coups de glLoadMatrix, glMultMatrix, glGetfv()... Bien sûr, Java/JOGL n'aidait pas dans ce capharnaüm, avec sa grande verbosité et son abstraction trop poussée. Et dire qu'un des "grands" arguments contre Ada est sa verbosité...

Les premières implémentations avaient des effets de bords désastreux, car personne dans le projet n'utilisait les glPushMatrix() glPopMatrix() avant de faire joujou avec la transformation courante... Et ensuite je me suis redécouvert un très vieux problème que j'avais rencontré quand j'avais développé à partir de zéro une toute petite bibliothèque de rendu 2D/3D logicielle pour de la stéréoscopie : la précision des nombres à virgule flottante. Usant et abusant des glMultMatrix(), l'erreur ou l'imprécision de chaque opération se répercutait extrêmement vite, en particulier lors des rotations. On voyait progressivement mais très vite l'horizon se pencher alors qu'il s'agissait d'une rotation dans le plan de l'horizon. Le passage à des calculs en précision double a un peu amélioré la situation. Et j'ai laissé le tout tel quel, en priant pour que l'examinateur ne s'en rende pas compte.

Au final je ne suis pas du tout satisfait de ce code, horrible, mais ce qui comptait c'était qu'il fonctionne, pour que je puisse me consacrer à la partie vraiment, vraiment intéressante du projet et qui n'avait plus besoin d'approcher JOGL et consistait majoritairement en de l'algorithmique et de ce fameux number crunching (gros calculs brutaux) dont Java se dit capable de rivaliser avec le C aujourd'hui.

Quatre pommes

Lors de ma soutenance de stage, lorsque j'ai présenté mon travail sur OpenGL et la recherche de performances maximales, via Pixel Buffer Objects, des mécanismes utilisant des textures rectangles, des FrameBuffer Objects pour l'écriture texture-to-texture... Un professeur dans le jury m'a demandé si j'avais recherché des optimisations de plus haut niveau, algorithmiques, en particulier dans le domaine du partitionnement de l'espace (Kd-Tree et autres friandises). Etant un ignare total dans le domaine, j'ai regretté de ne pas m'être penché plus tôt sur ce genre d'idées. Il me fallait corriger mon ignorance au plus tôt.

Je cherchais donc via ce projet à implémenter un algorithme intéressant permettant de réduire le nombre d'objets à afficher dans une scène. On avait survolé rapidement les BSP en cours et je voyais poindre la lourde, peu originale et surtout peu adaptée implémentation basique d'un tel engin... En recherchant d'autres solutions, j'ai découvert les Oct-tree et les Quad-tree. En résumé, il s'agit d'algorithmes très simples de découpage récursifs de l'espace. Ceux-ci sont beaucoup plus adaptés à la modélisation de bâtiments, car leur forme "carrée" simplifie énormément les calculs et leur structure rigide y rend la recherche extrêmement efficace.

L'idée était de gérer le frustum-culling avec un algorithme de détection de collision via un quadtree. Le frustum était projeté sur le sol (ses 6 faces l'étaient), et on utilisait ces quadrilatères pour vérifier la collision avec d'autres objets présents dans la scène.

Le problème premier et pénible était de récupérer le frustum, c'est à dire les coordonnées de ses 8 sommets. Il fallait faire ça à partir de la matrice de caméra. Heureusement j'avais déjà dépensé beaucoup de temps de cerveau à jouer avec les matrices et j'ai rapidement trouvé comment récupérer la position et l'orientation de la caméra, pour ensuite récupérer les 8 sommets à coup de géométrie simplette =oD.

Ensuite et enfin (j'aime garder le plus agréable pour la fin), j'ai implémenté l'algorithme de quadtree en 2 journées (de 22h) et ai optimisé la recherche ainsi que l'occupation mémoire comme j'ai pu, et ai fini de le débugger un autre soir. C'était vraiment agréable d'enfin développer quelque chose qui soit simple, relativement élégant dans le principe, sans la lourdeur pénible des abstractions d'interface graphique... Et surtout de pouvoir tester cet outil directement et de façon interactive avec une petite application Java2D (temps de développement compris dans l'implémentation de l'algorithme :-)) qui a plus tard été intégrée à l'interface finale. Elle sert de radar pour montrer quels objets statiques sont présents dans la scène et montre les frustum et les objets qu'il contient ou coupe, et donc les objets qui sont dessinés et ceux qui ne le sont pas. On visualise le résultat de l'algorithme d'optimisation, à défaut de pouvoir le constater.

En effet, les trois quarts de fonction géométriques que j'ai utilisées, je les ai recodées à la main, à partir de formules pas optimisées du tout. La recherche dans un cas bouclait infiniment et je n'avais pas réussi à reproduire cet Heisenbug. Quelques autres erreurs de conceptions ralentissaient encore ce code, mais priorité a été donnée au bouclage du projet. L'optimisation ralentissait en fait l'application :-D. Etant donnée la complexité de l'algorithme il aurait fallu avoir un nombre conséquent d'objets pour y trouver son compte :-).

Bile-an

Au final, ce projet étalé sur 2 mois m'aura rappelé que j'aime toujours si peu le Java, et que seul Eclipse qui m'a maintes fois sauvé de la dépression, en fait un langage de travail passable. J'aurai tout de même découvert beaucoup d'éléments intéressants, fait beaucoup (beaucoup !) d'erreurs, et donc appris énormément mais que le rapport :

Apprentissage / PITA

était proche de 0.

Ce projet nous a quand même valu la meilleure note de la promo... comme quoi...

I --------- Love --------- This --------- Compiler !

2005-11-26T18:35:00.000+01:00

Je suis un grand, grand fan d'Ada. J'adore travailler avec ce langage. J'ai l'impression de coder, et non de passer mon temps à comprendre quelle stupidité basique j'aurais oublié.

Introduction, Vite Fait

Oui, ce langage fortement typé, plutôt verbeux, pseudo-limitatif.

Pour le typage fort, ça facilite la détection des erreurs à la compilation, entre autres. En Ada je passe moins de temps à déverminer et plus de temps à coder. Et même si en général on écrit plus de code en Ada qu'en C/C++, on en écrit beaucoup moins qu'en Java. L'API n'est pas aussi complète quye celle de Java, bien qu'on puisse trouver de quoi faire pas mal de choses sur Teh Intarwaybe. Des bindings et des bibliothèques développées from scratch.

Les outils de debugging et de profiling que vous utilisez en C ou pas (c.f mon article sur KCacheGrind) sont utilisables avec Ada.

En plus ! La norme Ada 2005 est en phase de finalisation. Elle apporte pas mal de modifications pour simplifer un peu la vie du programmeur Ada.

Entre autres sucreries :

Des nouveaux profils temps-réel
La possibilité d'avoir des inclusions circulaires de packages (oui c'était un petit souci avec Ada95)
Des containers (liste, vector, sets, maps)
Du pseudo héritage multiple via interface
La notation pointée (pour les vieux critiques qui disaient "tu peux pas faire comme en Java mon_instance.ma_methode()")...
Les access anonymes : de fonctions/procédures ou de types. Très pratiques, car plus besoin de créer à chaque fois un type pointeur

Le but de cet article ? Montrer pourquoi, comme google le fut, le compilateur Ada est votre ami. Petite compilation des erreurs que renvoie le compilateur GNAT (celui qui est libre et plus ou moins intégré à GCC). Je les aime, et je suis sûr que ça peut faire des jaloux.

La compil'

Confondu Ada, SQL et VB6 ?

framebuffer_object.adb:79:42: "<>" should be "/="

Aide-moi pour la visibilitée et la gestion de portée

framebuffer_object.adb:79:42: operator for type "gl_uint" defined at opengl-types.ads:20 is not directly visible
framebuffer_object.adb:79:42: use clause would make operation legal

simple_video_handler_types.adb:95:33: "Void_Const_Access" is not visible
simple_video_handler_types.adb:95:33: non-visible declaration at opengl-types.ads:28

Variable non modifiée, en faire une constante ?

framebuffer_object.adb:106:07: warning: "Attachment_Type" is not modified, could be declared constant

Pas les bons types pour chaque opérande de l'opérateur "/="

framebuffer_object.adb:367:42: invalid operand types for operator "/="
framebuffer_object.adb:367:42: left operand has type "gl_int" defined at opengl-types.ads:16
framebuffer_object.adb:367:42: right operand has type "gl_uint" defined at opengl-types.ads:20

Une fonction fonction() qui fait return(function));

framebuffer_object.adb:412:14: warning: possible infinite recursion
framebuffer_object.adb:412:14: warning: Storage_Error may be raised at run time

J'adore celle là (corrige mon orthographe)

framebuffer_object.adb:369:71: "Ct_Gl_Frame_Buffer_Ext" not declared in "constants"
framebuffer_object.adb:369:72: possible misspelling of "ct_GL_FRAMEBUFFER_EXT"

Comment ça mieux que le C ?

hello_gpgpu.adb:107:22: "=" should be ":="

Oublié d'importer un package

simple_video_handler_types.adb:36:16: missing with for "Ada.Text_Io"

Multiple dispatching

Une autre erreur fort sympathique à propos de dispatching... hu hu hu c'est subtil... Là, on ne peut pas avoir un type tagged en argument d'une primitive d'un autre type tagged. A moins que l'argument soit mis en -- type'class... et qu'il soit converti explicitement à l'utilisation =o/

simple_video_handler_types.ads:28:04: warning: no primitive operations for "T_Radial_Struct" after this line
simple_video_handler_types.ads:34:14: this primitive operation is declared too late
simple_video_handler_types.ads:56:14: operation can be dispatching in only one type
simple_video_handler_types.ads:60:14: operation can be dispatching in only one type
simple_video_handler_types.ads:62:14: operation can be dispatching in only one type
simple_video_handler_types.ads:72:04: warning: no primitive operations for "T_Radial" after this line
simple_video_handler_types.ads:74:49: expected type "T_Radial_Struct" defined at line 15
simple_video_handler_types.ads:74:49: found an access type
simple_video_handler_types.ads:80:13: this primitive operation is declared too late
simple_video_handler_types.ads:81:13: this primitive operation is declared too late
simple_video_handler_types.ads:134:13: operation can be dispatching in only one type

Ordre des opérateurs

simple_video_handler_types.adb:307:29: "aliased" should be before "constant"

Pragma unreferenced

Pour avoir la paix avec le compilateur quand on est en train de coder et qu'on veut juste vérifier que "jusqu'à ce point une fonction compile", on peut utiliser la pragma unreferenced... Mais si on l'oublie après avoir tout codé, le compilo le voit... =o)

simple_video_handler_types.adb:410:55: warning: pragma Unreferenced given for "Data"

Oublié de mettre "body" pour désigner un corps de package...

buffer_lines_list.adb:1:08: keyword "body" expected here [see file name]
buffer_lines_list.adb:1:08: missing "body"

Génial : j'ai mis Const à la place de constant

video_runner.adb:43:23: illegal abbreviation of keyword "constant"

<> à la place de /=

simple_video_handler_types.adb:928:27: "<>" should be "/="

Ma vie est belle, grâce aux gens de AdaCore/Act. Merci :-D

KCacheGrind, killer-tool...

2005-11-04T20:23:00.000+01:00

J'en avais parlé récemment, et je viens juste de récupérer mes screenshots de kCacheGrind.

Quoi qu'est-ce ?

KCacheGrind est un outil de visualisation des résultats de l'outil callgrind. Callgrind est un outil de profiling qui permet de savoir dans quelles fonctions votre programme passe son temps.

Comme j'ai la flemme de détailler la technique et que google et le man page de callgrind regorgent d'informations, je vais plutôt poster mes screenshots de KCacheGrind, pour montrer à quel point ce logiciel est pratique et agréable.

Après avoir lancé callgrind sur l'exécutable de mon projet, je lance kcachegrind sur le fichier résultat. Et voila l'application qui se lance :

Intrigué, je cherche à comprendre à quoi tout ceci correspond. C'est facile. Les noms des fonctions sont dans les cases du dessin à droite, et dans la liste des fonctions à gauche. Le dessin qu'on voit, c'est en fait une sorte de partition du temps passé dans le programme, entre toutes les fonctions... Comme les fonctions en elles-même en appellent d'autres, on se retrouve avec des poupées russes. C'est très intéressant et même ludique. Je me suis vite pris au jeu de clic-cliquer partout sans trop savoir quoi faire.

Je me rappelle que je suis là pour savoir où se trouvent les goulets d'étranglements de mon application. Je clic-clique donc sur les plus gros carrés et clic-clique encore jusqu'à trouver les endroits où ça coince.

Le Boulet...

Là, surprise, je trouve un énorme (!) goulet d'étranglement, qui me saute aux yeux. (Evidemment je n'ai pas pris de screenshot tellement la honte était grande).
Explication : dans mon projet, pour faire du rendu 3d, j'utilise des shaders OpenGL (programmes exécutés par la carte vidéo). Pour les mettre en oeuvre, je me suis contenté de reprendre un package d'exemple présent dans le code que mon tuteur de stage m'avait donné au début du stage. J'ai rajouté des fonctions et des fonctions à ce package, jusqu'à ce qu'aujourd'hui il soit devenu totalement imbitable. Enfin dans Emacs, et sans le mode ECB.

Supposant qu'il s'agissait d'un code ultra-fonctionnel tout bien pensé, je ne me suis pas posé de question. Mais en fait j'ai eu tort. La bêtise que j'ai découverte c'est que je demandais l'index des variables uniformes et des attributs des programmes... A chaque fois ! Pour être clair, tout au long de la vie d'un fragment/vector program, les variables uniform et attribute sont accessibles et modifiables. Mais pour y accéder - en général, 99% du temps , pour les définir (écrire dedans) - il faut disposer de leur numéro d'argument. Oui OpenGL c'est du très bas niveau. Tous les objets qu'on utilise sont définis par des indices.

Ces indices des arguments ne varient pas, ne changent pas, à moins qu'on recompile les programmes... Et mon programme d'exemple, ainsi que mon package de shaders, demandaient à chaque utilisation à OpenGL de nous donner le numéro des variables...

Comme je le disais récemment, en général, les commandes OpenGL sont asynchrones. Ce n'est pas le cas du tout pour les opérations de lecture. Ainsi, mon programme forçait un flush du pipeline OpenGL à chaque modification des variables de shaders...

Tout cela grâce au dessin en boîte. =o)

Quand on ne peut plus...

Ensuite, j'ai trouvé quelques autres idioties sans grandes répercussions sur les performances. Et j'ai fini par me trouver limité par 2 facteurs et j'ai (encore !) eu un surprise.

Toutes les parties que j'aurais pu optimiser ne constituaient que 5 à 6% du temps d'exécution du programme. Il était totalement stupide de chercher à optimiser ces parties que je croyais critiques, avant de mesurer...
Je ne pouvais pas faire mieux. Dans le screenshot plus bas, la fonction qui prend presque 13% du temps (Get_Area_Index) n'est qu'une fonction de translation d'adresse. Cette fonction est la routine de base de l'architecture que j'ai implémentée dans ce programme. Et elle ne fait qu'une ligne : une conversion et une division. Et le compilateur l'inline déjà automatiquement (si je me rappelle bien, Gnat permet de sortir une version précompilée du code, où il on peut voir tous les checks, les instanciations silencieuse, les opérations implicites explicitées, et les fonctions inlinées indiquées). Au cas où c'était l'inline qui posait problème (en augmentant la taille du code), j'ai vérifié sans option d'optimisation, le résultat est pire.

Où donc que ça coince ?

L'image ci-dessous montre juste en haut à gauche le temps passé dans chacun des objets ELF en jeu pendant l'exécution de mon programme.

Comme on peut le voir (en haut à gauche) Mon programme passe son temps dans l'API que j'ai codée. Ou en tout cas, il y a énormément plus d'appels à des fonctions de mon API pour la gestion des données à afficher que pour l'affichage même (libGL.so, libGLCore.so). C'est une surprise, je pensais que le facteur limitant serait le GPU, et que c'était à cause de lui que ça ramait... En fait, le GPU va très bien, c'est dans la mémoire système et sur le CPU qu'on travaille beaucoup trop. Avec un peu de recul, le pourquoi du comment est évident.

On casse tout et...

Ainsi, à la recherche des fonctions primitives qui prennent plus de 10% du temps, je n'ai pas pu en trouver une seule dans l'API qui puisse être regroupée, factorisée, améliorée, et qui en vaille la peine. Je n'ai pas trouvé comment faire mieux. Mais l'idée que mon programme passe plus de temps sur le CPU que le GPU me turlupinait, alors j'ai mis en cause toute mon architecture.

Je pensais devoir stocker toutes les données pour connaître l'état exact à l'instant T des informations que je venais de dessiner
je pensais aussi devoir avoir différents niveaux de granularités et j'avais axé la performance sur la granularité la plus petite. Ainsi pour dessiner un gros paquet d'informations (la majorité des arrivées... mais je l'ignorais) cela me prenait 4 à 5 fois plus de travail - recherche, translation d'adresse, mise à jour mémoire application puis mémoire vidéo - que ce que je pouvais faire en fait. Mais le problème était que mon architecture était de base trop prévue pour être flexible.

Toute cette réflexion je l'ai remâchée à un collègue qui m'a expliqué qu'on s'en foutait en général de la petite granularité et, que la majorité du temps on recevait des gros chunks de données. Bon.

J'ai donc décidé de tout casser il y a de ça une semaine. Je change totalement la structure des données, et axe désormais mes traitements sur les gros chunks, pousse le maximum d'informations vers la carte vidéo (quitte à faire les fonctions bien chiantes pour la relecture et le débug...).

C'est pour ça que j'ai porté le code de gpgpu.org en Ada, pour avoir les outils et m'entraîner avec ces techniques.

Mais sinon, KCacheGrind ?

Tout de même fasciné par l'outil j'ai continué à m'en servir, ne serait-ce parce que je le trouve sympa, et que la procrastination est une tentation à laquelle il est difficile de résister =oD...

Je me suis intéressé aux petites fonctionnalités et à une autre, beaucoup plus cool.

Les listes des callees et de callers avec leurs statistiques assorties, permettent de naviguer dans les poupées russes de haut en bas, et de bas en haut sans trop repasser par le graphiques des boîtes imbriquées qui sont parfois trop denses et ne contiennent pas de statistiques globales d'une fonction par exemple. Voila ce que ça peut donner :

Et puis j'ai découvert, LE truc qui fait la différence et qui rend l'outil plus qu'utile, mais fun. C'est l'affichage du VRAI callgraph (graphe d'appel) sous forme de graphe noeud->liens. Si le système de poupées russes est très intuitif pour les performances des différents blocs, on trouvera utile le graphe d'appel pour savoir qui conduit à quoi, en quelle proportion, et si on a des cycles, des fonctions "globales"...

Je pense qu'une ou deux images feront plus court ici que des pages d'explications (et puis je fatigue). Voila ce qu'on peut obtenir à partir du même code et du même exécutable (et du même log il me semble).

On peut voir la représentation verticale du graphe d'appel.

Quelques notes :

La fonction qu'on a sélectionné pour être le centre d'intérêt du graphe est un peu ombrée.
On a une carte générale du graphe et une vue un peu plus zoomée.
On peut changer l'inclinaison du graphe :

de gauche à droite
du haut vers le bas (le screenshot ci-dessus)
le mode circulaire (le screenshot ci-dessous)

On peut réduire le graphe en sélectionnant des fonctions plus bas dans le graphe.
On peut continuer à parcourir le graphe d'appel, toutes les informations se mettent en correspondance. Si, par exemple, on choisit un élément dans le graphe d'appel, les poupées russes vont se mettre sur la fonction sélectionnée.

Petit détail un peu ennuyeux

J'ai découvert la fonctionnalité des jolis graphes assez tard (quand ils ne m'étaient plus vraiment utiles). KCacheGrind me disait que si je voulais pouvoir les afficher, il fallait dot et graphviz... J'avais occulté ce problème car l'outil me contentait. Et quand j'ai finalement voulu l'essayer je me suis retrouvé face à ce petit problème : graphviz, qui est un outil qui m'a l'air assez connu, n'est pas packagé par la communauté fedora linux, ou en tout cas ne se trouve pas dans leur repository de base.

Le problème s'est vite résolu, car sur le site de graphviz, on peut trouver tous les paquets rpm pour Fedora Core 4 (la bonne en plus) dont on a besoin. Ils s'installent sans problème et KCacheGrind fonctionne très bien ensuite, aucun problème.

C'est juste dommage, ceux qui n'ont pas Teh Intarwayb au boulot toute la journée, ou qui ont seulement accès à un miroir Fedora, sont condamnés à se priver d'une fonctionnalité de cet outil, pourtant si agréable. =o)

Rien de bien méchant, n'est-ce pas ?

Conclusion

Cet outil, il est bien, stable, intuitif et simple. Que demander de plus ?

Si vous avez encore un doute, c'est un outil KDE, donc derrière c'est du Qt. Voila qui devrait aider à convaincre le dernier récalcitrant blond un peu frisé au fond :-D

General Purpose GPU

2005-10-31T12:57:00.000+01:00

Il y a certains temps, je parlais ici d'OpenGL et des shaders, des progrès effectués ces dernières années et de mon impatience à voir d'autres applications émerger.

Gpgpu Didactique

Les gens de gpgpu.org travaillent dans ce sens. Le site dispose d'un nombre important d'articles, résumés de recherches, ou encore présentations (ppt/pdf) concernant l'utilisation d'un GPU pour des calculs plus "généraux" que juste du dessin 3D.

Bien qu'il faille quelque peu fouiller pour trouver les meilleurs articles, les présentations sont très didactiques et complètes, introduisent à l'architecture des cartes video de façon bien plus didactique et "généraliste" que la plupart des articles de programmeurs de jeux video que j'ai pu lire (et j'en ai lu des dizaines).

Une fois toute l'architecture des cartes video digérée, on peut passer très vite à la pratique, en utilisant les classes mises à disposition sur leur site, en C++/OpenGL. Le code est extrêment clair, simple, et didactique, commenté à profusion et une connaissance quasiment nulle du C++ (comme la mienne) permet tout de même de comprendre sans aucun problème comment faire !

Parce qu'en général, en ayant fait un peu de 3d, on a des structures assez rigides dans la tête et même si on voit des possibilités se dégager avec les Shaders, on a pas forcément l'intuition pour comprendre les concepts de base de GpGPU. Par exemple, le rendu multi-passe était pour moi un vrai casse tête sans nom, ainsi que le render-to-texture, ou encore leur notion de kernel ou de stream. (noyau et flux me semblent des traductions fort appropriées =o)).

Maintenant, avec leur présentation, remâchée, relue plusieurs fois, je peux définir :
- un stream : un ensemble de données séparées, traitables en parrallèle, et n'ayant aucune dépendance interne.
- un kernel : une opération qu'on applique sur un élément d'un flux.

On a de plus en plus besoin d'effectuer un rendu vers une texture, afin de pouvoir réutiliser le résultat de ce rendu pour dans d'autres calculs. La méthode est simple, et repose sur quelques concepts :

Texture = Array : Une texture correspond au concept de tableau dans la programmation "classique". On alloue une texture pour faire tenir nos données.
Fragment Program = Computational Kernel : un programme de fragment peut-être pensé comme un petit kernel de calcul qui est appliqué en parrallèle à plusieurs fragments (éléments d'un stream) en même temps.
One-to-one Pixel to Texel Mapping:

Data-Dimensioned Viewport : On a besoin (en général) d'un mapping "bijectif" de un pixel vers un texel. Ceci afin de s'assurer que l'on a effectué le calcul demandé sur chaque élément de la texture. En configurant notre viewport avec les dimensions de notre texture "destination" et en dessinant un Quad (rectangle en OpenGL) ajusté à la taille de l'écran, on s'assure que chaque pixel de notre texel (=o)) est généré et traité dans le fragment program... (oui, on dirait une traduction google mais non, je suis juste nul en anglais).
Orthographic Projection : On définit en général un matrice de projection orthogonale avec un repère [-1;1] sur les axes X et Y. Ca permet d'avoir une correspondance simple entre les pixels et les texels.

Viewport-Sized Quad = Data Stream Generator : pour pouvoir exécute des fragments programs, on a besoin de générer des pixels. Dessiner un Quad de la taille du viewport génère un fragment pour chaque pixel de notre texture de destination. Chaque fragment est traité identiquement par le fragment program.
Copy To Texture = feedback : nous avons juste invoqué notre calcul en appliquant un fragment program sur une quad de la taille du viewport. Les résultats sont maintenants dans le framebuffer. Pour les stocker, on copie les données du framebuffer dans une texture. Ainsi on peut réutiliser ces résultats comme source pour l'affichage ou pour d'autres calculs.

Ce code C++ est d'une simplicité et d'une clarté telle que la conversion en Ada m'a pris une après-midi seulement (en codant propre).

Et non, seulement le code est clair mais il est didactique. Il reprend dans l'ordre toutes les étapes nécessaires pour dessiner quelque chose avec OpenGL, plaquer une texture, charger/compiler/linker un shader... Et on voit même où poser nos propres améliorations pour faire ce qu'on veut.

En plus, le code est gavé de commentaires. Et bien qu'il y en ai presque un par ligne, ce ne sont pas des commentaires ASM. Leurs commentaires permettent presque de comprendre le code sans le lire =o).

Bref, pour ma part, rien de trop, rien ne manque. Chapeau.

Great expectations

Les drivers 80.x de NVidia sont sortis récemment pour windows. Apparemment, la nouveauté que j'attendais le plus est implémentée et a l'air de fonctionner (pas trop vu de plaintes sur les forums NVidia).

Il s'agit de drivers OpenGL multithreadés. Oui, c'est une nouveauté, aussi étonnant que ça peut paraître. OpenGL est basé sur un modèle de machine à état. On pourrait imaginer que les fonctions de l'API sont des fonctions statiques du contexte OpenGL. Les états sont globaux.

Plus clair, un exemple. Quand on veut sélectionner une texture à appliquer, on lie le contexte courant à un numéro de texture (réservé plus tôt). On est contraint de faire ceci pour que le serveur sache que le client souhaite utiliser cette ressource. Les Texture Objects, les Vertex Buffer Objects, Pixel Buffer Objects, et Framebuffer Objects sont en général des objets serveurs. Cela évite le transfert client->serveur quand on veut s'en servir. Donc quand on veut sélectionner un Vertex Buffer, il faut appeler glBindBuffer. Tous les threads appelant du programme appelant OpenGL partageront cet état.

A priori, NVidia avait commencé à travailler sur ce problème avec leur bibliothèque tls (thread local s*). Mais j'ai essayé plusieurs fois avec les tâches Ada (qui sont codées par dessus les pthreads dans Gnat sous Linux), et j'arrivais toujours à provoquer une erreur OpenGL voire de gros plantages.

Asynchrone

Si leur bibliothèque est désormais bien multitâches (et donc que je vais pouvoir utiliser l'hyper-threading de mon P4 et les fonctionnalités de parallélisme d'Ada), j'espère aussi qu'ils ont rendu certaines commandes totalement asynchrones.

En réalité, la majorité des commandes OpenGL sont asynchrones. Lorsqu'on appelle une commande, celle-ci est envoyée au serveur (ou à l'api client) et en général la fonction rends la main tout de suite, et le programme continue. Les commandes sont exécutées dans l'ordre donné, mais on n'a pas le contrôle absolu du moment de leur exécution. La seule chose qu'on peut faire pour forcer les commandes à être exécutées, c'est d'appeler glFlush() qui va demander l'exécution des commandes encore dans le pipeline. On peut aussi, pour être vraiment sûr que TOUTES les commandes sont exécutées, utiliser l'appel bloquant glFinish(), mais c'est peu conseillé.

Mais certaines fonctions malheureusement ne renvoient pas ou ne permettent pas de continuer pendant qu'elle s'exécutent. Par exemple, glReadPixels est une commande assez lourde (lecture de pixels, transfert, grosse utilisation de ressources et de bande passante). Avec une extension récente, glReadPixels() a été rendue asynchrone, grâce aux possibilités de DMA (dites ce que vous voulez transférer, et partez faire ailleurs). Cela fait gagner un temps fou quand on fait du rendu multi-passe, sur des ensembles différents. Le tout est d'éviter de mapper (rendre accessible en lecture/écriture aléatoire) une zone serveur.

Comme je dois travailler sur énormément d'éléments assez petits (qui ne rempliraient pas le cache de vertex/fragment processing de façon efficace), j'ai 2 solutions : tout casser mon code pour coder une sorte d'algo d'allocation pour utiliser le cache au maximum (sans même être sûr que c'est le point limitant) ou alors laisser OpenGL s'occuper de remplir son cache en me voyant appeler 600 fois le même programme sur différentes zones.

Bref, un peu d'espoir de pouvoir essayer bientôt de faire joujou avec ces nouvelles "features".

En attendant, je me prends la tête pour mon truc de rendu multi-passe en pensant pouvoir faire exploser les 320 millions de points par seconde de mon ancien moteur. Ou au moins rendre l'archi plus propre, en évitant la tonne de calculs inutiles que je faisais jusque là =o).

Auto-Conversation, Never-starting-projects

Je viens juste de commencer à travailler sur un petit module Ada pour lire/écrire du iCalendar. Juste un peu de lecture du format et une petite idée sur une architecture simple pour implémenter le parseur... Passer par Aflex-Ayacc serait bien mais trop lourd, et je ne comprends rien à AdaGOOP... Alors en attendant, je vais tester les expressions régulières de GNAT qui ont l'air de ressembler de loin à Snobol (que je ne connais pas mieux), et voir ce qu'on peut en sortir. Et si un jour ma motivation est grande je regarderai du côté de AdaGOOP (qui manque furieusement d'exemples didactiques à mon sens).

Bah, le bon gros vrai projet intéressant et technique, ce serait un xslt-processor en Ada... Mais bon... Depuis quand je sais coder ? Il me suffirait peut-être de regarder le code d'un parseur simple, basé sur SAX... Sans trop de récursivité-mal-de-crâne...

Si ça se trouve je vais même prendre goût aux bindings C et au Python et porter plein de trucs vers Ada, tellement c'était pas trop dur avec OpenGL. =o)

Comment ça digression ?

Edit - Pour Jb

Jb, (dit aussi Monsieur Borborygme dans les milieux huppés du vinaigre Puget(tm)) m'a posé une question intéressante (je déforme à peine le propos histoire de nettoyer les erreurs de grammaire les plus grossières)...

Est-ce que j'ai bien compris : les rendus multi-passes pourront se faire en parallèle ? Mais si elles sont dépendantes ces passes ?

T'as vu je fais bien le mec qui suit et qui est un peu au courant mais complètement à côté de la plaque (ma question est toutefois vrai)

Je ne vais pas mettre de Cokpit, ce serait mal placé. Dr Lionel et Mr Twouisteux, je m'en doutais un peu. A bientôt sur une autre passerelle de Massy...

Hé oui. A digression, digression et demi (quoiqu'il s'agisse plus de hors-sujet durable de ma part que d'un refus de te prendre au sérieux).

Pour te répondre, si on a besoin de travailler avec des passes dépendantes, il faut appliquer une bonne partie des cours théoriques de système qu'on a vu en 3ème année de FIIFO. Parallélisme maximal, dépendances des données (pas de dépendances de processeur/registres... le parrallélisme du GPU est un parallélisme des données), conflits... Tout ça.

J'avoue que d'avoir réalisé avec brio =o) le projet de rattrapage de système aide un peu =o).

Venez voir ce document (pdf) pour des informations plus détaillées et plus poussées sur le rendu multi-passes avec des passes dépendantes.

N'hésitez pas pour les questions.

Python : first sight

2005-10-20T22:40:00.004+02:00

Cela fait presque une semaine maintenant que je travaille sur un binding OpenGL avec les derniers drivers nVidia.

Jusque-là je travaillais sur d’anciens headers datant de 2003, qui me donnaient entière satisfaction, car j’ignorais l’avancée récente des technologies graphiques. Avec la découverte de gl_framebuffer_object et gl_pixel_buffer_object, et autres sucreries, il m’a fallu me remettre en cause.

Un binding OpenGL ?

En C pour travailler avec OpenGL il « suffit » de faire #include et à la rigueur la même chose pour le header de glut quand on travaille avec Glut.

Les choses ses corsent quand on veut faire la même chose en Ada. On ne peut pas faire #include . On ne peut pas appeler une fonction C sans au préalable l’avoir déclarée, avec les types corrects et avoir déclaré qu’il s’agissait d’une fonction importée d’un autre langage…

En gros, si on a une fonction dans une DLL (j’ignore si ça marche aussi avec une bibliothèque statique) il faut procéder ainsi :

Supposons qu’en C on ait la fonction :

unsigned char cEstCoolTaVie(int genre, float crari);

En Ada on déclarera (si on le fait à la main) :

function C_Est_Cool_Ta_Vie(Genre : Integer ; Float : Crari)
return Interfaces.C.unsigned_char;

Il faudra ensuite écrire dans le source Ada

Pragma Import (C, C_Est_Cool_Ta_Vie, "cEstCoolTaVie");

A propos de la taille du code (le double de lignes ici) : Ada est un langage plus verbeux, c’est sûr. Mais en général, comme on a moins de vérifications à ajouter dans le code en permanence – beaucoup sont faites par défaut par le langage – le code est souvent plus court et concis.

A propos de la notation, qui est critiquable (majuscule ET underscore ?) : c’est une convention de style du langage ou du compilateur. On est pas obligé de la suivre (la casse n’a aucune importance en Ada), mais la plupart des développeurs Ada y sont habitués, et les IDE Ada font le passage en majuscule automatiquement. On peut aussi utiliser gnatpp (pp pour pretty print), outil en ligne de commande assez configurable.

Les problèmes

Bien, maintenant si vous voulez regarder un instant un header glext.h sur lequel je travaille en ce moment.

Il fait plus de 5000 lignes et c’est un header C, avec les sympathiques instructions au préprocesseur pour définir des constantes et garder du code ou pas… Vraiment du code comme je l’aime : efficace - cà ! en performance c’est sûr… -, et compréhensible.

Ce qu’on peut voir c’est que « globalement », on a 3 parties intéressantes dans chaque header gl.h et glext.h :

des redéfinitions de types C (typedef), préfixés en GL, collé. Par exemple : GLint, GLuint, GLubyte, GLfloat…
des définitions de constantes « en dur » à l’aide de #define. Cela veut dire qu’en C ou en C++, à la précompilation le nom des constantes qu’on aurait pu insérer dans notre code sera remplacé « textuellement » par la valeur définie. Les constantes ont pour charte d’être entièrement en majuscules et les mots sont séparés par des caractères underscore ‘_’. Par exemple : GL_TRUE, GL_FALSE, GL_STREAM_DRAW.
des fonctions. Préfixées en gl (minuscule) et ensuite avec un style « dromadaire ». Par exemple : glDrawBuffers, glCreateShaderProgram.

Si on suppose qu’on veut séparer les fonctions OpenGL de base des extensions, on se retrouve avec 4 catégories d’éléments.

Mon job cette semaine, après avoir analysé et tergiversé sur les fonctionnalités récentes que j’allais utiliser pour multiplier la vitesse de l’appli OpenGL sur laquelle je travaille, c’est de transformer tout ce fatras de headers C de façon à pouvoir utiliser OpenGL en Ada, y compris les dernières extensions. Et, bien sûr il faut que l’expérience soit reproductible : les headers changent en fonction des constructeurs et des versions et des extensions…

Il faut donc que le processus de génération du binding soit automatisé au maximum.

Première étape : le gros outil pas terrible

Pour écrire un binding vers du C en Ada, en général on se pédale les signatures de fonction à la main, ainsi que les pragma import.

Mais ici, vu la taille du header, même pas la peine d’y penser. Alors j’ai cherché s’il existait des solutions, si possible « éprouvées ». J’étais très enthousiaste, car mon tuteur m’avait dit que le header qu’il m’avait passé, et dont je me servais depuis un mois, et qui fonctionnait très bien à quelques retouches près, avait été généré avec un « logiciel » appelé c2ada.

Mon enthousiasme s’est vite dégonflé. Le makefile de base, pour compiler c2ada, est assez mal fait et il faut un peu mettre la main au cambouis. Ensuite une fois qu’on a son exécutable – non sans des dizaines de warning à la compilation et même à l’édition de liens – il faut encore bidouiller $PYTHONPATH pour arriver à le lancer pour la première fois. J’ai essayé chez moi sous Windows, c’est encore pire… Bon, un après-midi perdu comme ça…

Le résultat fourni par c2ada est plutôt décevant. D’abord il lui faut inclure toutes les dépendances et donc en générer des sources Ada. Ainsi, glext.h faisant référence à des variables et types définis dans gl.h, il faut faire un petit script pour ajouter #include "gl.h" au début du fichier.

Les fonctions dans le header C sont déclarées (avec des APIENTRYP WINGDI et GLAPI…), puis plus tard dans le fichier on trouve leur signature. Bien sûr, c2ada ne retrouve pas ça tout seul. A priori, on dirait presque qu’il traduit ligne par ligne. Il faut donc encore un script pour retrouver les correspondances et virer les APIENTRYP et autres joyeusetés dédiées au préprocesseur, dont on a rien à faire en Ada.

Résultat, après avoir bataillé sec, on se retrouve avec plusieurs fichiers Ada, même pas compilables et bien sales.

Il faut donc se contenter du résultat. Bon en réalité je résume, parce que j'ai essayé au maximum d'utiliser les fonctionnalités proposées par c2ada, pour limiter la casse.

Mais encore une fois, il va être nécessaire de passer un script, mais sur du code Ada cette fois-ci.

Deuxième étape : l’outil puissant

En partant de ce code Ada tout pourri généré par c2ada, il me faut arriver à 4 « beaux » paquetages, contenant chacun les éléments qu’il faut.

Il faut aussi que soit respectée la Convention_De_Nommage_Ada, ce qui met en conflit les types, les fonctions, et les constantes, très proches "graphiquement". D’où l’intérêt des paquetages séparés.

Bien sûr les types ne sont pas convertis comme il faut par défaut. Il faut virer la dépendance à stddef.h et changer les ptrdiff_t pour ce que ça peut représenter… Les types contenus dans gl.h et glext.h peuvent se recouvrir, il faut les fusionner pour ne pas avoir de déclaration en double.

J’en passe et des meilleures...

Alors je me lance dans l’écriture d’un script Python pour faire tout ça. Oui, Python. En général je n’aime pas trop les langages de script. Pas typés statiquement, trop "je code à l’arrache et on verra" (mais on ne voit jamais en fait) et lents.

Mais la sagesse populaire dit : chaque langage a son utilité. Ou plutôt chaque type de langage a son champ d’utilité.

Or, pour ce que j’ai à faire j’avais besoin :

d’un bon système pour détecter les expressions régulières
de pouvoir faire relire le code =o)
de pouvoir coder assez vite sans avoir besoin de la vérification apportée par le typage
de fonctions de traitement de chaînes de caractères et d’entrées-sorties, simples et directes

Alors je suis parti d’un script qu’avait déjà commencé à coder mon collègue pour « Adaifier » les fonctions… J’avais sous la main le bouquin « Introduction à Python » et l’aide en ligne Python. Et j’avais cet exemple de code qui faisait la majorité de ce que j’aurais à faire :

compilation d’une regex
parcours du fichier source
match de la regex
reformatage ou autre

Passée la première phase de bidouille, j'ai très vite et très facilement compris comment ça foncitonne. Du coup en une journée j'adapté mes regex à mon code, fait des expressions « récursives » - terme bien pompeux par rapport à la réalité : il s’agissait juste de matcher des expressions dans des expressions dans des expressions, en appelant successivement des regex différentes… - testé, recommencé, ajouté encore des regex, encore des conditions, encore des fonctionnalités. On est loin des grammaires...

Ca allait très vite et j’ai pris plaisir à coder aussi simplement. Tout ce dont j’avais besoin était sous la main : liste, map, expressions régulières, traitement de chaînes flemmard-friendly, fichiers, et je pouvais très vite tester, regarder, modifier, tester, regarder, modifier…

Encore avant hier, j’étais un peu effrayé par la simplicité apparente du langage, alors j’avais vaguement lu quelques notions de syntaxe Python et c’est tout. Voyant les codes bizarres que mes camarades pythonistes postaient de temps en temps sur IRC (la vraie vie), je me disais qu’en fait il s’agissait plus d'un perl bis/beurkque d'un « bon langage simple ». Je m’étais trompé. Une fois de plus ça m’apprendra à penser/supposer sans tester.

J’avais déjà fait du « script » assez longtemps et pensais avoir fait le tour. Franchement vbs (Microsoft ASP) et vba (Microsoft Office) et javascript (dans les DOM HTML et SVG) étaient vite devenus pour moi des boulets plutôt que des outils appréciables qui auraient du faire gagner du temps, avec lesquels je n’ai que rarement apprécié coder. Et encore Javascript restait *relativement* intéressant parce qu’on pouvait manipuler le DOM SVG assez facilement.

Alors qu’en Python, j’ai l’impression que tout est simple, déjà là. Au point même que j’avais du mal à m’enlever de la tête la question suivante : « à part pour les applications de performances très très pointues ou encore pour des applications sûres, à quoi peuvent servir les autres langages après Python ? ». Peut-être qu’on fait trop de développement « simples » en C ou C++ juste « parce que ».

Le même argument vaut pour Ada ou Eiffel : j’ai l’impression que peu de décideurs et de développeurs se posent la question « le bon outil pour le bon job ». Je connais peu C++ mais est-on obligé de l’utiliser PARTOUT ? Si je veux écrire un logiciel de façon ultra-structurée, sûre (éviter trop d’overflow) ; passer mon temps à coder (après la phase de conception bien sûr) plutôt qu’à débugger ; avoir immédiatement le multi-tâches, des moniteurs en 3 lignes de code, des objets protégés… Gérer la mémoire finement via Storage Pool et ne pas trop m’inquiéter pour les fuites mémoire… Si je veux tout ça, je me tournerai vers Ada.

Si je veux de l’ouverture, pouvoir utiliser toutes les bibliothèques C++ du marché, organiser mon code un peu comme je veux... J’utiliserai C++.
Peut-être qu’en avançant plus dans le Stroustrup, d’autres arguments de choix me viendront…

En tout cas, l'argument "je n'arrive pas à recruter des programmeurs Ada qualifiés" est franchement fallacieux. L'apprentissage d'Ada est très rapide. En 2 semaines on est formé à l'essentiel. Et ensuite, des revues de code, quelques petits projets simples proches du sujet du travail. En général c'est plus que suffisant. Ada et Eiffel sont, par leurs contraintes et la qualité de leurs compilateurs, des langages qui s'apprennent presque "tout seul". En tout cas, très rapidement.

A quand une front/backend Swig pour Ada, ou encore un binding maison pour intégrer Python dans une application Ada ? Je vais regarder du côté de GPS.

Conclusion : une très bonne expérience

Ainsi, à la fin de cette journée, il me reste une impression de grand plaisir à coder, comme après une bonne journée de codage Ada.

Le script n’est pas fini, il fait déjà 400 lignes et fait déjà énormément de travail. Je l’ai étendu avec plein de regex (expressions régulières), et des conditions des plus en plus compliquées, et ça fonctionne encore sans que mon cerveau n’explose ou que je ressente le besoin de « partitionner » ou ranger le code (je commente bien sûr).

Seule remarque : malgré tout je trouve que l’indentation pour les blocs, même si c’est une idée intéressante, c’est PITA =o).

En deux jours j’ai réussi à améliorer/nettoyer mon binding généré de 90%. J’en suis même au point que le code généré compile sans même un warning.

Comme on dit par chez moi :

YaY !

et non pas LOLJesus ou encore LMAOZedong...

Shaders, Terre Promise...

2005-10-17T20:49:00.000+02:00

Je travaille aujourd'hui en permanence pour essayer de tirer un maximum de points de ma carte vidéo ces derniers temps, et je tombe en admiration profonde devant les capacités des cartes vidéo.

Petite Différence :

J'ai fait une comparaison entre les capacités de la NVidia Geforce 6600GT du travail (en PCI-Express s'il vous plaît) et mon ATI Radeon 9600 (remerciez ATI pour ne pas avoir mis de chiffres sur leur spec, j'ai du fouiller...), AGP8X (Rajoutez vous-même les ©™®, merci)

Carte	Radeon 9600	Geforce 6600GT
Pixel Fillrate	1.3 Gpixels	4.0 Gpixels
Geometry Rate	325 MTriangles	375 MTriangles

Loin de leur capacité à coûter cher, je me suis intéressé aux statistiques et benchs de ces 2 cartes distantes d’une génération seulement, et je vois qu’en matière de pixel/fragment shader, la NVidia (plus récente) est 2 fois plus "puissante" que l’ATI (ainsi que la Geforce FX 5900). Bien sûr, ça a l’air ridicule comme augmentation, on se dit que les CPU doivent augmenter en puissance bien plus vite.
Que nenni. Les cartes 3D voient leur puissance multipliée par 2 tous les 9 mois, soit comme j’ai lu dans un article, la loi de Moore au cube, alors que les fondeurs de processeurs x86 rament pour suivre cette dernière loi, et sont quasiment obligés d'ajouter des coeurs =o)…

A ajouter à cela qu’il ne s’agit pas forcément d’une course à la fréquence, les chips tournant au maximum autour de 500MHz, avec une mémoire très très rapide (NVRAM ou autre GDDR2 ?), mais plutôt d’une conception architecturale complètement différente.

Les processeurs vidéo exécutent majoritairement des instructions SIMD. SIMD pour Single Instruction on Multiple Data. Une instruction peut-être exécutée en même temps sur plusieurs données en parallèle. On dit aussi qu’il s’agit d’une architecture vectorisée. En fait pour donner une image, les optimisations consistent à réfléchir de cette façon : « une multplication de 2 variables float est aussi rapide qu’une multiplication de 2 matrices(4x4) ».
Ainsi 1 multiplication est effectuée aussi vite que 16 multiplications ! (Après il s’agit sûrement d’un peu de marketing-talk, mais c’est assez souvent repris par les experts).

Virtuellement, l’architecture de shading nous incite à penser que chaque vertex ou fragment dispose d’un processeur, et que tous ces processeurs tournent en parallèle.

En réalité ces processeurs sont capables d’exécuter plusieurs shaders « en même temps » sur différentes données, parce qu’elles sont restreintes, que l’environnement d’exécution est restreint, et qu’on a très peu de dépendances par rapport à un traitement généraliste.

C’est l’avantage et l’inconvénient du shader : on a très peu de notion de l’environnement extérieur.

Le vertex processor

On prend en entrée du vertex processor un vertex, sur lequel on applique un traitement identique à tous ceux qui sont dans le même appel de dessin. Bien sûr on peut avoir des paramètres pour chaque vertex et donc appeler à chaque vertex dessiné la fonction de définition d’attribut, ce qui en général, rend l’application très utilisatrice d’appel de fonctions OpenGL, et donc surchargée d’appels API… On appelle ça API bounded ou API limited dans la langue de John Carmack.

On peut aussi grouper les définitions de paramètres et ainsi définir un paramètre pour un gros nombre de vertices, comme par exemple une couleur, une position de départ, une direction, des coordonnées de texture…

Il peut arriver qu’on ait besoin de définir un tableau d’attributs qui peut être mis en correspondance avec un tableau de vertices. On trouve ici une utilisation pratique supplémentaire des tableaux de vertices -Vertex Array - et aujourd’hui des Vertex Buffer Objects. On peut se servir de ces tableaux pour stocker des vertices (comme l’indique leur nom), mais aussi pour stocker des tableaux d’attributs. Je ferais sûrement un post sur les Vertex Buffer Objects).

Dans le vertex processor, on peut agir sur la géométrie d’un vertex, sur sa couleur (ses couleurs avant et arrière), sur son illumination… On peut effectuer toutes les computations qu’on souhaite en gardant bien à l’esprit que l’on est dans un architecture où tous les vertices sont « censés » être traités en même temps, et donc qu’on ne peut savoir où se trouve le vertex voisin ou le vertex N. On n’a qu’un notion « atomique » du vertex.

Le fragment processor

La sortie du vertex processor est généralement envoyée au fragment processor. Entre les 2 processeurs, on a une étape dite de « rastérisation ». Il s’agit en fait d’interpoler les paramètres « varying » entre les différents vertex dont on demande le dessin. Un paramètre varying est défini dans le vertex processor et est passé au fragment processor, mais interpolé suivant la matrice de projection en place.

Si on dessine d’un triangle, on va donner trois vertices, avec chacun un attribut de couleur, et qu’on fait passer ces couleurs en varying dans le fragment processor, on aura des couleurs interpolées sur tous les pixels (autrement dit tous les fragments) que forment la surface de dessin du triangle.

Bien sûr le fragment shader permet d’effectuer des traitements bien plus lourds que le vertex processor. Il est en général beaucoup plus puissant en calcul, peut « regarder » des textures (ce que le vertex processor ne peut faire que depuis très peu de temps) et effectuer des calculs pour changer la couleur d’un pixel dessiné. C’est ainsi que des graphistes parviennent à créer des textures dites procédurales. Ils recréent avec un fragment shader des objets qu’on pourrait avoir en texture autrement. L’exemple de base du fragment shader est la « brique », où l’on recrée un « pattern » simple de brique dans un shader, c’est-à-dire qu’on dessine certaines lignes en blanc et le reste en rouge de façon périodique.

En général, on fait effectuer au fragment processor ce que le vertex processor ne peut pas faire. On peut modifier les couleurs dans le vp (vertex processor), mais on n’aura pas le niveau de détail et de finesse du fp (fragment processor).

Si vous avez compris quelque chose, et que vous vous demandez si on est au sommet des fonctionnalités et de ce qu’on voudrait faire avec la carte vidéo, la réponse est non. Au delà de ces merveilleuses fonctionnalités, on se rend compte que les shaders deviennent les briques de base de toute une classe d’applications. Et paradoxalement, les utilisations les plus intéressantes des cartes graphiques ne sont plus les jeux vidéo mais celles qui n’ont strictement rien à voir. Toutes ces nouvelles applications poussent les cartes vidéo au maximum, montrent leurs limitations, et font miroiter qu’en investissant dans un tel pari, on peut doubler les performances de ses applications de calcul lourd tous les 9 mois =o).

Enthousiasmant

Ainsi, en flânant sur gpgpu.org , on peut trouver une certain nombre d’articles assez techniques pour, entre autres, implémenter un moteur de base de données (désolé c’est au format PowerPoint) sur la carte vidéo en utilisant à la fois les shaders mais aussi les fonctions 3d habituelles à des fins totalement différentes. C’est absolument fascinant.

On trouvera aussi des travaux de recherche sur des algorithmes de tri ultraperformants, rendus encore plus rapides par les capacités de traitement et l’architecture des shaders.

Et si on fouille un peu, on trouve de la documentation sur les limitations des shaders et les nouvelles architectures mises en place pour y pallier, dont je parlerai dans un prochain post.

Conclusion : déjà 2 ans ?

Cela fait plus de deux ans que toutes ces merveilles sont disponibles dans des cartes vidéo grand public. Et je découvre seulement aujourd'hui toute la puissance de ce monde =o). Et encore quand je dis 2 ans, c’est de cette époque que datent les headers OpenGL que j’utilisais récemment encore pour développer mon appli. J’imagine le progrès depuis =o).

Frsit Bgol

2005-10-15T01:06:00.000+02:00

N'ayant pas bloggué depuis un mois, j'ai un certain nombre de choses à raconter... Je pense que je vais faire plusieurs billets jusqu'à trop sommeil.

Mais je pense que je m'étais un peu éloigné de l'idée du blog quand je l'ai créé. Je ne voulais pas le montrer (j'hésite toujours) et je voulais plus en faire une archive de journal ou un truc qu'on pourrait garder de moi quand je serais mort ou quelque chose de similaire, plutôt qu'une façade "racontage de vie".

Je n'aime pas vraiment les blogs. Au delà des skyblogs, c'est juste l'aspect je-raconte-ma-vie-personnelle-sur-le-web qui m'ennuie. Parce que je m'en fiche comme de l'an 68, et aussi parce que les gens devraient garder un peu de pudeur, cacher un peu leur vie. Que diable que deviendra l'illusion de deuxième chance dans la vie quand tout le monde pourra vous dire "ON A LES LOGS !!!1One".

Que Jean-Patrick le semi-chauve-semi-skin aie mangé des saucisses allemandes pour la première fois et les décrive en détail et explique même la meilleure façon de les régurgiter pour mieux les digérer (indice : le vinaigre est un acide), c'est cool.

Qu'une bande gays lurons fasse un journal de leur vadrouille vers Etretat, tant mieux.
Qu'un expatrié à Massy ressente un besoin d'étaler un peu de vinaigre sur la Touâhle, fort bien.
Mais par pitié, pas de blogs "zva coman m lyf est dr, m su fé lrdé pr lott'e tasp".

Cà ! par pitié épargnez-moi aussi et surtout les "oui j'adore le prozac(tm)(c) la vie est belle les oiseaux chantent et les ordinateurs quantiques c'est trop cool-génial" (traduction plus qu'approximative à partir de belge), ou affiliés (quoique, merci pour la crise de rire). De toute façon je ne les lis pas.

Ainsi, comme bonne discipline commence par soi (ou approchant), je n'aurai qu'un lien vers l'extérieur du monde :

Non ne riez pas c'est pas sa faute s'il est blond.

Soit, c'est dit, je n'écris pas ce truc pour qu'il soit lu. Ceci juste ma psychanalyse techno-hebdomadaire, le petit besoin de flusher mes petites intuitions ou pensées, mes grosses idioties ou maladresses, ou encore des visions qui m'ont touché (pas les miennes donc) et qui ont changé la face du monde. Et si j'ai envie de me taper un article de 145 pages sur l'intérêt de telle extension OpenGL, ben euh... comment répondre avec un maximum d'humilité et de maturité... Ah, j'ai :

Na !

Edit : j'ai trop la flemme pour continuer ce soir. Ca commence bien.

OpenGL, la 3D

2005-09-18T03:13:00.000+02:00

Je viens d'arrêter mon job d'été (SVG/ASP je bloguerai sûrement un jour là-dessus) pour commencer un autre stage.

Il s'agit d'un stage plutôt technique où je dois refaire un système d'affichage un peu vieillot en utilisant OpenGL et le dernières techniques d'affichage. Par dernières techniques, disons depuis la 2ème génération de cartes 3D Geforce, depuis l'apparition des vrais GPU.

Expériences avec la programmation 3D

Personnellement mon expérience avec OpenGL se limitait à des bidouilles peu optimisées, où j'avais des milliers de vertices que j'envoyais un par un (j'avais quand même une idée de ce qu'étaient les displaylists) et que je faisais transformer par les fonctions OpenGL que tout le monde utilisait... En gros, ma connaissance d'OpenGL devait s'arrêter à la version 1.1. Pas bien fameux.

J'ai essayé Direct3D ensuite aussi, à l'époque de DirectX7 je crois... Une expérience sympa. Même si j'ai des mauvais souvenirs avec C++/COM...

J'ai découvert Java3D ensuite, dans le cadre d'un projet Java de 2ème année à la FIIFO. Très enthousiasmant, à la première approche. En un week-end j'avais construit un package de classes pour la manipulation d'un personnage composé de sphères "rotatées, scalées, et translatées" =o). Tout allait très vite. Je découvrais Eclipse en même temps. Je n'avais jamais pris autant de plaisir à coder (je devrais bloguer sur Eclipse un jour...). Les performances étaient bien pauvres mais suffisantes pour animer une vingtaine de sphères texturées. Le projet s'est bien passé et j'ai eu un bon résultat.

Ensuite j'ai acheté un bouquin sur OpenGL 1.4, et j'ai découvert les vertex arrays, me suis un peu amusé avec les fonctionnalités de textures avancées (le bus AGP s'améliorant toutes les 2 semaines :-)). Rien de bien fameux. Le problème était toujours le même. Dès que j'essayais de faire la moindre chose un peu sympa la masse de modifications à appliquer sur un code déjà pas terrible me décourageait très, très vite. Et évidemment, chaque modification rendait l'application horriblement lente... Bref, j'ai laissé tomber.

Et pendant 2 ans j'ai vu les nouveaux jeux, les nouvelles cartes, entendu les nouveaux buzzwords "pixel/vertex shaders", "tesselation", "HLSL", "Cg", "Vertex unit"... On aurait dit que les performances brutes avaient explosé, que les CPU des machines avaient aussi explosé. En voyant la complexité des scènes des jeux vidéos récents, je me suis dit qu'ils avaient multiplié par 150 les capacités d'affichage de génération en génération...

C'est bien ce qu'il s'est passé =o) (quoique 150 c'est peut-être un peu en-dessous de la réalité). Mais cela ne suffit pas. Si la carte vidéo peut transformer 150 milliards de vertices à la seconde, il faut bien les produire quelque part ces vertices. Je ne comprenais pas le "progrès" et l'enthousiasme pour les cartes 3D...

La programmabilité du GPU

Le sujet de mon stage concerne l'utilisation de "shaders OpenGL". J'avais une vague idée ce que c'était. Quand je dis vague, je pensais C'est une fonctionnalité *moderne* qui trouve plein d'enthousiastes et peut-être qu'on pourra gagner 2% de performances avec ça... J'étais, comme d'habitude, bien loin de m'imaginer l'intérêt de cette fonctionnalité.

Première illumination : un vrai langage C-like pour les shaders

le langage de shading OpenGL est en fait un langage exécuté par le GPU. On programme le GPU par ce langage. On lui fait effectuer des opérations par vertex et par fragment (on dit par pixel sous DirectX).

Donc, à chaque appel à glVertex, on définit soi-même les opérations qui seront effectuées sur le vertex. Transformation, illumination, calcul de normal, coloration... Et on définit aussi les opérations effectuées sur les pixels interpolés (fragments). Texturage, coloration, illumination per-fragment... Tout le code OpenGL qu'on aurait placé en amont dans le glBegin / glEnd avec les 300 changements d'états (si on a mal regroupé les éléments de ses modèles =o)), on le déporte dans 2 fichiers sources .vert et .frag et on se contente de lier nos objets à ces programmes...

Bien sûr, ce n'est pas aussi simple. Il y a toute une procédure à respecter. Lecture du source, compilation par OpenGL (en ligne !), link des programmes, instanciation, binding, et ensuite définition des paramètres.

Les paramètres ! Grâce à eux, on peut paramétrer (!) les opérations effectuées dans un shader. L'exemple le plus attrayant est l'animation de particules. Supposons que vous voulez calculez la trajectoire des particules avec une fonction (du genre les bonnes vieilles fonctions de physique de Terminale S).

Vous construisez un shader qui prend comme paramètre une variable temps. Vous placez vos 4000 vertices sur une grille. Vous bindez votre shader à cette grille de vertices. Ensuite, quand vous le souhaitez, incrémentez le paramètre temps et réaffichez. Chaque vertex va être transformé en fonction de ses coordonnées de départ, et du temps courant. Plus besoin de parcourir soi-même des listes sans-fin de vertices, de leur appliquer une transformation "à la main"...

On dispose maintenant d'un moyen d'effectuer des traitement pour chaque vertex ET pour chaque fragment !

Sans parler des possibilités offertes : faire faire des calculs très lourds au GPU pour alléger le CPU. Le GPU est très fort en calcul de matrices par exemple... Il est capable par exemple d'exécuter un calcul de matrice 4x4 floats aussi vite que la multiplication 1x1 float... Il ne s'agit pas que d'une révolution dans le graphisme...

Deuxième illumination : les zones en mémoire vidéo/serveur enfin utilisables

Il y a eu beaucoup de travail effectué chez NVidia pour réduire les goulets d'étranglement CPU et bus AGP. Ayant déjà essayé à une époque lointaine d'utiliser des vertex arrays, j'en gardais un mauvais souvenir. Envoyer beaucoup de vertices (des centaines de milliers) avec même très peu de calcul à faire derrière (pas d'illumination, pas de texture...) à la carte la mettait très vite à genoux. Le phénomène est simple à comprendre et la solution était "évidente". La lenteur appraissait (entre autres) parce que les tableaux de vertices étaient stockés dans la mémoire application, chez le client (OpenGL est très orienté Client/Serveur). A chaque dessin il fallait renvoyer tout le tableau de vertices au serveur (la carte vidéo) pour lui faire faire le transform & lightning... Quelle efficacité !

J'ai appris la suite de l'histoire récemment. NVidia a créé un extension appelée VAR ou NVAR (pour NVidia Vertex Array Range). Cette extension permettait de réserver des zones en mémoire vidéo, AGP, ou application... Ainsi on évitait les aller-retour... Si simple ? Pas vraiment.

D'une part, cette extension avait une limitation au début, au niveau du nombre de vertices : 64K vertices au maximum... peu intéressant. Cette limitation a été levée avec le Geforce3. Mais surtout cette approche cassait le modèle client/serveur d'OpenGL, puisqu'un client avait accès à une zone mémoire serveur comme si elle était chez lui, et celle-ci n'était absolument pas verrouillée. En plus, il fallait que les développeurs codent leurs propres procédures d'allocation (comment savoir si j'ai déjà réservé cette place, en ai-je toujours besoin) ce qui rendait la programmation avec NVAR peu agréable et fiable.

NVidia (ou un autre constructeur...) a donc créé les VBO/PBO. Il s'agit des Vertex Buffer Object (et Pixel BO...). Il s'agit de permettre de réserver des buffers simplement, de dire où l'on souhaite qu'ils se trouvent (client, serveur). On peut les mapper (les bloquer en lecture/écriture), et l'allocation est gérée par le driver.

Vraiment je ne peux pas attendre lundi/mardi pour "jouer" avec les VBO et voir les différences de performances... Peut-être le million de vertices/frame. C'est le premier but.

From the bottom-up

-- digression
J'ai lu mon premier jour de stage les 5 premiers chapitres du svn handbook. Et il y a une introduction d'un chapitre qui dit à peu près ceci (traduction anglaise plus qu'approximative) : certaines personnes apprennent plus efficacement en partant du bas.

Je suis de ces gens-là. Je comprends mieux si je vois d'abord un bon exemple qu'en 2 jours de cours abstraits sur le pourquoi du comment. Je commence par un exemple. Et rapidement je comprends comment fonctionne X. Ensuite, je peux mieux comprendre le pourquoi du comment parce que j'ai une idée de comment ça fonctionne. Je n'ai peut-être pas toutes les subtilités, et mon esprit est sûrement "corrompu" par ce cambouis sur les mains et par une expérience concrète trop précipitée =o).
-- fin digression

J'ai lu le livre d'introduction "OpenGL Shading Language" rapidement, en une journée, et reparcouru rapidement le red book OpenGL pour me remettre dans le bain... C'était même plus qu'idéal : mon tuteur m'avait laissé un exemple de code qui fonctionnait : une application utilisant Glut (fenêtrage et la théïère) et les "derniers" drivers NVidia sous linux.

Je me suis lancé dans la lecture du code. Qui fait quoi ? Pourquoi ? si j'enlève ça qu'est-ce qu'il se passe ? si je fais ça avant est-ce que ça marche toujours ? Si je demande 1000 fois plus de vertices, est-ce que c'est toujours utilisable ?

Et en 2 heures j'avais déjà un premier résultat sympathique. J'ai vite compris comment ça fonctionnait et j'ai repris le livre sur les shaders pour mieux le comprendre. En 3 jours j'avais déjà de quoi faire une toute petite démonstration où j'affichais, en utilisant un shader, 200000 vertices/frame à quelques dizaines de fps.

Conclusion, et ensuite ?

Mon premier contact avec les dernières technologies 3D est vraiment enthousiasmant et je commence à comprendre l'engouement général. Je me demande d'ailleurs pourquoi il n'est pas plus important.

J'ai des souvenirs d'application de calcul qui auraient grandement bénéficié d'une utilisation intensive du GPU. Je pense à des applications de cartographie/géodésie qui demandent des calculs assez lourds (projection conique, cylindrique, interpolation linéaire, changement de système géodésique à 7 paramètres...) et qui en général faisaient s'effondrer un Athlon 2400+... Je pense aussi au projet SETI ou encore à ce projet de dépliage de protéines... Je pense aussi à POV... Augmenter la puissance d'un cluster en rajoutant des cartes graphiques ?

Une bonne semaine. En plus d'un nouvel environnement de travail, de nouveaux collègues, de nouvelles technos, un bon langage (Ada), une mise en selle rapide, et un bonheur de vendredi soir : "J'ai bien bossé"

Et maintenant j'ai envie de m'acheter un Geforce 6800 :-).

Courte (Trop) apologie de SVG et de Deer Park Alpha 2

2005-08-31T22:26:00.000+02:00

La beta de Firefox 1.1 (ou 1.5...) qui s'appelle Deer Park Alpha 2 démarre, espérons, une période de prospérité et de joie permanente pour les développeurs Web.

Au dela des améliorations du moteur de rendu HTML/CSS pour lesquelles j'ai peu d'intérêt (à part peut-être si on peut encore se servir de I Must Not Fear ou encore Delicious Delicacies), Deer Park apporte un support assez "complet" du format SVG.

SVG est un format d'image vectoriel.

Mais pourquoi un format vectoriel de plus, bigre ? On a déjà AI (Adobe Illustrator), PDF (Adobe, Portable Document Format), PS (Postscript), DXF/DWF (Autodesk Autocad). On trouvera aussi le format de Dia, de Sketch, et d'une myriade d'autres éditeurs de graphiques vectoriels.

Le premier intérêt de SVG ici est qu'il s'agit d'une recommandation W3C. Le W3C qui fait XML, XHTML, CSS, DOM et toute une foultitude de recommandations dérivées, qui ont souvent pour dénominateur commun l'idée de faire du Web un monde meilleur. Bien qu'il ne s'agisse que de recommandations, celle-ci sont promulgées par des groupes de travail composés par les poids lourd du logiciel (IBM, Sun, Microsoft...) et font souvent office de "norme" fixe. On peut en lisant les recommandations, créer une implémentation complète de n'importe quel "standard" W3C.

SVG est donc un format ouvert.

Ensuite, c'est un format basé sur XML. Avec tous ses avantages : lisibilité, simplicité, propreté, universalité (il faut bien sûr disposer d'un parseur XML pour traiter du SVG). On peut le styler à l'aide de XSL ou CSS, le manipuler grâce aux interfaces DOM définies (DOMScripting, Ajax, tout çà...), le mixer avec un autre format XML (XHTML par exemple) grâce aux namespaces.

Une des utilisations les plus intéressantes de la nature "XML" de SVG est la génération grâce à XSLT. Prenez une feuille de données XML sur les statistiques de fréquentation de votre site, puis créez 2 feuilles XSLT. L'une va vous faire générer du XHTML et transformer vos statistiques en tableau, l'autre va vous faire générer du SVG pour dessiner des histogrammes, camemberts, courbes. Avec les mêmes informations de base, créez 2 représentations. Ensuite, avec le DOMScripting, faites interagir vos 2 représentations (rien de bien sorcier, le DOM SVG ressemble beaucoup au DOM XHTML) et vous avez une interface de statistiques riche, modifiable à souhait, indexable (le texte dans vos images est lisible par le moteur de recherche) en très peu d'efforts.

Pour les dessins plus complexes, SVG dispose de fonctions avancées et puissantes : filtres, dégradés...
Vous pouvez dessiner des courbes (paths) de toutes les formes possibles, en bézier quadratique ou cubique, ou de point à point.

Vous pouvez réutiliser les objets présents dans le dessin pour faire suivre, par exemple, une courbe à un texte.

Plus fort encore, vous pouvez déclarer des animations. Animer un objet suivant un chemin défini ailleurs, animer un attribut (couleur, taille de police, dégradé, caractéristique de dégradé), utiliser des keytimes pour vos animations non linéaires... SVG est très puissant.

Au niveau de la "lourdeur" du format, tout a été fait pour que les éléments de base du format (les paths) soient optimisables en taille (coordonnées relatives, séparateurs facultatifs, espaces facultatifs...).

On peut même intégrer des images externes (en binaire/base64 ou en donnant l'adresse du fichier grâce au namespace XLink) et vous en servir comme textures...

SVG est un format très complet. Un très bon concurrent de Flash.

Point de troll ici. Flash c'est très bien, très puissant, le runtime fait seulement 500Ko, et Macromedia ne cesse d'améliorer son outil, et Flash dispose en plus d'une base installée très importante. Dès qu'on veut un site animé, joli, très interactif, on travaille avec Flash.
Oui le format swf de Flash est ouvert. Flash peut même charger des images SVG et les afficher.

Alors pourquoi SVG ? Pourquoi un nouveau format ?
Chacun son intérêt.

Mais SVG reste sérieusement le meilleur outil pour les graphiques générés côtés serveur (ou client, merci XSLTProcessor dans les navigateurs modernes...) et pour fournir des images légères, agrandissable à envie sans pixeliser (même s'il y a une limite) et qui puisse profiter du grand engouement présent pour Ajax et l'applicatif Web.

Je reparlerai sûrement de ce format, sachant que c'est ce format avec lequel j'ai beaucoup travaillé.

Mais je tenais à lever mon chapeau bien haut pour l'équipe qui programme le renderer SVG (NATIF!) pour Mozilla. La liste des fonctionnalités implémentées est loin d'être complète mais on peut déjà travailler avec les fonctionnalités présentes (pas de super filtres, patterns complexes et dégradés bien chiadés) mais la partie DOMScripting fonctionne comme un charme, et est même mieux implémentée que le viewer majeur du monde SVG (Adobe SVG Viewer 3.03), même si la version 6 beta rattrape pas mal de choses mais ne sortira jamais officiellement (stagne depuis juillet 2003)...

Bravo Messieurs, continuez ! Mon travail n'en est que plus agréable.

Premier blog, premier post, un compliment.