Yomgui

PyMUI v0.4

Yomgui — Fri, 30 Apr 2010 11:13:00 +0200

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.

Altivec vs SSE

Yomgui — Fri, 29 Jan 2010 10:18:00 +0100

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

Wikions ensemble

Yomgui — Tue, 14 Jul 2009 18:02:00 +0200

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.

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

Yomgui — Mon, 08 Jun 2009 11:28:00 +0200

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.

Pour changer un peu

Yomgui — Thu, 09 Apr 2009 15:08:00 +0200

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.

Test Python/PIL pour la vidéo

Yomgui — Mon, 30 Mar 2009 19:16:00 +0200

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:

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

Helios: Taaadaaa !!

Yomgui — Fri, 27 Mar 2009 10:16:00 +0100

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

Quoi de neuf depuis la dernière fois?
...Presque tout! Effectivement j'ai:

fait une nouvelle API ;
fixé 7236569754 bugs ;
rajouté le mode isochrone en réception ;
rajouté 2 exemples en C pour utiliser l'API ;
rajouté quelques options à FWInspect ;
modifié fondamentalement certaines partie pour plus de simplicité et de vitesse ;
et plus encore...

Alors le plus intéressant est évidement ce petit bout de code get61883.c que vous retrouverez dans SDK/Examples/. Il vous permet de charger des flux DV ou MPEG2-TS venant du premier noeud FW qui envoi ce type de données. Bien-sûr il vous faudra le compiler avant pour l'utiliser. Mais j'ai pensé à tout, voilà un binaire tout prêt!

La syntaxe est très simple: get61883 [-dv] output
Par défaut il ne prend que les paquets MPEG2-TS, mais avec l'option -dv il s'attend au format DV. output étant évidement le nom du fichier qui contiendra vos données.

ATTENTION: Il faut lancer FWInspect avant, car le bus doit être stable pour pouvoir trouver qui envois des données 61883!

ATTENTION: comme vous allez le voir avec les compteurs de taille et de vitesse qui s'afficheront, cela va très vite! 6 minutes de MPEG2-TS c'est déjà plus d'1Go! Avec des flux à 3.2Mo/s c'est certain...
Par ailleurs, je gère les fichiers avec des tailles en 64bits, donc vous inquiétez pas!

Dernière chose: mplayer arrive parfaitement à gérer ces formats

Helios: et la lumière fut !

Yomgui — Thu, 26 Mar 2009 09:58:00 +0100

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

Helios: 299 792 458 m/s

Yomgui — Mon, 02 Mar 2009 11:35:00 +0100

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...

Décidément en ce moment j'arrête plus de poster sur mon blog... si cela continue on va dire que je suis un blogueur (et pas un blagueur comme me le propose le correcteur orthographique).

Donc je disais que j'ai fais un petit essai de mesure de vitesse de lecture avec Helios. Les conditions de tests étaient:

2 Pegasos (I et II) reliés avec un câble IEEE-1394 (6-6) formant l'ensemble du réseau.
Helios tournant sur le Peg2, le Peg1 étant l'unité lue.
Utilisation du module Python.

Dans ce dernier j'ai utilisé la propriété timer d'un objet Device qui retourne le 3-tuple correspondant au temps du bus (secondes, nombre de cycles (8000/s), offset du cycle (horloge de 24.576MHz modulo 3072)).

J'ai donc encadré par 2 appels à cette propriété la méthode Read de Device pour lire un bloque de 10 Méga-Octets en mémoire du Peg1, depuis le Peg2. Cette méthode provoque des transactions asynchrone de type lecture blocs sur le bus. Une boucle for permettant de découper la taille demandée en morceaux d'une taille limitée par la contenance maximale d'un paquet asynchrone IEEE1394.
Tout ceci rajoute évidement un plus dans le temps par-rapport à un appel C direct, mais les résultats montrerons que l'impacte est minime.

Les 2 Pegs ont un mode vitesse maximal de S400 et en asynchrone à cette vitesse un paquet peut transporter jusqu'à 2048 octets. J'ai donc obtenu une vitesse d'environs 9Mo/s... Il faut savoir qu'en premier je n'avais pas utilisé la vitesse S400, mais S100, qui donne un résultat de 5Mo/s!

Par la suite j'ai modifié le code C du module python pour encadrer l'appel à la fonction Helios Helios_DoAsyncTransaction() qui s'occupe d'initialiser, d'envoyer et d'attendre (Wait()) la réponse d'une transaction asynchrone quelconque. J'ai utilisé ici ReadEClock() de timer.device. Cela permet d'éliminer le rajout de temps par les appels à travers les couches Python.
Un résultat approchant les 10Mo/s montrant 2 choses: 2 timers hardware différents donnant des résultats cohérents validant les vitesses et le code python bien optimisé pour ne pas rajouter trop de temps.

Mais revenons aux résultats même: voici les vitesses maximales en Méga-bits/s (Mb/s) pour chaque vitesses standards possibles sur un bus IEEE1394a:

S100 : 98304000 Mb/s
S200 : 196608000 Mb/s
S400 : 393216000 Mb/s

On en déduit donc une taille maximale de données transportées par paquets (la bande passante par paquet donc):

S100 : 1536 octets
S200 : 3072 octets
S400 : 6144 octets

De notre résultat d'environs 5 Mo/s en S100 en asynchrone on en retient donc que 50% de la bande passante est utilisée.
Et de notre résultat d'environs 10 Mo/s en S400 en asynchrone: c'est 20% de la bande passante qui est utilisée.

Le résultat en S400 n'est pas très bon... Bon pour l'instant Helios n'est pas en phase d'optimisation et la création du paquet, sa mise en place la liste de lecture de la DMA du chipset OHCI1394, ainsi que l'attente du résultat rajoute pas mal de temps supplémentaire. Mais surtout il faut voir que je n'utilise pas ici la DMA de la meilleure façon qu'il soit: je pose un descripteur pour mon paquet, puis j'attends le résultat. C'est très simple, mais très mauvais pour les performances!

Effectivement il faut savoir que la DMA se programme. On lui donne une liste de descripteurs de paquets à envoyer et on attend les résultats après. Ainsi les paquets asynchrones peuvent être envoyés au plus vite, sans attendre les réponses les unes après les autres. Ce qui est le principe même du mode asynchrones après tout.

Helios possède en l'état un bloc mémoire de 64Ko pour créer la liste de descripteurs en envois et un descripteur fait 64 octets (il faut 1 descripteur pour 1 paquet, tout types confondus). On peut donc préparer 1024 paquets à l'avance (bon en faite c'est pas possible à l'avance, dès que le bus est prêt on envoi, les descripteurs suivants s'attacheront à la suite). En S400, cela implique 2Mo de données qui peuvent être ainsi mis en tampons pour l'envoi.
Donc vous le voyez je perd beaucoup de temps pour rien à attendre la réponse d'un paquet pour envoyer le prochain!

Mais attention, il y a une limite aussi en réception où j'utilise ici seulement 2 descripteurs en mode remplissage continue : quand l'un est plein je le retire de la liste, j'utilise le premier pour la suite et j'ajoute un nouveau à la suite de celui-ci pour garantir les cas de dépassement, et c'est repartis pour un tour... Mais si jamais un paquet arrive et qu'il n'y a pas de descripteur pour le recevoir ce paquet est annulé et il doit être recommencé.

Donc il faudra que je refasse le module Python pour qu'il puisse remplir au plus vite la DMA et quand même temps il récupère les réponses. Cela me fait dire que la fonction Helios_DoAsyncTransaction() est peut-être très sympathique pour le développeur mais très dangereuse pour les performances!

Notes: en tout cas avec une optimisation nulle on a déjà 10 fois mieux que l'USB 1.x et je crois aussi bien que l'USB 2.0! ... en asynchrone!

EDIT 2009/03/05

Hier soir (enfin plutôt ce matin...), en modifiant largement le code du module Python plus quelques optimisations dans le code d'Helios, j'ai atteint la barre des 20Mo/s !!! Soit dans les 18Mo/s de façon stable (si vous n'avez pas trop de processus qui viennent embêter). Pour info, le seul port filaire sur le Peg2 plus rapide est le Giga-Ethernet (20Mo/s = 160Mb/s).

Helios Reloaded

Yomgui — Wed, 18 Feb 2009 18:31:00 +0100

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

Après plus d'une semaine de combat brutal avec un virus, non pas sur le Peg (pas possible), mais dans mon propre body à moi que j'aime, je reprend Helios à bras le corps!

J'ai eu quelques petits soucis de conception de l'API pour faire gérer les données dans le cas où le noeud de destination est aussi le noeud d'envoi... En clair quand on envoi un paquet en local.
Gros pépins, API complexes, code lourd, etc, j'ai donc décidé de reprendre les bonnes vielles méthode: papier, ~~ciseaux, caillou,~~ crayon!
Et hop, re-design complet du schéma de transmission sur le bus pour tous les cas possibles et visualisation claire de la vie et mort des blocs de données mémoires.

Résultat très intéressant (enfin je code là...), je pense enfin avoir trouvé la meilleure API à donner. Claire, simple, évolutive, respect du système (MsgPort à donf!), tout est là!

J'en ai profité au passage pour nettoyer mes fichiers et l'arborescence du projet pour incorporer des nouveautés:

Une conception modulaires: la création d'un répertoire DEVS:Helios/ qui contiendra les modules dédiés. Sorte de device améliorés.
L'abandon de l'avc1394 telle aujourd'hui pour devenir un module.
L'ajout du module iec61883, qui fournira un service FCP (Fonction Control Protocol) sous forme de serveurs, utilisés par le module avc1394 par exemple.
la configuration des modules et d'Helios en MUI, permettant une intégration facile dans le système.
Un module python (déjà écrit en parti).

Que du bon quoi...

Pour les livraisons, je fini le nouveau design d'Helios pour se qui est de la transmission asynchrone et je livrerai cela pour tests avec toujours l'application FWInspect (augmentée de quelques fonctionnalités déjà implémentées).
Ensuite j'attaque l'isochrone, en réception au moins. Puis le module iec61883, et l'avc1394. J'ajoute une nouvelle GUI pour le système, avec la gestion des modules (+ GUI pour chacun), un petit programme tout simple juste pour utiliser l'AVC et livraison tout cela pour tests. Je pourrai enfin attaquer le mode isochrone en envois et compléter les modules en cours, et hop re-livraison.

Et enfin je pourrai faire mon appli que je rêve depuis tout ce temps: capture/écriture de vidéo sur support DV.

Note: faudra que j'insère quelques part l'écriture de la doc d'utilisation aussi... un jour

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

Yomgui — Fri, 30 Jan 2009 14:12:00 +0100

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

Je viens tout juste hier de refaire Hélios pour qu'il puisse utiliser uniquement des boites-aux-lettres, système de messages utilisés pour faire des IPC.

Avec ça je me suis dit que j'allais enfin pouvoir faire l'avc1394.device.... bah c'est plus compliqué!

Effectivement c'est mieux que l'ancienne version qui pouvait manger tous les signaux disponibles des tâches systèmes. Mais cela ne résout en rien le pb du protocol AV/C...

Pour faire simple pour demander par exemple à votre caméra à quelle image elle se trouve, vous devez d'abord lui envoyer une commande qui correspond à cette demande. Ceci se traduit en 1394 par une transaction complète. Et là vous n'avez pas encore votre réponse et c'est là mon souci: la transaction est du type écriture, donc la réponse à celle-ci n'est qu'une sorte d'acquittement. Si cette écriture doit provoquer l'envoi d'un résultat, ces données viendront par une toute autre façon:
La caméra viendra elle-même répondre en envoyant un paquet 1394 d'écriture aussi, contenant le-dit résultat, à une adresse CSR définie par le standard AV/C ($fffff0000D00 pour être précis... oui c'est sur 48bits les adresses 1394!).

Donc il va falloir dire à Hélios que si un nœud (la caméra ici) veut nous dire quelque chose à cette adresse, c'est que c'est une réponse à une requête faite précédemment par une application.

Le problème c'est que le paquet de réponse de la caméra n'est en rien lié avec une requête, en gros impossible de savoir qui a demandé se résultat jsute en regardant le paquet entrant...!

Ceci implique donc quelque chose d'important: si une application souhaite communiquer avec un noeud supportant l'AV/C, cette communication doit être unique dans l'espace et dans le temps, c.-à-d. que:

aucunes autres applications ne peut venir demander des infos si l'application courante attend une réponse.
une application donnée ne peut demander quelque chose, si et seulement si elle n'est pas en attente d'une réponse.

Finalement tout cela pour dire que faire un avc1394.device n'a aucune utilité et que je peux faire une simple bibliothèque fonctionnant en synchrone uniquement (à cause point 2).

Helios: ayé!

Yomgui — Mon, 26 Jan 2009 11:24:00 +0100

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.

Cliquez sur l'image pour voir en plus grand.

Helios: AV/C(ésar)

Yomgui — Thu, 15 Jan 2009 18:44:00 +0100

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.

Helios: enfin stable!

Yomgui — Mon, 12 Jan 2009 11:18:00 +0100

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

Mon Peg2 à alzheimer!

Yomgui — Tue, 06 Jan 2009 12:13:00 +0100

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.

Helios: retards...

Yomgui — Fri, 19 Dec 2008 18:26:00 +0100

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

Un cadeau de noël pour MorphOS?

Yomgui — Mon, 08 Dec 2008 16:12:00 +0100

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!

Pour mes 30 ballais

Yomgui — Thu, 04 Sep 2008 13:17:00 +0200

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

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

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

Missing Gun

Yomgui — Tue, 15 Jul 2008 14:44:00 +0200

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):

MorphOS 2.0 est là!

Yomgui — Thu, 10 Jul 2008 16:57:00 +0200

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