www.g-truc.netThe latest G-Truc Creation projects and newsthu, 10 jul 2008 10:00:00 GMTfrNewshttp://www.g-truc.net/news.html#news0137http://www.g-truc.net/news.html#news0137thu, 10 jul 2008 10:00:00 GMT Parfois builder un projet C++ peut prendre du temps... beaucoup de temps! Chez e-on software attendre 30mins pour un build est une habitude quotidienne... pour les développeurs Windows! Sous Mac automatiquement make -j12 sur les octocores donnent au build multithread tout son sens! Grâce à Arnaud [Calvin1602] Masserann le build Windows à pris un bon coup de boost! Automatiquement, Visual Studio 8 est capable de paralléliser le build des projets qui n'ont pas dépendance entre eux. Malheureusement, c'est un cas assez limité, mais heureusement, il y a /MPx! /MPx est une option à ajouter à la ligne de commande de compilation d'un projet Visual Studio 8 et qui lance autant d'instances de 'cl' qu'indiquer par la commande /MPx (/MP8 pour 8 instances par exemple). J'ai effectué quelques tests sur mon Q6600 + 2Go de RAM tournant sous Windows XP 32. Quake 4 SDK 1.3 (default): 35s Quake 4 SDK 1.3 (/MP2): 25s Quake 4 SDK 1.3 (/MP4): 20s Quake 4 SDK 1.3 (/MP8): 21s Irrlicht 1.4 (default): 43s Irrlicht 1.4 (/MP4): 14s Irrlicht 1.4 (/MP8): 14s Xerces lib 2.8 (default): 71s Xerces lib 2.8 (/MP4): 26s Xerces lib 2.8 (/MP8): 27s Le gain est donc vraiment significatif même si assez variable suivant les projets. J'ai noté une utilisation assez importante de mémoire, les 2 Go sont par loin d'y passer, je pense que sur une machine équipée de Vista et utilisé de manière plus vaste que seulement build un projet, les 4 Go de RAM ne feront pas de mal. Newshttp://www.g-truc.net/news.html#news0136http://www.g-truc.net/news.html#news0136thu, 03 jul 2008 23:00:00 GMT JeGX d'oZone3D.net m'a offert la possibilité d'avoir un forum sur son site pour pouvoir discuter des activités de mon site. Un grand merci à lui ! J'espère que vous appréciez de partager votre feedback sur ce forum. Un post est disponible à propos de la réflexion sur les GPUs que j'ai commencé avec MatRem. Newshttp://www.g-truc.net/news.html#news0135http://www.g-truc.net/news.html#news0135tue, 24 jun 2008 00:00:00 GMT La réflexion sur les GPUs que j'avais commencé il y a quelques temps à pris une tout autre envergure notamment grâce à la participation de Mathieu [MatRem] Roumillac que je remercie pour son esprit critique et sa rigueur en terme de modélisation UML. Nous avons créé de nombreux diagrammes pour montrer différent aspect, point de vue du GPU. Les résultats ne nous conviennent pas encore tout à fait mais voici deux diagrammes issus de cette réflexion qui à n'en pas douter, continuera à s'enrichir. Ces diagrammes ont très probablement certains manquent et nous n'avons pas hésiter à ajouter nos suppositions. Ils sont donc à lire avec un oeil critique et non pas comme des vérités strictes. Bien entendu, tout commentaire est bien venu, d’ailleurs ces diagramme en aurait bien besoin … Cela viendrait avec le temps. Newshttp://www.g-truc.net/news.html#news0134http://www.g-truc.net/news.html#news0134sat, 15 jun 2008 19:00:00 GMT J'ai tout récemment mise à jour mon environnement de développment, en intégrant TortoiseSVN à Visual Studio ! Ceci est possible grâce au menu "external tools" dans "Tools" et l'utilisation de TortoiseSVN en ligne de commande. Update tous les fichiers de la solution: /command:update /path:"$(SolutionDir)" /notempfile /closeonend Commit tous les fichiers de la solution: /command:commit /path:"$(SolutionDir)" /notempfile /closeonend Diff sur le fichier actif: /command:diff /path:"$(ItemPath)" /notempfile /closeonend Log des commits sur le fichier actif: /command:log /path:"$(ItemPath)" /notempfile /closeonend Newshttp://www.g-truc.net/news.html#news0133http://www.g-truc.net/news.html#news0133mon, 30 may 2008 21:00:00 GMT Suite à ma réflexion du design de Küken et pour présenter "OpenGL" chez e-on software je me suis lancé dans la création d'un diagramme d'activité UML représentant les traitements et les flux de données qui gravitent dans d'une carte graphique. J'ai finalement obtenu le diagramme suivant. Trouver le bon type de diagramme UML qui pourrait représenter ceci fut déjà une grande étape mais il est clair que ce diagramme seul n'est pas suffisant pour donner une bonne appréciation des contraintes liés à la programmation GPU, pour monter d’où l’on vient et où l’on se dirige. N'hésiter pas à m'envoyer un commentaire sur ce diagram ou sur vos idées pour réprésenter le GPU. Newshttp://www.g-truc.net/news.html#news0132http://www.g-truc.net/news.html#news0132mon, 18 may 2008 21:00:00 GMT Après 2 années passées chez e-on software à bosser sur Vue, je me dis qu'il est temps de trouver un nouveau défi ! Je recherche donc un nouveau boulot, je ne limite pas mes recherches à la France mais au monde. Je n'ai pas de recherche spécifique au delà d'être lié à la 3D, l'essentiel est ce que l'offre pourrait m'apporter et comment je pourrais mettre en oeuvre mon expérience, mes connaissances et mes idées. Newshttp://www.g-truc.net/news.html#news0131http://www.g-truc.net/news.html#news0131mon, 24 mars 2008 16:00:00 GMT Une nouvelle version de GLM est disponible à present sous license MIT. La documentation a été largement complété et de nombreux bugs ont été corrigé. Newshttp://www.g-truc.net/news.html#news0130http://www.g-truc.net/news.html#news0130fri, 14 mars 2008 01:00:00 GMT Depuis maintenant un moment, j'ai commencé à travailler sur un nouveau "moteur 3D" entièrement orienté shader avec un terme la vocation d'être massivement multithreadé. Soyons honnête, le projet est vraiment à son commencement. Pour la première release, j'ai simplement prévu d'intégrer un renderer OpenGL 2 mais il manque encore bien des fonctionnalités. Le code est disponible sur SVN et utilise GLEW et GLM. Newshttp://www.g-truc.net/news.html#news0129http://www.g-truc.net/news.html#news0129web, 16 jan 2008 23:00:00 GMT Le G-Tut Pack a été mis à jour avec trois nouveaux samples. Un premier propose une méthode de rendu dans un vertex buffer. Le second donne un exemple de vertex texturing et enfin le troisième évoque l'alpha to coverage, c'est à dire la possibilité d'antialiaser une texture qui contient des texels non visible. L'alpha test pour le multisampling en somme. Newshttp://www.g-truc.net/news.html#news0128http://www.g-truc.net/news.html#news0128sat, 12 jan 2008 15:00:00 GMT Dans une news du 11/01/2006, deux ans presque jour pour jour, j'évoquais mon passage à Visual Studio 8 au travers d'un benchmark mettant en œuvre GCC 3.2, GCC 3.4, Visual C++ 7.1 et Visual C++ 8.0. les résultats étaient alors peu flatteur pour Visual C++ 8.0. Visual C++ 7.1 caracolait alors en tête suivit de près par GCC 3.4, Visual Studio 8.0 étant largement en retrait. Ces tests avaient été effectués sur mon raytracer avec un Athlon XP 2800+. Aujourd'hui, j'entame ma migration vers Visual C++ 9.0 bien que Visual C++ 8.0 soit toujours mon IDE de référence tout simplement car tous les outils (DevPartner, VTune) ne sont pas encore près pour Visual Studio 2008. Le test est maintenant réalisé sur un Core 2 Q6600 ce qui laisse l'opportunité d'activer les optimisations SSE2 ainsi que la compilation en 64bits. Ce test montre que globalement les performances n'ont pas évolué depuis Visual C++ 7.1 si l'on s'arrête sur le mode 32 bits et sans optimisation SSE. L'utilisation des optimisations SSE permet de gagner environ 20% de performances. Passer en 64 bits permet de gagner encore environ 10% de performances. Selon ce test Visual C++ 8.0 SP1 est pour le moment le plus efficace particulièrement en 64bits. Le schéma suivant donne le temps en seconde pour la génération d'une image avec mon raytracer.