Yomgui

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 30 avril 2010

PyMUI v0.4

Je refais vivre un peu ce blog en vous annoncant que je travail sur la v0.4 de PyMUI, mon module Python pour concevoir des interfaces graphique avec MUI.

Cette version est une ré-écriture complète du code C du module, avec une nouvelle façon de gérer l'interaction Python - BOOPSI. Elle laisse plus de responsabilités à l'utilisateur: un objet PyMUI est maintenant lié faiblement avec un objet BOOPSI, une classe doit-être écrite de façon à faire perdre cette lisaison par l'appel à une méthode had-hoc ou bien automatiquement dès l'appel à la méthode AddChild().

Actuellement tout à l'air de fonctionner comme dans la v0.3, sauf les MCC car j'ai un problème de design avec BOOPSI, mais je pense le solutionner aujourd'hui.


Notes: Même si c'est une ré-écriture, globalement l'utilisation (l'API et le design) est toujours la même à quelques exceptions près.

vendredi 29 janvier 2010

Altivec vs SSE

I've wanted to make same SIMD optimizations done in Blender render engine as made with SSE (Intel).

The code (Blender 2.5alpha0) is the following one:

inline int test_bb_group4(__m128 *bb_group, const Isect *isec)
{
        
        const __m128 tmin0 = _mm_setzero_ps();
        const __m128 tmax0 = _mm_load1_ps(&isec->labda);

        const __m128 tmin1 = _mm_max_ps(tmin0, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[0]], _mm_load1_ps(&isec->start[0]) ), _mm_load1_ps(&isec->idot_axis[0])) );
        const __m128 tmax1 = _mm_min_ps(tmax0, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[1]], _mm_load1_ps(&isec->start[0]) ), _mm_load1_ps(&isec->idot_axis[0])) );
        const __m128 tmin2 = _mm_max_ps(tmin1, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[2]], _mm_load1_ps(&isec->start[1]) ), _mm_load1_ps(&isec->idot_axis[1])) );
        const __m128 tmax2 = _mm_min_ps(tmax1, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[3]], _mm_load1_ps(&isec->start[1]) ), _mm_load1_ps(&isec->idot_axis[1])) );
        const __m128 tmin3 = _mm_max_ps(tmin2, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[4]], _mm_load1_ps(&isec->start[2]) ), _mm_load1_ps(&isec->idot_axis[2])) );
        const __m128 tmax3 = _mm_min_ps(tmax2, _mm_mul_ps( _mm_sub_ps( bb_group[isec->bv_index[5]], _mm_load1_ps(&isec->start[2]) ), _mm_load1_ps(&isec->idot_axis[2])) );
        
        return _mm_movemask_ps(_mm_cmpge_ps(tmax3, tmin3));
}

And this is my first working Altivec version:

inline int test_bb_group4(vector float *bb_group, const Isect *isec)
{
        int res[4] ALIGNED_16;

        const vector float v0 = (vector float) vec_splat_u32(0);
    
        const vector float tmin0  = (vector float) vec_splat_u32(0);
    
        const vector float vstart = vec_ld(0, &isec->start[0]);
        const vector float tmax0  = vec_splat(vstart, 3);
        const vector float vidot_axis = vec_ld(0, &isec->idot_axis[0]);

        const vector float tmin1 = vec_max(tmin0, vec_madd( vec_sub( bb_group[isec->bv_index[0]], vec_splat(vstart, 0) ), vec_splat(vidot_axis, 0), v0) );
        const vector float tmax1 = vec_min(tmax0, vec_madd( vec_sub( bb_group[isec->bv_index[1]], vec_splat(vstart, 0) ), vec_splat(vidot_axis, 0), v0) );
        const vector float tmin2 = vec_max(tmin1, vec_madd( vec_sub( bb_group[isec->bv_index[2]], vec_splat(vstart, 1) ), vec_splat(vidot_axis, 1), v0) );
        const vector float tmax2 = vec_min(tmax1, vec_madd( vec_sub( bb_group[isec->bv_index[3]], vec_splat(vstart, 1) ), vec_splat(vidot_axis, 1), v0) );
        const vector float tmin3 = vec_max(tmin2, vec_madd( vec_sub( bb_group[isec->bv_index[4]], vec_splat(vstart, 2) ), vec_splat(vidot_axis, 2), v0) );
        const vector float tmax3 = vec_min(tmax2, vec_madd( vec_sub( bb_group[isec->bv_index[5]], vec_splat(vstart, 2) ), vec_splat(vidot_axis, 2), v0) );
        
       const vector unsigned int vmask   = (vector unsigned int){0x1, 0x2, 0x4, 0x8};
       const vector unsigned int vmasked = vec_and(vec_cmpge(tmax3, tmin3), vmask);
       const vector signed int   vres    = vec_sums((vector signed int)vmasked, vec_splat_s32(0));

        vec_st(vres, 0, (signed int *)&res[0]);
        return res[3];
}

To use it we shall also take car to align on 16-bytes following variables:

  • isec->start
  • isect->idot_axis
  • isect->labda

Unfortunatly speed-up was not here :-(
I've got only a gain of 10% render time on the scene from the benchmark .blender file here

Today I've tried to optimize again more, by changing how I've emulated the SSE predicat _mm_movemask_ps in Altivec... a bit complex. But I need to change how this function is used also! Packing 4 unsigned int into 4 bits is a bit ... overkill.

To be continued ;-)

mardi 14 juillet 2009

Wikions ensemble

Pour ceux qui ne sont pas encores (quoi!) au courant, j'ai fait un Wiki! En même temps c'est facil on tombe direct dessus avec la racine de mon domaine. Vous retrouverez dessu plus amples infos sur mes développements par exemple.

A propos, je reconstruis Helios pour être plus proche d'un model comme celui de Poseidon (la couche USB). Vous pouvez d'ailleurs voir ce model sur ce fameux Wiki ici.

lundi 8 juin 2009

Bouge ton corps... (et tous le reste)

Info un peu tardive mais je viens de déménager en ce début de mois de juin. Pas d'ADSL donc non plus (vive le monde moderne!) pour encore qq temps et te toute façon j'ai plus de bureau pour installer mon matos qui va rester dans les cartons jusqu'à la fin du mois minimum!

Résultats: nous vous attendez pas à un quelconque avancement sur mes développements d'ici... on va dire Juillet-Août.

jeudi 9 avril 2009

Pour changer un peu

6 mois que je travail sur Helios...

J'en ai un peu marre de voir sa tronche ;-).

Je suis repassé sur Python, pour faire le port de la version 2.5.4.
C'est pas la dernière mais c'est celle supporté officiellement par les dernières versions de Blender, donc...

Sinon j'en profite aussi pour refaire le port:

  • Nettoyage du code, nouveau Makefile plus simple.
  • Virer les hacks stupides de la libc pour faire un truc propre pour le support des threads.
  • Nouveaux concepts pour l'utilisation de python.library dans les programmes.
  • Nouveaux concepts pour coder des modules dynamiques.

Évidement cela va impliquer que la prochaine version devient totalement incompatible avec l'ancienne, donc que tous les codes basés dessus devront être recompilés.

lundi 30 mars 2009

Test Python/PIL pour la vidéo

Je me suis amusé avec Python et le module PIL (python et les ''thirdparty'' sont disponibles pour MorphOS ici) à faire un script pour tester une moulinette qui me sort le waveform d'une image... c'est très utile en vidéo ;-)

Voilà la sortie du script pour une image d'exemple: waveform_sample.jpg

PS: non c'est pas une échographie de ma femme!

vendredi 27 mars 2009

Helios: Taaadaaa !!

Outre le fais que j'ai trouvé un titre pourri, Helios en version 0.3.323 est sortis depuis ce matin. Retrouver le chez votre libraire habituel sur Aminet: Helios_0.3.323.lha

Lire la suite...

jeudi 26 mars 2009

Helios: et la lumière fut !

Bon alors je me suis couché tard (4h...) donc la lumière elle vient pas de moi là... ... Mais de ma pile Firewire Helios.

J'ai codé le mode isochrone, qui au passage n'aura pris que 2 jours, et fait un petit code de test pour charger des vidéos depuis une caméra supportant le protocole iec61883 et sortant en format HDV (MPEG2-TS) ou DV.

Et ça fonctionne !!!

Bon faut que je mette au propre un peu tout cela et je fais une release...

PS: ouai c'est pas très étoffé comme news, mais ZZZZzzzzzz

lundi 2 mars 2009

Helios: 299 792 458 m/s

Avant la petite gastro de ce w.e. (ouai... encore!) j'ai fais quelques tests de vitesses avec le nouveau design d'Helios.
En voilà le récit...

Lire la suite...

mercredi 18 février 2009

Helios Reloaded

Quand ça va plus rond... il faut tout mettre au carré! Logique...

Lire la suite...

vendredi 30 janvier 2009

AV/C 1394 ou comment péter les plombs...

Alors que Hélios poursuis son développement vers une meilleur compatibilité avec le monde asynchrone, l'avc1394.device me cause bien des soucis...

Lire la suite...

lundi 26 janvier 2009

Helios: ayé!

Version pre-alpha pour bêta-bouffons-testeurs bientôt disponible... Sur aminet

EDIT: Je rajoute une petite capture de FWInspector, l'interface graphique sous MUI pour montrer et faire quelques manipulations sur les devices connectés en FireWire.

FWInspect #001

Cliquez sur l'image pour voir en plus grand.

jeudi 15 janvier 2009

Helios: AV/C(ésar)

J'ai commencé hier l'avc1394.device. Ceci permettra le contrôle de tous les device firewire supportant l'AV/C donc

...par exemple les caméras ;-)

En plus ceci donnera un exemple au programmeurs de comment créer un .device et utiliser la helios.library.
Et moi cela me valide mon SDK!

EDIT du 16.01.2009:

Ce qui devait arriver, arriva! L'écriture de l'avc1394.device m'a montré de sérieux problèmes de design quand a l'utilisation de l'helios.library! En conséquence de quoi je stop ce développement et reprend le design interne d'Helios pour le refaire encore.

Pour plus de précision, il s'agit de la gestion des requêtes et du contrôle du flux des transactions entre l'applicatif et le driver OHCI (Helios quoi). Cela me change mes structures, la façon dont l'applicatif donne une requête et la façon dont il en reçoit le résultat. En gros c'est toute l'intelligence du driver que je revois...

Bah ouai c'est ça le problème quand on fait pas un port, on est le responsable du design sur qui frapper.

lundi 12 janvier 2009

Helios: enfin stable!

Oula que j'ai bien travaillé!

Helios est enfin stable depuis samedi (et même encore plus le dimanche :-D)!

C'est donc une étape majeur dans le dév, où j'ai d'abord préférer stabiliser les requêtes asynchrones vers les nodes et donc la gestion des réponses aussi.

Donc update dans le status depuis le billet suivant:

  • Gestion des resets du bus et des packet SelfID: 100% pas vu de bug depuis.
  • Envois de requêtes asynchrone: 92%, manque juste locker les buffers DMA pouvant être utilisés par les applications en attendant qu'elles lisent les données inscrites.
  • Gestion ROM locale: 85%, je recode tout, depuis la processus de lecture dans la couche device. Il faut faire la lecture de la structure complète, pour l'instant je ne lis que le Bus Info Block. Définition de la ROM locale pas faite non plus.
  • Couche devices: 90% fonctionnelle mais elle me plaît pas encore sur la façon dont elle dialogue avec les applications.
  • API publique (SDK): 20% mais quelques changement à faire.
  • Interface MUI de configuration et de status: 0% pour la config, mais j'ai commencé FWInspect, un petit outil pour voir et utiliser le bus.

Yomgui

mardi 6 janvier 2009

Mon Peg2 à alzheimer!

Fallait bien que cela arrive un jour avec l'âge!

La compilation d'Helios stoppé nette, reboot aussi vite que l'éclair (ça arrive souvent avec gcc, alors l'habitude)... et

... et bah plus rien!!

Petit tour dans la console série reliée sur le Peg1 pour m'apercevoir un joli message du genre:

Mem test failed ...blablabla... IKARUS console ...blablabla...

Oups comme on dit!
Plusieurs reboot bien à froid plus tard pour voir aucuns changement sauf que le tests mémoire plante et montre 1 bit seulement erroné. Pas de chance, juste pour un bit, une des 2 barrette de 512 ne veut plus fonctionner, résultat ce matin un petit tour au magasin pour trouvé, 2 barrettes de 1G en DDR PC3200 (400MHz), de chez Corsaire (ref. VS1GB400C3), pas trop chère encore (83 CHF en tout donc).

Donc cool, je vais donc passer le Peg1 en 1G en translatant la barrette de 512 restante du Peg2 et passer ce dernier en .. 2 Go! ouaaaahh!

J'en connais un qui va s'amuser avec les grosses scènes sous Blender ;-)

EDIT du 07/01/09
On oublis les 2Go, je vais ne mettre qu'un seul Go sur le Peg2 et garder l'autre en backup si jamais. Le Peg1 ne sera pas modifie car c'est pas le meme type de memoire :-( (SDRAM-133). La raison est toute simple: MorphOS/ABox mappe la memoire de 0x20000000 a 0x80000000 au maximum, soit environ 1536Mo.

vendredi 19 décembre 2008

Helios: retards...

Bon, bah cela ne sera pas pour noël :-(

J'ai perdu beaucoup de temps à fixer certaine routine/algo, j'en suis un peu déçu. Surtout qu'il manque encore une couche pour que cela soit déjà utilisable rien qu'en mode requêtes asynchrones (couche device).

Pour l'instant le bilan:

  • Trouver les bridge PCI IEEE1394 et les initialiser: 100%, fonctionne correctement.
  • Gestion des interruptions PCI venant du bridge: 50%, mode ISO non supporté.
  • Gestion des resets du bus et des packet SelfID: 95%, tout est codé mais bug dans la mise à jour de la topologie.
  • Gestion des DMA: 100%, création des buffers pour les descripteurs et gestion opérationnelle.
  • Envois de requêtes asynchrone: 90%, création des packets, envois, gestions des événements, attente réponses et décodage.

Tout les types d'envois gérés, sauf stream et "block". Ce dernier n'est pas géré car je dois implémenter un système de réservation des buffers DMA consommés pour pas qu'ils soient détruit (quasi codé mais pas utiliser encore).

  • Gestion ROM locale: 80%, les requêtes locales sont codées et opérationnelles, manque juste la définition des unités dans la ROM.
  • Gestion des requêtes asynchrone venant de l'extérieur: 0%, pas commencé.
  • Envois/réception de données en isochrone: 0%, pas commencé.
  • Gestion logique (devices): 15%, juste commencé mais de toute façon j'aime pas... à refaire.
  • API publique (SDK): 10%, juste commencé.
  • Interface MUI de configuration et de status: 0%, en attente du SDK.

Bon c'est pas si méchant pour déjà avoir quelque chose, mais je pense pas avant le 15 Janvier 2009.
J'espère avoir tout fonctionnel pour la mi-février.

PS: ce qui donne déjà une bibliothèque de 55Ko.

Yomgui

lundi 8 décembre 2008

Un cadeau de noël pour MorphOS?

Depuis longtemps attendue pour être ensuite abandonnée, car tuée sur l'hôtel des profits financiers (surtout ceux d'Intel) par ses créateurs, voici de retour la venue de la pile FireWire/IEEE1394/Lynx/i.Link_<inserer ici votre marque> spécialement pour notre OS préféré, le bien nommé MorphOS!

Voui, voui, voui, vous avez bien lu!

Si vous n'avez pas bien vu encore, j'ai eu 30 ans en août!
Hein ? C'est quoi le rapport ?? Comme vous le voyez sur mon billet d'anniv, j'ai eu une caméra vidéo au format DV (HDV même) et donc avec son petit port 1394...
Ouai c'est cool mais c'est pas du tout cool sous Window... la moindre application faisant correctement de la vidéo est payante, et encore ce sont des usines à gaz!

Guerre de choix s'offre donc à vous que d'avoir un bon vieux Mac (pas le cas pour moi et cela résous pas le problème du prix, oh non!) ou bien de pirater emprunter un soft à un ami pour finalement vous dire que ouai c'est vraiment une merde un casse tête pour travailler avec.

Bon, bah y a pas trop le choix et comme je le dis régulièrement on est jamais mieux servis que par soit même.

Donc la caméra c'était en août, le bilan pas très joyeux de l'existant c'était début septembre, le voyage au Canada (histoire de dire que l'achat en valait le coup) c'était fin septembre, donc le début du projet c'était fin septembre - début octobre.

Comme tout bon développement qui se commence, j'ai commencé par voir si cela n'était pas déjà en cours (cf le premier lien du billet). J'ai donc contacté Sonic qui a en premier tenté un port de la pile Linux (cf toujours le premier lien, décidément!). Malheureusement au vu du Firewire en 2006, abandonné par ses pères, il décida qu'il ne valait plus la peine (dixit Sonic, que j'ai eu par e-mail) de continuer. Fin de l'histoire.

Dommage pour les utilisateurs, cool pour moi (ouai enfin je me donne du taf de nuit en même temps...) je saute sur l'occasion et commence à réunir la documentation après avoir vérifié le chipset en place dans mes Peg1 et 2, un VIA VT6306 (ieee1394a-1995, 3 ports). Ce qui nous donne:

  • la norme IEEE1394a-1995, ainsi que son amendement de 2000 (utile pour certaines explications sur les paquets du type Self-ID et la ROM) ;
  • la norme OHCI1394 qui elle est une couche d'abstraction pour les concepteurs de chipset comme VIA et qui nous facilite les choses pour nous les concepteurs de drivers ;
  • le datasheet du VT6303, utile pour le format des paquets de la couche PHY.

En même temps que je me prend un gros mal de crâne à lire tout cela en même temps, je passe un peu de temps sur l'implémentation sous Linux histoire de voir si j'ai bien compris les docs tordues peu triviales du Firewire.
Et zou passage au code début octobre en commençant par utiliser les nouveaux includes du SDK de MorphOS 2.x dont certains fichiers pas encore publiques quand j'écris ces lignes par ailleurs (lib PCIX pour remplacer openpci par exemple).
D'ailleurs j'avais jamais attaqué le PCI sur MorphOS, c'est tout de même bien ce projet ;-)

Nous voilà donc aujourd'hui (début décembre) et qu'en est-il?
Et bien après plus de 2 semaines sur un bug des plus crétin subtile, inventé par votre crétin de subtile serviteur, je gère complètement la modification temps-réel de la topologie du bus (connections/déconnections des devices)et quasiment le mode asynchrone en envoi-réception. Il me reste à:

  • débuger le code de réception des acquittements des requêtes en transmission ;
  • gérer complètement et correctement les paquets de types 'lock' et 'phy' (toujours en asynchrone) ;
  • envoyer des paquets de réponses aux paquets de requêtes reçus ;
  • terminer le code de la couche 'device' qui sera vue par l'utilisateur et par où il pourra les contrôler ;
  • coder toute la partie isochrone, le mode le plus intéressant bien-sûr ;
  • faire un petit 1394raw.device pour déjà s'amuser avec.

Vous l'aurez compris (comment ça non ?!) cette pile ne s'occupe que du transport de données entre les nœuds sur le bus 1394, le contrôle sera donc laisser au soins de bibliothèques en xxxxxxx.device (genre dv1394.device ou bien sbp2.device et même avc1394.device).
Si tout cela marche bien j'espère pas moins que sont intégration officielle dans MorphOS 2.x (3.x?) à l'instar de son homologue USB: Poseidon.

Voilà, voilà pour les nouvelles ;-)

PS: Je me disais bien que j'avais oublié quelque chose d'important: cette pile n'est pas un port, mais bien un truc développé sur et pour MorphOS!

jeudi 4 septembre 2008

Pour mes 30 ballais

Voilà mon cadeau pour mes 30 ans, un nouveau joujou fort sympathique:

CanonHV30

Maintenant il me reste plus que quelques subtiles améliorations à faire pour obtenir ceci:

hv30_custom_1.jpg hv30_custom_2.jpg hv30_custom_3.jpg

HV30 custom de NextWaveG sur le forum HV20
Cliquez sur les images pour voir en grand

mardi 15 juillet 2008

Missing Gun

Je viens d'optimiser la routine du en mode Bohek du noeud Blur de Blender.
J'ai donc tester cela sur une scène demandant pas mal de flou.
L'optimisation fait gagner plus de 25% de temps! Et cela tout CPU confondus!

En voilà le rendu (cliquez sur l'image pour la voir en entier):

missing_gun.png

jeudi 10 juillet 2008

MorphOS 2.0 est là!

Mon OS favori est enfin sorti publiquement en sa version 2.0.
Pour fêter cela et pour m'entrainer avec Blender 2.46 j'ai fait une petite animation.
Dès que j'ai un peu de temps je fait un tutorial pour montrer la conception.

Télécharger l'originale (AVI-XVID)

Ou bien en flux WEB:


MorphOS 2.0 summer clip test

- page 1 de 2