Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » gint : un noyau pour développer des add-ins
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

gint : un noyau pour développer des add-ins

Posté le 20/02/2015 17:30

Les SDKs classiques pour écrire des add-ins sont le fx-9860G SDK de Casio avec fxlib (pour Graph monochrome) et le PrizmSDK avec libfxcg (pour Prizm et Graph 90+E). Voici mon alternative : le fxSDK avec gint, pour toutes les plateformes.

Contrairement à fxlib et libfxcg, qui appellent les fonctions de l'OS pour faire leur travail, gint est un noyau indépendant de l'OS qui exploite seul le matériel et le met à disposition de votre add-in. Il vous offre plus de finesse sur le contrôle du matériel, notamment le clavier, l'écran et les horloges, de meilleurs performances sur le dessin, les drivers et la gestion de interruptions, et des choses entièrement nouvelles comme le moteur de gris.

Toutes les sources de gint sont publiques et accessibles sur la forge de Planète Casio :

» Dépôt Gitea Lephenixnoir/gint «

Voici plus précisément ce que gint vous offre de nouveau :

• Un contrôle détaillé du clavier pour les jeux, parfait pour les combos !
• Des timers avec une précision de 60 ns, d'autres à 30 µs
• Toutes vos images converties automatiquement sans code à copier (plus de Sprite Coder)
• Des polices personnalisées
• Des fonctions de dessin, d'images et de texte fulgurantes et optimisées la main
• Mesurer les performance de votre code à la microseconde près (avec libprof)
• Le contrôle du matériel et des interruptions
• Plein de petites choses pratiques comme dprint(1, 1, "x=%d", x)

• (Graph monochrome) Un moteur de gris pour faire des jeux en 4 couleurs !
• (Graph monochrome) La compatibilité SH3 et SH4, avec le même fichier g1a.

• (Graph 90+E) Une nouvelle police de texte, plus lisible et économe en espace
• (Graph 90+E) Le dessin en plein écran, sans les bordures blanches et la barre de statut !
• (Graph 90+E) Un driver écran capable de triple-buffering

Le coût de tout ceci, c'est que vous avez une copie du code de gint dans votre add-in. Cela prend environ 20 ko de place (selon la quantité de fonctions que vous utilisez), soit à peu près comme le sprintf() de fxlib qui fait 18 ko !

Et voici quelques photos et captures d'écran !





Tester gint sur votre machine

La fin du portage vers la Graph 90+E signera la sortie de gint v2. L'add-in de test de l'application est désormais gintctl :

» Dépôt Gitea Lephenixnoir/gintctl «

En plus de tester les fonctionnalités de gint, cet add-in contient quelques outils permettant d'inspecter la machine, la mémoire, et les registres. Je le développe au fur et à mesure, et je posterai un protocole de test complet avec la sortie de la v2 !

Utiliser gint pour développer des add-ins

Normalement, vous avez besoin du fxSDK pour développer avec gint. Le fxSDK est compatible avec Linux et Mac OS, et on peut réfléchir à un portage sous Windows s'il y a vraiment des intéressés. Il faut l'installer en premier (et avoir un cross-compilateur GCC).

La procédure de compilation et d'installation de gint est décrite sur le README du dépôt, c'est du configure - make tout à fait banal.

Une fois que gint est installé sur votre système, voyez les tutoriels de développement pour avoir un aperçu de son fonctionnement. La plupart des choses sont expliquées dans les en-têtes (fichiers .h) de la bibliothèque que vous pouvez consulter en ligne, sur votre copie locale du dépôt, ou dans les dossiers d'installation du compilateur.

Obtenir la dernière version de gint après une mise à jour

Je pousse régulièrement des mises à jour de gint sur le dépôt du projet. Pour les télécharger, tapez git pull, puis recompilez et réinstallez gint avec make et make install.


Fichier joint


Pages : Précédente1 ... , 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28Suivante
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 06/08/2019 16:19 | # | Fichier joint


Du côté de fxconv tout est bon, il ne supprime pas de ligne ou de colonne tant que tu ne spécifies un area sur la ligne de commande. Je viens de tester avec ton image, la première colonne est bien là.

Ce que tu décris doit marcher tout seul, c'était bien un bug dans l'algo de tracé ! (Un bug que j'avais déjà vu mais pas corrigé totalement, con comme je suis...) J'ai corrigé et poussé, Je te joins un g1a qui démontre le code fonctionnel ci-dessous et trace chaque élément de ton image indépendamment.

Merci de ta patience avec mon code encore jeune...

#include <gint/display.h>
#include <gint/keyboard.h>

int main(void)
{
    dclear(C_WHITE);
    dtext(0, 0, "Sample fxSDK add-in.", C_BLACK, C_NONE);

    extern image_t img_brouillard;
    dimage(0, 9, &img_brouillard);

    for(int i = 0; i < 16; i++)
    {
        dsubimage(4 + 16 * (i&7), 32 + 16 * (i>=8), &img_brouillard,
            8 * i, 0, 8, 8, DIMAGE_NONE);
    }
    dupdate();

    getkey();
    return 1;
}
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 06/08/2019 18:25 | #


Super, ça marche, merci beaucoup ! bon au début ça a pas marché 3x de suite parce que j'avais pas make install, mais là c'est bon x)
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 08/08/2019 23:07 | #


Bon... j'ai intégré la pull request de Milang (merci encore !) et commencé à tester dclear() avec un dma_memset().

La première chose à noter est que le DMA part avec un désavantage. Pour memset(), la version CPU naïve contient l'opérande de remplissage dans un registre donc tous les accès à la RAM sont faits en écriture. Le DMA, à l'inverse, est obligé de relire l'opérande à chaque cycle de lecture/écriture et fait donc deux fois plus d'accès en RAM.

Sur la même taille de 4 octets par accès, le DMA met donc 15 ms alors que la version CPU naïve met 6 ms.

Heureusement le DMA peut copier jusqu'à 32 octets par bloc, mais ça nous amène aussi à 6 ms.

La solution que j'ai trouvée est de placer l'opérande source dans une mémoire plus rapide que la RAM ; et là ça se complique. Principalement il y en a deux : la mémoire RS et la mémoire IL. Quand je place mon opérande dans la mémoire RS, le transfert se complète en 2.5 ms. Cependant la mémoire RS est utilisée pour des choses critiques comme le redémarrage et il est hors de question d'y toucher sur des add-ins en production. Quand je place l'opérande en mémoire IL, les accès par le DMA freezent.

J'ai des pistes pour avancer un peu mais c'est pas gagné tout de suite. D'un autre côté la mémoire IL est très rapide et est un super plan pour mettre du code ou des données critiques, donc ça vaut le coup de rechercher.

Notez que pour memcpy(), cette fois-ci le CPU perd son avantage car il est lui aussi obligé de lire les données en RAM, en plus de lire le code en ROM (mais pas longtemps car le cache prend le relai je suppose).

Enfin, je cherche vaguement la possibilité qu'il y ait un 2D-DMA dans le microprocesseur, qui pourrait copier des zones non continues pour afficher rapidement des images de n'importe quelle taille. En effet avec le DMA on ne peut qu'afficher des images qui font toute la largeur de l'écran, à savoir 396 pixels, c'est assez restrictif. SimLo n'indique pas de 2D-DMA dans sa doc mais ça ne coûte rien d'en chercher un je suppose.

Voilà voilà, un peu de recherche en perspective.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 09/08/2019 14:31 | #


De toute façon, même si le temps pris par le dma est supérieur, cela ne fait rien si on peut faire autre chose en même temps
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 09/08/2019 14:53 | #


Well, pas tout à fait, parce que seuls les cycles de calculs sont vraiment économisés. Il n'y a qu'un seul bus et c'est chacun son tour. Tous les cycles où tu fais des accès mémoire, le DMA ne peut pas tourner. De plus, c'est pas forcément codé de façon à te permettre de faire autre chose en même temps... x_x

J'ai progressé. En cherchant un peu j'ai découvert que le problème qui se pose quand j'utilise la mémoire IL comme source est en fait une erreur d'adresse juste après la fin du transfert. C'est assez bizarre, et les effets dépendent aussi du channel DMA utilisé. Pour l'instant j'ai un contournement qui consiste à faire un transfert sans interruptions, et ça marche bien !

Donc dclear() ne prend plus 6 ms mais 2.5 ms. Yay !

Côté un peu moins bien maintenant, j'ai voulu tenter de faire une copie d'une image en plein écran vers la VRAM avec le DMA. C'est très facile à coder, mais un problème subsiste : l'image est dans la ROM, plus précisément dans la zone de la ROM qui est mappée en userspace... et n'est donc pas forcément continue sur le stockage physique, selon les caprices du système de fichiers. Or le DMA interagit quasi-exclusivement avec l'espace d'adressage physique. Et donc, la copie n'est pas possible dans le cas général...

Je vais aller voir dans le TLB quelle taille font les pages et comment elles sont agencées mais je pense que c'est 64k, et qu'une image en plein écran prend donc 3 pages. La continuité n'est donc pas garantie. On peut réfléchir à découper le transfert en 3 si l'image est extrêmement bien alignée, mais ça reste très fin. Ce ne sera sans doute pas le comportement par défaut...

Ah et btw, j'ai mesuré avec libprof le temps de dessin, exactement comme Darks le suggérait. Comme prévu, c'est 24.8 ms, soit un poil plus que 40 FPS. Avec le dclear() et les épées par-dessus, on passe en-dessous donc le programme n'arrive plus à suivre les entrées clavier (qui sont à 40 Hz par défaut dans gint). Je vais continuer de chercher des optimisations pour améliorer ça au bas niveau qu'est gint, pour que vos applications bénéficient des meilleures performances possibles.

Au passage, pour les fonctions qui écrivent directement en RAM, la facteur limitant est la vitesse de la RAM donc les optis comme dérouler des boucles pour réduire le temps CPU n'ont quasiment aucun effet.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 17/08/2019 20:02 | #


J'ai un problème en utilisant le dma :

J'ai un zbuffer que je dois effacer à chaque frame. Ce buffer est aligné sur 32 octets grâce aux fonctions suivantes :
#define ALIGN 32
static void* buffer_malloc(uint_fast16_t size)
{
    void *mem = malloc(size+ALIGN+sizeof(void*));
    void **ptr = (void**)((uintptr_t)(mem+ALIGN+sizeof(void*)) & ~(ALIGN-1));
    ptr[-1] = mem;
    return ptr;
}
static void buffer_free(void *ptr)
{
    free(((void**)ptr)[-1]);
}


Pour effacer le buffer à chaque frame j'utilise la fonction suivante :
static const int32_t clearval[8]={3000,3000,3000,3000,3000,3000,3000,3000}; // je remplis le buffer avec la valeur 3000
void FE_zbuffer_clear()
{
    if (isSH3())
    { // effacer avec le CPU
        uint_fast16_t indice;
        for (indice = 0; indice < size_uint32; indice ++)
            address[indice] = clearval[0];
    }
    else
    { // effacer avec le DMA
        dma_transfer(0, DMA_32B, size_blocks, &clearval, DMA_FIXED, address, DMA_INC);
    }
}

Logiquement, je copie donc mon tableau de 4 octets dans le zbuffer qui est aligné sur 32 octets.
Enfin, j'attends par sécurité que le transfert s'achève avec dma_transfer_wait(0); avant d'écrire dedans

Cependant, lors des tests, je m'aperçois que les valeurs présentes dans le zbuffer avec le memset du dma ne sont pas celles obtenues avec l'effacement du cpu >_<
Quelle est l'erreur dans mon utilisation du dma ?

Ajouté le 17/08/2019 à 20:08 :
J'ajoute que *src (clearval) est également aligné sur 32 bits grâce à cette fonction
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 18/08/2019 21:06 | #


Je te fais confiance sur l'allocation ; n'oublie pas que tu peux simplement écrire __attribute__((aligned(32))) uint16_t zbuffer[...] si tu peux l'allouer en statique. Vérifie juste au cas où que le pointeur est bon...

clearval devrait être aligné sur 32 octets, tu peux justement utiliser cette technique :

#include <gint/defs/attributes.h>

GALIGNED(32) GSECTION(".rodata") static const int32_t clearval[8]={3000,3000,3000,3000,3000,3000,3000,3000}; // je remplis le buffer avec la valeur 3000

Et au passage le placer explicitement en ROM ne fait pas de mal.

Sinon ça m'a l'air légitime...
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 18/08/2019 22:43 | #


L'allocation statique, j'aimerais bien, mais je ne suis pas sûr qu me cela fonctionne pour 32 768 octets d'un coup
Sinon merci pour tes conseils, j'essaierai la semaine prochaine
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 19/08/2019 10:17 | #


Milang a écrit :
L'allocation statique, j'aimerais bien, mais je ne suis pas sûr qu me cela fonctionne pour 32 768 octets d'un coup

Tu peux utiliser la zone statique sur SH4, elle fait 64k contre 8k sur SH3. Quitte à modifier un poil le linker script...

Sinon tu as la fin de la RAM qui est semble-t-il libre.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 19/08/2019 11:31 | #


Cela me parait une bonne option.

Cependant, il y a des points qui m'échappent :
Si j'alloue statiquement un tableau de 32 ko, cette opération ne fonctionnera jamais sur les modeles sh3 et je ne sais pas du tout comment modifier le linker script
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 19/08/2019 11:59 | #


Les SH3 disposent de la deuxième moitité inutilisée de RAM. Tu peux certainement juste faire :

static const int32_t *zbuffer = (void *)0x88080000 - 32768;

ce qui te place tout à la fin de la RAM. Faudra juste vérifier que c'est libre sur la Graph 35+E II (de mémoire oui, mais ne me crois pas sur parole avant de tester sur cette machine) et c'est bon.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 19/08/2019 12:17 | #


Mais c'est genial ça !
Je code ça tout de suite. (par contre je n'aurai accès à mon pc pour compiler et tester seulement la semaine prochaine

Quand à la graph 35 e II, ben je n'en ai pas, donc ce sera aux risques et perils du premier heureux (ou pas ) testeur.


Ajouté le 26/08/2019 à 15:12 :
J'ai l'impression d'avoir trouvé un bug dans le dma, probablement au niveau de la fonction dma_transfer_wait

#include <gint/display.h>
#include <gint/keyboard.h>
#include <gint/dma.h>
#include <gint/std/stdio.h>
#include <gint/defs/attributes.h>

#define size 32768
#define clear_val 0xFFFFFFFF
GALIGNED(32) GSECTION(".rodata") static int32_t clear_vals[8]={clear_val,clear_val,clear_val,clear_val,clear_val,clear_val,clear_val,clear_val};

static int32_t *clear_zone = (void *)0x88080000 - size;

int main(void)
{
    clear_zone[size/4-1]=0;
    
    dma_transfer(0,DMA_32B,size/32,clear_vals,DMA_FIXED,clear_zone,DMA_INC);
    
    dma_transfer_wait(0);
    
    int val=clear_zone[size/4-1];

    char txt[10];
    sprintf(txt,"%d",val);
    dclear(C_WHITE);
    dtext(1, 1, txt, C_BLACK, C_NONE);
    dupdate();
    getkey();
    return 1;
}


Alors que le programme devrait m'afficher quelque chose comme -1, il me retourne 0
(J'execute le code sur une g35++ sh4 2.05.2201)

Ajouté le 26/08/2019 à 15:24 :
ça se précise !
le problème ne vient pas de dma_transfer_wait, mais de dma_transfer , ce que je prouve grâce au code suivant :
#include <gint/display.h>
#include <gint/keyboard.h>
#include <gint/dma.h>
#include <gint/std/stdio.h>
#include <gint/defs/attributes.h>

#define size 32768
#define clear_val 0xFFFFFFFF
GALIGNED(32) GSECTION(".rodata") static int32_t clear_vals[8]={clear_val,clear_val,clear_val,clear_val,clear_val,clear_val,clear_val,clear_val};

static int32_t *clear_zone = (void *)0x88080000 - size;

int main(void)
{
    clear_zone[size/4-1]=0;
    
    dma_transfer(0,DMA_32B,size/32,clear_vals,DMA_FIXED,clear_zone,DMA_INC);
    
    //dma_transfer_wait(0);
    while (clear_zone[size/4-1]==0)
        0;

    int val=clear_zone[size/4-1];

    char txt[10];
    sprintf(txt,"%d",val);
    dclear(C_WHITE);
    dtext(1, 1, txt, C_BLACK, C_NONE);
    dupdate();
    getkey();
    return 1;
}


Ajouté le 26/08/2019 à 15:29 :
en fait, même avec dma_transfer_noint, cela ne marche pas et la calculatrice freeze

Il y a donc un problème au niveau du transfert
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 26/08/2019 15:33 | #


As-tu essayé avec dma_memset() ? J'ai résolu des bugs non triviaux pour le faire marcher celui-là.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 26/08/2019 15:42 | #


dans quel header est-elle définie, je ne la vois pas ?
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 26/08/2019 15:44 | #


Untracked files:
  (use "git add <file>..." to include in what will be committed)

    src/core/exch.c
    src/dma/memcpy.c
    src/dma/memset.c
    src/render-cg/dimage.c

Never mind?

Je te pousse ça dès que j'ai plus de quelques minutes...

Ajouté le 27/08/2019 à 21:30 :
Voilà, c'est poussé. N'hésite pas à essayer avec dma_memset().

Par ailleurs, j'ai eu des problèmes lorsque j'ai testé cette fonction et j'ai dû me rabattre sur le DMA1 sans interruptions. Utiliser le DMA0 ou utiliser les interruptions ne marchait pas. Ce bug ne se produisait que quand la source était la mémoire IL.

Au cas où tu ne connaisses pas encore, la mémoire IL est un bout de mémoire sur la puce qui est indépendant de la RAM et à accès rapide, surtout pour le code. Elle est associative à 4 voies et remplace typiquement la mémoire L1 des processeurs modernes. J'ai expliqué un peu les enjeux dans #168088 ; en gros quand je passe par la mémoire IL le comportement est plus erratique. DMA1 sans interrputions semble marcher.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 27/08/2019 22:27 | #


ok, je vais essayer
Je trouve quand même étrange que le channel 0 ne soit pas fonctionnel , peut être un erreur dans la doc...

En tout cas, cela va augmenter sensiblement les perfs je pense
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 28/08/2019 09:57 | #


Milang a écrit :
Je trouve quand même étrange que le channel 0 ne soit pas fonctionnel , peut être un erreur dans la doc...

J'ai renoncé à comprendre pour l'instant... c'est louche louche, vraiment

En tout cas, cela va augmenter sensiblement les perfs je pense

Je passe de 6 ms à 2.5 ms pour un dclear() qui était déjà bien optimisé donc je pense que oui. Avec un peu de chance ton nettoyage de z-buffer va prendre un petit ×3 (pas sûr après, l'optimisation du code ne compte peu-être juste pas quand c'est la fréquence de la RAM qui régit le débit).

Ajouté le 29/08/2019 à 15:33 :
Des nouvelles ? Est-ce que ça marche mieux avec dma_memset() ?
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 29/08/2019 15:40 | #


alors je n'ai pas encore retesté, car comme j'ai transformé fxengine en lib j'ai choisi de le restructurer, mais je vais reprendre mon programme de test et regarder
D'ailleurs, du coup j'ai du réécrire la déclaration dans mon fichier source, car à ma connaissance la fonction n'est dans aucun header
LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 29/08/2019 15:41 | #


Ah exact, j'ai dû oublier ça pendant le développement. Je vais m'en occuper.
MilangHors ligneMembrePoints: 325 Défis: 2 Message

Citer : Posté le 29/08/2019 15:47 | #


alors du coup, j'ai réouvert mon projet de test :
#include <gint/display.h>
#include <gint/keyboard.h>
#include <gint/dma.h>
#include <gint/std/stdio.h>

#define SIZE (32768)
#define CLEAR_VAL (0xFFFFFFFF)

static int32_t *clear_zone = (void *)0x88080000 - SIZE;

extern void dma_memset(void *dst, uint32_t l, size_t size);

int main(void)
{
    clear_zone[SIZE/4-1]=0;

    dma_memset(clear_zone, CLEAR_VAL, SIZE);

    char txt[10];
    sprintf(txt,"%d",clear_zone[SIZE/4-1]);
    dclear(C_WHITE);
    dtext(1, 1, txt, C_BLACK, C_NONE);
    dupdate();
    getkey();
    return 1;
}


mais le compilateur me dit
/usr/bin/sh3eb-elf-ld: /usr/lib/gcc/sh3eb-elf/9.1.0/libgint-fx.a(inth.s.o): in function `inth_dma_ae':
(.gint.blocks+0x3c): undefined reference to `dma_address_error'

LephenixnoirHors ligneAdministrateurPoints: 15998 Défis: 140 Message

Citer : Posté le 29/08/2019 15:51 | #


Ouuups xD

C'est la fonction qui déclenche le gestionnaire d'erreur quand une erreur d'adresse se produit durant un transfert DMA. Je l'ai ajoutée récemment, mais quand j'ai commit la dernière fois j'ai séparé les modifs du DMA de celles du gestionnaires d'erreur, donc le commit est incomplet...

Et bien sûr j'ai testé dans mon environnement à moi où la fonction est fournie par gintctl et du coup je m'en suis pas rendu compte...

Ajouté le 03/09/2019 à 22:37 :
Voilà, j'ai poussé tout ce qu'il fallait, à savoir les gestionnaires d'exceptions. Tu devrais pouvoir compiler maintenant, puisque j'ai fait pointer l'erreur d'adresse du DMA dessus.

Désormais, si votre code fait une opération illégale, au lieu de crasher gint affiche un message d'erreur, exactement comme une System ERROR en fait.

Si vous rencontrez un crash, alors il y a probablement un bug et un rapport de bug est le bienvenu.

Je mettrai demain des images des erreurs en question.
Pages : Précédente1 ... , 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28Suivante

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2019 | Il y a 111 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd