Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » La conquête des coprocesseurs DSP
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

La conquête des coprocesseurs DSP

Posté le 22/09/2020 10:42

Contexte, le DSP intégré et les DSP du SPU

Récemment, j'ai redécouvert avec l'aide de Yatis que le SH7305, le microprocesseur qu'on trouve dans les calculatrices SH4 (y compris les Graph mono récentes et la Graph 90+E) possède un module de traitement de son (SPU) avec deux DSP.

Pour information, un DSP est un coprocesseur dédié au traitement du signal. C'est une sorte de processeur qui travaille en parallèle du processeur central et possède un jeu d'instructions permettant de traiter rapidement des signaux. C'est donc particulièrement adapté au traitement du son. Leur existence est très intéressante car on peut dans une certaine mesure les détourner pour faire d'autres tâches intensives. Mon plan par exemple c'est de faire des shaders 2D avec.

Il y a une poignée de ressources parlant de DSP ([1], [2], [3]), mais en fait la plupart concernent un DSP intégré au processeur central, documenté dans la section 6 du manuel du SH4-AL DSP (le processeur qu'on a et qu'on appelle communément « SH4 »). Ce DSP est intéressant mais il ne tourne pas en parallèle du processeur central : pour l'utiliser, on insère des instructions DSP dans le code et dans ce cas le processeur ne fait rien quand le DSP travaille. De plus, son jeu d'instructions est difficile à détourner dans des buts graphico-ludiques (il n'a par exemple qu'une seule multiplication 16x16→32, ce qui est boiteux au possible).

Par contre le DSP intégré a deux zones de RAM appelées XRAM et YRAM de 8k chacune, qui sont foudroyantes en vitesse parce que situées près du bus processeur. Pour vous donner une idée, les memcpy() et memset() optimisé de gint tournent à 10 Mo/s et 30 Mo/s environ pour la RAM normale. Avec le DSP, on peut monter aisément à 300 Mo/s voire 450 Mo/s si on s'y prend bien. Le potentiel est très élevé pour les calculs intensifs, avec la limite que 16k c'est très peu.

Les deux DSP de l'unité de traitement de son (SPU) sont différents. Ils ont une mémoire de travail beaucoup plus grande (vaguement connue [4]), avec chacun 170k de XRAM, au moins 30k de YRAM (pas clair encore), et 160k de RAM supplémentaire pour stocker du code. Puisque la mémoire pour le code est différence de la mémoire où on stocke le programme central, ces DSP calculent vraiment en parallèle à la façon d'un processeur multi-coeurs. Le hic, c'est qu'il n'y a pas de documentation. Il faut donc rétro-analyser tout ce dont on dispose pour récupérer le fonctionnement de 0. C'est là que ça se complique...

Le modèle 24-bits et la RAM à trous

Dans la doc du SH7305, il y a une seule page expliquant les fonctionnalités principales du SPU, c'est en quelque sorte le teaser de Renesas envers ses potentiels clients ; tout le détail n'est fourni qu'aux clients qui utilisent le processeur pour de vrai. Mais la doc explique déjà que le DSP manipule des mots de 24 bits, qu'on peut imaginer sont des valeurs en point fixe pour représenter des échantillons de signal. C'est différent du DSP intégré donc d'emblée on sait que le jeu d'instructions sera différent.

Ce qui est un peu casse-pieds, c'est que la XRAM et la YRAM sont à trous pour faciliter le travail du DSP. Vous voyez, un signal est souvent vu comme un tableau d'échantillons géant. Le problème c'est qu'avec des valeurs de 24 bits (trois octets), atteindre le n-ème échantillon demande de calculer n*3, ce qui prend du temps en électronique. Les processeurs ont depuis longtemps pris l'habitude d'utiliser des types de données à 1, 2, 4 ou 8 octets (des puissances de 2) parce que multiplier par des puissances de 2 est immédiat en électronique (il suffit de déplacer les fils et d'ajouter des 0). Ici, le DSP fait un truc encore plus fourbe : il place un mot de 24 bits (3 octets) tous les 4 octets, en ignorant un octet sur 4. Le premier mot couvre les adresses 0, 1, et 2 ; le second couvre les adresses 4, 5 et 6 ; le troisième, les 8, 9 et 10 ; et ainsi de suite.

Comme les adresses 3, 7, 11 etc sont inutilisées, le constructeur a trouvé malin de ne pas réellement y mettre de mémoire. Du coup la XRAM et la YRAM sont hyper fragmentées, avec un trou tous les quatre octets. Impossible donc d'y stocker un simple int puisqu'il n'y a pas 4 octets de mémoire d'affilée. Il faudra donc être malin pour faire marcher ça. Par contre, le RGB888 ça passera crème pourvu qu'on arrive à calculer avec efficacement.

Qu'y a-t-il à faire et où va-t-on ?

Actuellement je désassemble le programme de Renesas qui émule le SH7305 (d'ailleurs utilisé dans les émulateurs de Casio) pour déterminer quels sont les registres périphériques des DSP, comment les initialiser, les utiliser, et j'espère trouver le jeu d'instructions. Il y a pas mal de choses à comprendre :

• Liste des registres périphériques : fait
• Allumage et initialisation : en bonne voie
• Transfert de données via DMA intégré : en bonne voie
• Fonctionnement de la RAM et des bus : ?
• Jeu d'instructions : ???
• Horloge : ?

Ce sera un bon début pour cette fois.


Kbd2 En ligne Membre Points: 239 Défis: 0 Message

Citer : Posté le 22/09/2020 11:49 | #


This is very intriguing, especially the 2D shader part!
Hackcell En ligne Membre Points: 1375 Défis: 11 Message

Citer : Posté le 22/09/2020 11:56 | #


Sha-chan nous a déjà, fais le coup du module wifi, tu nous auras pas comme ça

Plus sérieusement, c'est follement exitant
Yatis Hors ligne Membre Points: 543 Défis: 0 Message

Citer : Posté le 22/09/2020 13:28 | #


Je vais essayer d'apporter un peu de ce que je sais pour compléter.

En gros, la partie SPU est hiérarchisé en 4 modules :
* SPU2 - celui qui gère et ordonnance les autres modules
* SPU2DP0 - Le DSP0
* SPU2DP1 - Le DSP1
* SPU2RAM - Les différentes zones de RAM que le SPU offre.

En désassemblant le bootcode de Casio, je suis tombé sur un petit bout de driver utilisé uniquement lors d'un redémarrage a froid et qui semble initialiser le SPU et le FSI pour une raison obscure (je pense que c'est utilisé pour déboguer la machine de l'extérieur car il me semble que H-UDI est impliqué dans la manœuvre de Casio). En tout cas j'ai pu réussir à accéder aux différentes RAMs. Reste à savoir en quoi le module SPU2 peut influer sur les zones de RAMs (car il a certains de ses registres qui sont en lien avec le module SPU2RAM).

J'ai aussi documenté le module CPG qui permet globalement de gérer la fréquence des différents bus / clock et je tiens à signaler qu'il y a registre pour le SPU justement. En sois, il me reste encore à documenter le module BSC pour être sur mais il me semble que l'horloge du module peut être modifiée uniquement ici.

Après ce qui est sympa c'est que les deux DSP sont probablement construit en miroir ce qu'il signifie qu'une fois qu'on en a documenté un, l'autre est identique (ou presque). Donc en sois, il n’y a pas tant de chose à RE pour avoir quelque chose de fonctionnel. Le truc qui est long c'est qu'on est dans le noir total pour avancer (car Casio ne l'utilise pas ou peu) et qu'on est obligé d'y aller en tâtonnant. Mais j'ai bon espoir pour la documentation du module.

Je pense qu'il y a effectivement pas mal à jouer en détournant le SPU de son but premier (pour aider à certaines actions graphiques par exemple). Il faudra en parler à Ninestars pour son moteur 3D, parce qu'il a probablement beaucoup à gagner avec ce module.
Massena Hors ligne Rédacteur Points: 1591 Défis: 11 Message

Citer : Posté le 22/09/2020 20:42 | #


J'ai rien compris mais je sens qu'il y a un truc lourd qui se prépare (notamment lorsqu'on lit "shader") :3
Bientôt un gint 3.0 ?
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 25/09/2020 13:34 | #


Ha ha je ne suis pas surpris que ce soit les applications qui donnent le plus l'eau à la bouche. Attention cela dit, je n'ai pas encore d'informations quantitatives sur la puissance de calcul que ça offrirait, c'est surtout des estimations par expérience de Yatis à moi à manipuler la matériel et mes propres observations sur les capacités de la Graph 90.

Le point le plus subtil c'est le jeu d'instructions, avec deux questions cruciales : (1) Peut-on rétro-analyser le jeu d'instructions ? et (2) Peut-on détourner efficacement le jeu d'instructions ?. Dans le cas du moteur 3D de Ninestars, s'il n'y a pas au moins une multiplication décente c'est vraiment pas gagné d'avance. (Par contre il peut mettre tous ses buffers dans les RAM DSP et gagner 15% de perfs en plus. )

Bientôt un gint 3.0 ?

Les règles de versionnage sémantique réservent les montées de versions majeures aux modifications incompatibles d'API ou de fonctionnement. En tant qu'extension, l'ajout du DSP ne serait qu'une nouvelle version 2.x.

Yatis a pas mal couvert la partie horloge, merci !

Je continue de désassembler comme je peux et de tester les perfs. Le RE est assez imprévisible donc il n'y a jamais de garantie qu'on va réussir à progresser sur la compréhension des mécanismes. Je vous tiens au courant.

Là j'ai commencé à m'occuper du DMA, je désassemble ce que je trouve comme code pour comprendre les différents champs de CHCR et le fonctionnement des buffers de communication inter-DSP.
Dark storm En ligne Membre d'honneur Points: 11324 Défis: 176 Message

Citer : Posté le 25/09/2020 14:15 | #


Pour rétro-analyser le jeu d'instructions, je ne sais pas si tu connais ce site, mais il y a une catégorie dédiée au DSP. Si les instructions sont les mêmes suivant les différentes familles de processeurs, ça peut être un début de piste.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 25/09/2020 14:38 | #


Non, c'est juste un dump de la documentation du SH4AL-DSP. Ça ne concerne que le DSP intégré ; les autres ont définitivement un jeu d'instructions différent.
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 29/09/2020 14:39 | # | Fichier joint


Un bout de conversation avec Kbd2, qui contient des informations intéressantes ; pour pas que ça se perde



Ajouté le 03/10/2020 à 18:43 :
J'ai pas mal progressé sur la question, ayant réussi à comprendre la logique majeure du DMA et déterminé la plupart des interruptions. Pour l'instant je ne sais pas encore comment programmer le DMA dans les détails, mais ça s'approche. Je crois que le DMA est complètement cassé aussi à cause de quelques bugs, mais je confirmerai avec les tests si besoin.

Comme l'émulation du DMA utilise beaucoup le mécanisme d'allocation de mémoire de l'émulateur, j'ai dû toucher à ça aussi.

J'ai également joué avec les interruptions et je pense avoir obtenu la liste exhaustive des signaux d'interruptions, par un ID interne mais aussi par les registres IMR et IPR. Il y a définitivement des choses passionnantes à sortir !

Pour l'instant, aucune trace de l'émulation du DSP en tant que processeur. Si ça se trouve il est pas émulé ; c'est encore trop tôt pour conclure mais je garde cette (triste) possibilité en tête.
Yatis Hors ligne Membre Points: 543 Défis: 0 Message

Citer : Posté le 03/10/2020 21:43 | # | Fichier joint


J'ai également joué avec les interruptions et je pense avoir obtenu la liste exhaustive des signaux d'interruptions, par un ID interne mais aussi par les registres IMR et IPR. Il y a définitivement des choses passionnantes à sortir !


J'en profite pour donnée mes notes sur l'INTC (fichier joint). C'est toujours en cours de RE mais il me semble avoir trouvé le contrôle des interruptions venant des deux DSP(?) (IMRx et IPRx). Si tu arrives à me devancer dans la recherche de cette partie (ce qui sera forcément le cas vu le peu de temps que j'ai devant moi) tiens-moi au courant.
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 07/10/2020 11:32 | #


Effectivement ce que tu as trouvé pour les DSP est correct (je l'ai redécouvert indépendamment). Dans l'émulateur les interruptions sont identifiées par des entiers de 8 bits. J'ai listé tous ces IDs internes pour lesquels une priorité peut être calculée (il y a une fonction qui renvoie ça), et aussi tous ceux pour lesquels la fonction qui active les interruptions est appelée. Mon but serait de partir de ça et ensuite de nommer tous les signaux qu'on a testé et vérifiés sur la calculatrice pour pas se retrouver avec des modules multimédias du SH7724 qui n'existent en fait pas.

J'ai préparé ça et intégré les infos dans ton fichier joint, merci ! Je publierai ça bientôt. J'ai les IPR et IMR pour presque tout avec juste un problème relatif à l'ADC à voir.
Yatis Hors ligne Membre Points: 543 Défis: 0 Message

Citer : Posté le 07/10/2020 11:47 | #


J'ai les IPR et IMR pour presque tout avec juste un problème relatif à l'ADC à voir.

Mes travaux sur l'ADC m'ont amené à penser qu'il y a plusieurs moyens de déclencher une mesure : via le DMA et/ou via un des TMU. Seulement, je n'ai réussi à trouver comment configurer l'ADC pour tester mes hypothèses. Mais je pense que ça pourrait t'aider dans tes recherches car il doit y avoir de la redirection d'interruptions possiblement émulée quelque part.

En tout cas, bravo pour tes découvertes, j'essaie de te rejoindre le plus vite possible dans la documentation du MPU
Lephenixnoir Hors ligne Administrateur Points: 19373 Défis: 142 Message

Citer : Posté le 08/10/2020 20:22 | #


Alright, j'ai presque fini de décortiquer le DMA. Il ne me reste qu'une poignée de paramètres à étudier, ensuite je pousserai mon début de doc sur la bible ! Stay tuned.

Si tout cela s'avère correct sur la calculatrice, ce que j'ai découvert complète ce que Yatis sait déjà et permettra de :
• Démarrer le SPU et ses DSP (ça Yatis sait faire).
• Accéder à la PRAM, la XRAM et la YRAM de chaque processeur (ça Yatis y arrive mes les tailles des zones sont louches).
• Utiliser le DMA pour copier efficacement des données entre la RAM normale et la XRAM/YRAM/PRAM de chaque DSP.
• Et quelques détails avancés de DMA, conversion de l'endianness, différentes tailles d'accès, etc.

Tout cela donnerait déjà beaucoup de mémoire rapide supplémentaire et serait un joli boost pour les add-ins ! Notamment pour remplacer la deuxième moitié de RAM (88040000:256k) qui était libre jusqu'à la Graph 35+E II mais plus depuis, utilisée notamment par C.Basic, CasioPython et FxGnuBoy.

C'est pas révolutionnaire mais ce sera une partie indispensable de tout usage optimal d'un DSP. Le tout après c'est que le DSP soit émulé dans la DLL sinon on ne peut rien faire avec. Si par chance le DSP est émulé, je pense qu'il y aura beaucoup à en tirer car il est apparemment conçu spécifiquement pour décoder de l'audio, la doc citant AAC et MP3. MP3 utilise des transformées trigo et de Fourier donc il doit définitivement y avoir du calcul en point fixe ou flottant disponible. Le DSP peut aussi recevoir des interruptions et contrôler le DMA sans l'aide du CPU donc il doit y avoir au moins des registres internes de 32 bits et des fonctions logiques/arithmétiques décentes. On croise les doigts !

Ajouté le 09/10/2020 à 11:16 :
Upload time! o/

Voici la version préliminaire de la doc d'après ce que j'ai tiré de l'émuateur. J'ai pas encore testé sur calto donc je ne vous conseille pas de le faire sauf si vous voulez faire du RE à proprement parler. Ce sera implémenté assez vite sur la branche dev de gint avec une API propre si vous voulez tester dans vos programmes.

Autre bonne nouvelle, le DMA intégré aux DSPs du SPU a un mode de transfert qui lit et écrit dans la XRAM et la YRAM en sautant les trous. Ça veut dire qu'on peut au moins archiver et récupérer des données quelconques dans ces zones de façon efficace sans s'embêter à gérer les trous. Ce qui est extrêmement pratique si vous avez des données lourdes mais que vous pouvez implémenter une politique de swap efficace !

Voici les pages que j'ai poussées sur la bible :

SPU: DSP Reset
SPU: DSP Interrupts
SPU: DSP DMA channels (le plus complet !)
INTC: Interrupt sources, comme discuté avec Yatis

Ajouté le 10/10/2020 à 17:58 :
J'ai fait d'autres découvertes aujourd'hui, et... je crois que j'aurai bientôt fini le module SPU. C'est surprenant à dire parce que je ne pensais pas qu'il était possible d'isoler proprement un module dans une aussi grosse DLL et de le désassembler de fond en comble.

Actuellement j'ai un grand bloc de code, entièrement désassemblé et bien compris dans l'ensemble, qui commence par la routine d'initialisation du SPU et se termine par le code d'écriture dans la RAM spécifique du SPU, qui est coincé entre du code du MSIOF1 (rien à voir) et du FSI (rien à voir non plus dans un certaine mesure).

Le plus gros, c'est-à-dire l'existence et l'utilisation de coprocesseurs DSP, reste à établir. Pour l'instant je n'ai pas vraiment de certitudes ; ils peuvent être émulés ailleurs, ne pas être émulés, ou ne pas exister. Pour l'instant on a probablement la RAM en plus, le temps que j'arrive à faire marcher ça proprement dans gint (avec quelques indices de Yatis), ce sera déjà bien.

Notez que je n'ai pas non plus vu la moindre trace de l'émulation du bon vieux processeur SH4 donc clairement je n'ai pas tout vu.

Ajouté le 12/10/2020 à 21:14 :
Update rapide après pas mal de discussion avec Yatis. Deux mauvaises nouvelles essentiellement :
• Les DSP du SPU ne sont probablement pas émulés voire pas présents sur la calculatrice.
• La PRAM et la XRAM est probablement partagée entre les deux DSP, ce qui réduit la quantité de RAM supplémentaire à ~450k.

Bon tout ça reste pas dégueu. Je vais refaire un tour sur le DSP intégré pour voir si on peut l'abuser d'une façon ou d'une autre.

Ajouté le 21/10/2020 à 11:03 :
Time for a summary of the discoveries so far (in English since it's an important one x3).

Available SPU memory:
• PRAM0: 160 kiB, 4-byte access only, continuous
• XRAM0: 224 kiB, 4-byte access only, every 4th byte is not writable (total memory: 168 kiB)
• YRAM0: 64 kiB, 4-byte access only, every 4th byte is not writable (total memory: 48 kiB)
• YRAM1: 64 kiB, 4-byte access only, every 4th byte is not writable (total memory: 48 kiB)
Total memory: 424 kiB, 62% with holes

Non-existence or non-availability of the SPU DSPs:
The SPU normally comes with two DSPs, DSP0 and DSP1, but there is no trace of any emulation code and no documentation so even if they exist we don't know how to use them.

Availability of the SH-4AL integrated DSP:
Our CPU, the SH4-AL, comes with an integrated DSP that has a limited but usable instruction set along with two memory regions called XRAM and YRAM of 8k each. This is our fastest processing unit because of high data/memory parallelism and a decent lead for computation-intensive tasks and color manipulation.

SPU memory sharing mechanisms:
All the SPU memory can be accessed from the CPU and the integrated DSP. Parts of PRAM0 and XRAM0 (which belong to DSP0) can be shared with DSP1 (in two regions called PRAM1 and XRAM1) with a bank mechanism, but we mostly don't care because we don't have these DSPs and we can already access all of the memory from PRAM0 and XRAM0.

SPU DMA for fast access to SPU memory: (still under testing)
The SPU comes with some DMA channels that allow fast access to PRAM0, XRAM0, YRAM0 and YRAM1. In particular, these channels have a "compacting mode" that store or retrieve continuous data to and from XRAM0, YRAM0 and YRAM1 by skipping the holes, which would make for a very efficient storage method.

Ajouté le 23/10/2020 à 23:11 :
Voici le fonctionnement détaillé du partage de mémoire SPU entre les deux DSP.

Il y a 5 pages de PRAM et 7 pages de XRAM, toutes de 32 kiB adressables (32 kiB de données par pages de PRAM, 24 kiB de données par page de XRAM). Ces pages peuvent être attribuées soit à DSP0, soit à DSP1.

Le registre PBANKC0 possède 5 bits représentant le statut de chaque page de PRAM pour DSP0. Avoir le bit n à 1 indique que la page n est accessible depuis DSP0, c'est-à-dire depuis PRAM0 (fe200000). Avoir le bit à 0 indique que la page n'est pas accessible. PRAM0 est toujours continu, donc si seules les pages 0 et 2 sont actives pour DSP0, alors fe200000 pointera vers la page 0, fe208000 pointera vers la page 2, et toue le reste à partir de fe210000 pointera dans le vide.

Il en va de même pour PBANKC1 vis-à-vis du DSP1. Les pages sont exclusives et on ne peut pas y accéder depuis les deux DSP en même temps ; si le bit d'une page est à 1 à la fois dans PBANKC0 et PBANKC1, alors la page est attribuée à DSP0 et invisible depuis DSP1.

La XRAM fonctionne pareil au détail près qu'il y a 7 pages et pas 5. Les registres PBANKC0, PBANKC1, XBANKC0 et XBANKC1 ont tous 24 bits en lecture-écriture mais seuls les 5 (PRAM) ou 7 (XRAM) premiers ont un effet.

La YRAM est privée, et contient 64 kiB de mémoire adressable pour chaque DSP (48 kiB de données, pour un total de 96 kiB).

Ajouté le 24/10/2020 à 00:15 :
J'ai mis à jour la documentation du SPU sur la bible avec ces informations. Encore un grand pas sur la documentation et le test de toutes ces choses !

Je n'attends plus de nouvelle fonctionnalité sur le SPU désormais, donc je planifie uniquement de documenter proprement ce que j'ai trouvé, et de bien tester ce qu'on peut sortir de performant sur les transferts de données, le DMA, et le DSP intégré du SH4-AL.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2021 | Il y a 69 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