Mandelbrot POPOPO - Page 2

Hmmm je sais pas, tout depends de la console

dilinger (./22) :

Salut, comment fais tu pour avoir la fenêtre "output video" avec virtualjaguar Rx en mode debuger ?

J'dois être un peu con j'ai cherché partout, même dans la doc, y a rien.

DEATH (./32) :
Salut, comment fais tu pour avoir la fenêtre "output video" avec virtualjaguar Rx en mode debuger ?
J'dois être un peu con j'ai cherché partout, même dans la doc, y a rien.

Tu n'es pas con, cette feature n'est disponible que sur la version R5 que je n'ai pas encore sorti. C'est probablement la feature la plus demandé du mode debugger, cela fait bien du sens mais je n'en avais pas besoin jusqu'à récemment.
En attendant, je continues a faire des updates dans la branche "develop" de mon github.

Zerosquare (./26) :
C'est vrai, mais ça se décharge moins vite qu'on pourrait le croire. J'ai déjà testé sur la Jaguar : on peut couper l'alim pendant plusieurs secondes, et le contenu de la RAM est en grande partie préservé (une image est facilement reconnaissable par exemple, bien qu'il y ait une proportion de bits qui ont changé d'état). D'autre part il n'est pas dit que l'état déchargé soit interprété comme un zéro, avec des sense amplifiers inverseurs ça donnerait un un.

Du coup, penser que la RAM est "naturellement" initialisée à zéro est risqué. Mais c'est intéressant comme question, il faudrait faire des essais

Pas besoin d'éteindre la Jaguar pour ça, il suffit de couper le rafraichissement de la DRAM (REFRATE dans MEMCOM2). Tu peux même tester plusieurs fréquence de rafraichissement.
D'ailleurs c'est une des valeurs à modifier de préférences lorsqu'on fait de l'overclock comme tu as fais, car ça bouffe des cycles mémoire pour rien sinon.
Pour info la fréquence de rafraichissement la plus commune (pour l'époque en tout cas) pour la DRAM était de 64Khz (moitié moins pour la "L"ow refresh) et sur Jaguar compte tenu de la fréquence de l'horloge et du diviseur pour le cycle de rafraichissement on est de base à environ 69Khz (parce que sinon il fallait choisir la valeur en dessous qui faisait environ du 59Khz, donc en dehors de la plage de tolérance.
A 32Mhz avec la valeur de base initialisée par le BIOS on passe à un taux de rafraichissement de + de 83Khz et à 40Mhz + de 104Khz. Ca en fait des cycles perdus.

Zerosquare (./30) :
Je dis pas le contraire, mais si les jeux respectaient toujours les bonnes pratiques, le boulot des développeurs d'émulateurs serait beaucoup plus facile

C'est en grande partie vraie, mais il y a aussi les users sadiques ou malsains qui insultent les développeurs que l'émulateur ne correspond pas a leur souhait.
J'en ai eu qui se plaignait que ca ne tourne pas, ou au ralenti, sur leurs (très) vieilles machines moisies. En général, je réponds que les sources sont disponible, ca calme 50% du temps. Les 50% qui restent lâche l'affaire au bout d'un moment.

DEATH (./34) :
Pas besoin d'éteindre la Jaguar pour ça, il suffit de couper le rafraichissement de la DRAM (REFRATE dans MEMCOM2). Tu peux même tester plusieurs fréquence de rafraichissement.

Oui j'y avais pensé aussi, mais en fait c'est pas aussi simple :

- pas sûr que la décharge des condensateurs soit la même quand la DRAM est sous tension que quand elle est hors tension
- rien que lire la RAM fausse les choses

Par exemple, je voulais afficher une image et désactiver le refresh pour constater visuellement l'évolution, mais les accès en lecture de l'OP auront le même effet qu'un refresh, donc la méthode n'est pas valable.

dilinger (./35) :
il y a aussi les users sadiques ou malsains qui insultent les développeurs que l'émulateur ne correspond pas a leur souhait.

Ah ben ça, y'a toujours plus de gens pour râler que pour contribuer

Pour l'initialisation de la mémoire (ou du reste d'ailleurs) c'est effectivement aux émulateurs de s'adapter à la réalité.
Ne pas initialiser la mémoire à zéro (ou d'autres registres) qui est quand même la valeur la plus probable quand on allume la console, c'est prendre le risque qu'un jeu "mal programmé" certes, fonctionne sur le vrai matériel mais pas sur émulateur.

Et on en a la preuve flagrante avec mon programme avant que je corrige le bug sur VI dans le 2ème écran. Sur une vraie Jaguar la mémoire à cette endroit au démarrage est à zéro, donc malgré le bug ça "fonctionne" (VI=0 ce n'est pas si déconnant) alors que sur émulateur où la mémoire est rempli d'un peu n'importe quoi, ça plante (VI avec une valeur trop grande.... l'interruption ne se produit jamais)

ça vaut aussi pour les linker genre SkunkBoard ou JaguarGD. Si l'initialisation de la console quand ils passent la main aux programmes/cartouches n'est pas conforme à la réalité, il y a risque d'incompatibilité.

Zerosquare (./36) :

Oui j'y avais pensé aussi, mais en fait c'est pas aussi simple :

- pas sûr que la décharge des condensateurs soit la même quand la DRAM est sous tension que quand elle est hors tension
- rien que lire la RAM fausse les choses

Par exemple, je voulais afficher une image et désactiver le refresh pour constater visuellement l'évolution, mais les accès en lecture de l'OP auront le même effet qu'un refresh, donc la méthode n'est pas valable.

Il faut tout couper, 68000, OP, REFRATE... tu fais une boucle avec le GPU en local ram avec les timers interne (PIT) et quand tu atteints la valeur voulue tu réactive tout et tu regardes le résultat.
Tu peux faire aussi des tests à base de somme de contrôle.

je me trompe sans doute, mais de mémoire à l'origine VJ initialisé la ram à 0, et suite a justement des différences de comportements avec le matériel, il a été changé en initisalisant la ram à random.
Il me semble aussi qu'il y avait un paramètre à l'exécutable pour choisir en init à 0 ou random.

(SCPCD IS HERE!)

SCPCD (./40) :
je me trompe sans doute, mais de mémoire à l'origine VJ initialisé la ram à 0, et suite a justement des différences de comportements avec le matériel, il a été changé en initisalisant la ram à random.
Il me semble aussi qu'il y avait un paramètre à l'exécutable pour choisir en init à 0 ou random.

La ram se trouve dans ce que l'on pourrait appeler la .bss de l'émulateur. Elle n'est pas touché par l'initialisation de l'émulateur.
Dans la 2.1.3, il n'y a pas d'option pour toucher a la ram, et par la même ma version Rx ne l'a pas non plus. Possible que d'autres versions de l'émulateur en aient eu une. Dans tout les cas, en mettre une ne serait pas un soucis.

Un OS moderne met tout a zero si le bloc n'a jamais été utilisé par le programme en court... (question de sécurité, on ne peux pas laisser la RAM avec des données "aléatoires", il pourrait y avoir des données sensibles)

dilinger (./42) :
La ram se trouve dans ce que l'on pourrait appeler la .bss de l'émulateur. Elle n'est pas touché par l'initialisation de l'émulateur.
Dans la 2.1.3, il n'y a pas d'option pour toucher a la ram, et par la même ma version Rx ne l'a pas non plus. Possible que d'autres versions de l'émulateur en aient eu une. Dans tout les cas, en mettre une ne serait pas un soucis.

Ok
J'avais pour souvenir qu'il y avait un "rand()" exécuter dans la phase d'init sur l'ensemble des 2Mo de ram, mais je dois me fourvoyer (ça fait un paquet d'années que j'ai pas joué avec le code de VJ)

SCPCD (./44) :

dilinger (./42) :
La ram se trouve dans ce que l'on pourrait appeler la .bss de l'émulateur. Elle n'est pas touché par l'initialisation de l'émulateur.
Dans la 2.1.3, il n'y a pas d'option pour toucher a la ram, et par la même ma version Rx ne l'a pas non plus. Possible que d'autres versions de l'émulateur en aient eu une. Dans tout les cas, en mettre une ne serait pas un soucis.

Ok
J'avais pour souvenir qu'il y avait un "rand()" exécuter dans la phase d'init sur l'ensemble des 2Mo de ram, mais je dois me fourvoyer (ça fait un paquet d'années que j'ai pas joué avec le code de VJ)

Il y a bien un rand mais juste pour le output vidéo avec l'option "--please-dont-kill-my-computer | -z Run Virtual Jaguar without "snow".

C'est vrai qu'il y a bien d'autres options qu'on aimerai sur virtualjaguar

Il y a un sujet dédié quelque part ?

En attendant voici la toute dernière version optimisé du calcul au GPU.
J'ai ajouté aussi une attente d'1 seconde après l'initialisation vidéo pour laisser le temps à l'écran de se synchroniser
J'ai remis l'effacement du 2ème l'écran pour faire propre

Pour le calcul GPU, je crois que j'ai atteint une bonne limite d'optimisation avec le code d'origine.
Le plus gros du calcul c'est celui de la boucle d'un point, qui peut être répéter au maximum 256 fois. C'est le calcul fractal en lui même.
Je ne suis pas assez calé dans ce domaine (ou alors il faudrait que je m'y penche plus sérieusement) pour pouvoir toucher à cette partie.
J'ai quand même réussi à optimisé la boucle d'origine de 2, oui madame, 2 instructions (woohoo) en modifiant le comptage de la couleur et en utilisant le fait que les RISC de la Jaguar exécute toujours l'instruction suivant un JUMP (ou JR)
Bon en fait pour le comptage de la couleur j'avoue je ne gagne rien car pour gagner 1 instruction j'ai changé l'incrémentation d'origine par une décrémentation. ça m'a permit de pouvoir virer une instruction CMP pour remplacer la boucle par un SUBQ suivi d'un saut par condition.
Donc là au lieu de 3 instructions (ADDQ, CMP,JR), j'avais juste 2 instructions (SUBQ, JR). Seulement, dans le code d'origine la valeur 0 n'est jamais utilisé, la boucle s'arrête donc à la valeur 1. Sans CMP je ne peut pas atteindre cette condition sans ruser.
La ruse c'est de décrémenter de 2 au lieu de 1, et si le résultat est zéro c'est qu'on est arrivé à al fin de la boucle. Et juste après le rajoute 1 pour retomber sur la bonne valeur.... et donc je perds l'instruction que j'avais gagné.... Tout ça pour ça...

Et du coup bien sur la palette de l'image est inversée, mais c'est jolie aussi.

La boucle d'origine fait 24 instructions en comptant les nop, la version optimisée fait 22, en respectant le nombre de couleurs traités.
Par contre tout le reste du code est vraiment pas mal optimisé, mais ça ne change vraiment pas grand chose.

J'ai trouvé une routine sur Internet dont la boucle principale fait 16 instructions, mais c'est du code x86 que je ne maitrise pas. J'ai commencé à regarder mais ça commence à faire beaucoup pour un truc qui était juste pour passer le temps.
pour info : https://github.com/leto/asmutils/blob/master/src/bonus/mandelbrot.asm?fbclid=IwAR0oLAVMrQW7j5PD0nkH1PtCTvvzseucW_JlYswvTmcxyjZms795vV1Al5I
Je ne sais pas si le résultat est le même non plus. C'est une routine pour une image en 640*480*8, mais pour une fractale Mandelbrot il y a d'autres critères qui entre en compte, notamment le nombre d'itération non ?

Il faudrait que je regarde aussi la routine d'effacement de l'écran au blitter. Je n'ai pas regardé en détails et je ne connais pas assez le fonctionnement du blitter pour comprendre, mais dans la version d'origine B_COUNT est initialisé avec les valeur 256 et 200.
Normal, l'écran d'origine est est en 256*200. Logiquement je me suis dit qu'en mettant 640 et 480 dans B_COUNT ça marcherait.... ben non, je dois mettre 640*1000 sinon ça n'efface pas tout l'écran...

Fichier joint : JAGMAND.COF

Petite surprise dans 3...2..1....

Vous l'avez demandé, la voici

Version GPU - DSP

Environ 14s

Alors on sait que sur virtualjaguar les timings ne sont pas vraiment respecté par rapport à une vraie Jaguar.
Par exemple dans ce programme le GPU va plus vite que sur une vraie Jaguar.

Mais là en plus on voir que le DSP et le GPU ne vont pas du tout à la même vitesse.

Sur une vraie Jaguar je peux vous assurer que les 2 vont EXACTEMENT à la même vitesse et que les 2 terminent l'image exactement au même moment.


Fichier joint : JAGMAND.COF

Ah merci pour cette version!
J'ai pas testé les versions intermédiaire mais ce coup ci ça marche bien sur ma Jaguar relié à un TV LCD un convertisseur S-VIDEO->HDMI. Tu as bien trouvé la méthode pour faire de l'entrelacement.
T'as pas eu de problème avec le DSP? Il a des "particularités" au niveau lecture/écriture en RAM que le GPU n'a pas.

DrTypoFr (./50) :
Ah merci pour cette version!
J'ai pas testé les versions intermédiaire mais ce coup ci ça marche bien sur ma Jaguar relié à un TV LCD un convertisseur S-VIDEO->HDMI. Tu as bien trouvé la méthode pour faire de l'entrelacement.
T'as pas eu de problème avec le DSP? Il a des "particularités" au niveau lecture/écriture en RAM que le GPU n'a pas.

Oui en effet ça fonctionne impec sur Jaguar et émulateur depuis la version du 27/04

Pour le DSP c'est pour ça que j'ai ouvert un autre sujet, mais à priori si j'ai bien compris le comportement du DSP ça ne concerne pas ma routine.

Version JagFPGA en 1280x720p exécuté en 18,4s (GPU seul)



En comparaison, la version de DEATH GPU-DSP en 640x480 prend environ 3s (difficile d'avoir la valeur précise, flemme de patcher le cof pour avoir les compteurs au cycle près)

SCPCD (./52) :
Version JagFPGA en 1280x720p exécuté en 18,4s (GPU seul)



En comparaison, la version de DEATH GPU-DSP en 640x480 prend environ 3s (difficile d'avoir la valeur précise, flemme de patcher le cof pour avoir les compteurs au cycle près)

Menfin c'est quoi ce debugger ?

Un debugger que j'ai écrit spécialement pour la JagFPGA.

Il se connecte en RJ45 et j'ai du coup des transferts de plusieurs Mo/s, avec accès à tous les registres (ce qui n'est pas possible sur une vrai jag,, vu qu'une bonne partie est en écriture seule)
c'est très pratique pour vérifier que tout marche bien.

SCPCD (./54) :
Un debugger que j'ai écrit spécialement pour la JagFPGA.

Il se connecte en RJ45 et j'ai du coup des transferts de plusieurs Mo/s, avec accès à tous les registres (ce qui n'est pas possible sur une vrai jag,, vu qu'une bonne partie est en écriture seule)
c'est très pratique pour vérifier que tout marche bien.

Tu as modifié le code ? La palette est inversée.

oui, j'avais fait des optimisations similaires que toi dans la boucle GPU pour faire un subq au lieu du addq, cmp, du coup j'ai remplacé le code du chargement de la CLUT en conséquence.
move.l #256,d0 move.l #CLUT+(256*2),a0 move.l #cry_data,a1 .cloop: move.w (a1)+,-(a0) dbra d0,.cloop

SCPCD (./56) :
oui, j'avais fait des optimisations similaires que toi dans la boucle GPU pour faire un subq au lieu du addq, cmp, du coup j'ai remplacé le code du chargement de la CLUT en conséquence.
move.l #256,d0 move.l #CLUT+(256*2),a0 move.l #cry_data,a1 .cloop: move.w (a1)+,-(a0) dbra d0,.cloop

C'est justement ce que j'était en train de faire et justement il y a un bug dans le code d'origine que je viens de voir. Je me posais des question car quoi que je fasse pour modifier la couleur 0 ça n'avais jamais aucun effet.
La routine d'origine boucle en fait une fois de trop et viens donc écrire une nouvelle valeur de la couleur 0 dans F0600 (2ème table CLUT).

Il faut donc mettre move.l #255,d0

Voici la version avec les couleurs d'origines (pareil j'ai inversé le chargement de la palette et corrigé le bon nombre de transfert)

Ma version utilise 256 couleurs alors que la version d'origine en utilise 255

GPU+DSP

Source inclus

Fichier joint : JAGMAND.zip

C'est amusant car avec virtualjaguar, lors du 1er lancement le GPU et le DSP vont quasiment à la même vitesse et virtualjaguar indique 60FPS puis au bout de quelques lancement (sans redémarrer virtualjaguar) le GPU et le DSP ne vont plus du tout à la même vitesse et le compteur FPS indique un peu n'importe quoi sur le 1er écran puis indique 30-32FPS sur l'écran fractal.

SCPCD (./54) :
Un debugger que j'ai écrit spécialement pour la JagFPGA.

Il se connecte en RJ45 et j'ai du coup des transferts de plusieurs Mo/s, avec accès à tous les registres (ce qui n'est pas possible sur une vrai jag,, vu qu'une bonne partie est en écriture seule)
c'est très pratique pour vérifier que tout marche bien.

Ca déchire comme on dit. Et il faut quel genre de budget pour reproduire ton JagFPGA?