Calcul fractal Mandelbrot sur V4 en vidéo

[OL]

https://www.youtube.com/watch?v=1Qb9624x4kc

Bon c'est sous système Amiga.

[Francois LE COAT]

Salut,

OL écrit :

> https://www.youtube.com/watch?v=1Qb9624x4kc
>
> Bon c'est sous système Amiga.

C'est très classique. Au début des années 90, j'avais programmé le tracé
sur Connection Machine (CM5) en langage massivement parallèle C*. En
effet le calcul de chaque pixel est indépendant les uns des autres. Il
est possible de consacrer un processeur par pixel, pour calculer la
convergence de la suite en nombres complexes. Sachant qu'un processeur
était constitué d'un noeud SPARC. Ça allait très vite, et l'on pouvait
zoomer à la cadence de la vidéo.

Fort de cette expérience, j'ai réalisé la même chose sur ATARI, avec
le logiciel Persistence Of Vision, et en trois dimensions ...

<https://www.youtube.com/watch?v=Yf7q2KdAS-4> *POV-Ray*

Alors, sur Amiga est-il aussi possible de tracer l'ensemble de
Mandelbrot en 3D ? Avec Eurêka 2.12 il est possible de réaliser un
tel objet dans l'espace ...

<https://skfb.ly/o6TTw> *Sketchfab*

C'est très classique, l'ensemble de Mandelbrot en vidéo. Mais en 3D ?
Non, ça n'est pas l'exclusivité des machines Amiga, certainement pas !

<https://www.youtube.com/watch?v=Xw0a6P4xlPQ> *Zoom 2D*

Ça laisserait d'ailleurs penser que la V4 est particulièrement lente.
L'état de l'art des mathématiques par ordinateur a nettement progressé !

ATARIstiquement vôtre =)

--
François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org/

[OL]

Alors fais nous une petite vidéo sur ton Hades en 2D déjà, même si
l'image n'est pas bonne parce que tu l'auras pris avec ton téléphone, on
ne chipotera pas sur la qualité. Voir comment tu as progressé sur le
calcul de fractal Mandelbrot, ce serait intéressant.

[Francois LE COAT]

Salut,

OL écrit :
> Francois écrit :

>> OL écrit :
>>> https://www.youtube.com/watch?v=1Qb9624x4kc
>>>
>>> Bon c'est sous système Amiga.
>>
>> C'est très classique. Au début des années 90, j'avais programmé le tracé
>> sur Connection Machine (CM5) en langage massivement parallèle C*. En
>> effet le calcul de chaque pixel est indépendant les uns des autres. Il
>> est possible de consacrer un processeur par pixel, pour calculer la
>> convergence de la suite en nombres complexes. Sachant qu'un processeur
>> était constitué d'un noeud SPARC. Ça allait très vite, et l'on pouvait
>> zoomer à la cadence de la vidéo.
>>
>> Fort de cette expérience, j'ai réalisé la même chose sur ATARI, avec
>> le logiciel Persistence Of Vision, et en trois dimensions ...
>>
>>     <https://www.youtube.com/watch?v=Yf7q2KdAS-4> *POV-Ray*
>>
>> Alors, sur Amiga est-il aussi possible de tracer l'ensemble de
>> Mandelbrot en 3D ? Avec Eurêka 2.12 il est possible de réaliser un
>> tel objet dans l'espace ...
>>
>>     <https://skfb.ly/o6TTw> *Sketchfab*
>>
>> C'est très classique, l'ensemble de Mandelbrot en vidéo. Mais en 3D ?
>> Non, ça n'est pas l'exclusivité des machines Amiga, certainement pas !
>>
>>     <https://www.youtube.com/watch?v=Xw0a6P4xlPQ> *Zoom 2D*
>>
>> Ça laisserait d'ailleurs penser que la V4 est particulièrement lente.
>> L'état de l'art des mathématiques par ordinateur a nettement progressé !
>

> Alors fais nous une petite vidéo sur ton Hades en 2D déjà, même si
> l'image n'est pas bonne parce que tu l'auras pris avec ton téléphone, on
> ne chipotera pas sur la qualité. Voir comment tu as progressé sur le
> calcul de fractal Mandelbrot, ce serait intéressant.

Je ne doute pas un instant que la V4 est beaucoup plus rapide que mon
Hadès060. C'est un Amiga de 2020, alors que mon ATARI date de 1996 !
Heureusement que les processeurs 68k ont progressé en 25 années ...
Mais le véritable progrès que je propose, est de passer de 2D en 3D =)
Mandelbrot en 3D sur Amiga, c'est quand ? Sur ATARI ça date des 90's.

[GOOD OLD TOS]

Hello,

à vue de nez c'est un calcul très bestial sur des flottants, nul doute que cela puisse être grandement amélioré mais la vitesse de tracé est quand même assez bluffante pour du 640x360 en 128 itérations max.
Olivier, si tu pouvais lancer un calcul similaire sur Fractals tournant sur la V4, ça m’intéresse!
A+,
Jean

[Arachide]

J'ai découvert que les opérations de multiplication et division de la V4
(en flottant) n'utilisent pas les 64 bits du format double, mais
seulement 56. Les 8 derniers sont laissés à zéro.
Fatalement, déjà que la fréquence est meilleure, ils ont implanté un
algorithme plus rapide, mais moins précis.

Guillaume.

[Arachide]

Le jeudi 27 octobre 2022 à 21:50:52 UTC+2, Francois LE COAT a écrit :

> Fort de cette expérience, j'ai réalisé la même chose sur ATARI, avec
> le logiciel Persistence Of Vision, et en trois dimensions ...
>
> <https://www.youtube.com/watch?v=Yf7q2KdAS-4> *POV-Ray*

En fait tu pars d'un calcul en 2D et chaque valeur de pixel est convertie en une profondeur et une couleur. Donc ce n'est pas réellement une fractale 3D.
C'est très classique, on se servait de la même technique dans des logiciels de simulation de vol pour représenter un sol avec du relief. A partir d'un tableau 2D, chaque valeur correspondait à une altitude et une couleur (souvent blanc en haut: la neige, puis des dégradés de marron et vert pour la végétation et du bleu océan pour un niveau zéro.

Dommage que Eurêka ne se lance pas sur ma V4, j'aurai pu comparer.

Guillaume.

[Francois LE COAT]

Salut,

Arachide écrit :
> Francois LE COAT écrit :

>> Fort de cette expérience, j'ai réalisé la même chose sur ATARI, avec
>> le logiciel Persistence Of Vision, et en trois dimensions ...
>>
>> <https://www.youtube.com/watch?v=Yf7q2KdAS-4> *POV-Ray*
>
> En fait tu pars d'un calcul en 2D et chaque valeur de pixel est convertie en une profondeur et une couleur. Donc ce n'est pas réellement une fractale 3D.

En fait si, parce que la profondeur est une valeur flottante, et non pas
simplement un entier (la valeur pour l'index de couleur). J'ai implanté
l'algorithme d"approximation des distances" qui est un algorithme 3D. Il
s'agit pour la profondeur, de calculer la distance par rapport à la
frontière de l'ensemble de Mandelbrot. C'est une distance fractale.

> C'est très classique, on se servait de la même technique dans des logiciels de simulation de vol pour représenter un sol avec du relief. A partir d'un tableau 2D, chaque valeur correspondait à une altitude et une couleur (souvent blanc en haut: la neige, puis des dégradés de marron et vert pour la végétation et du bleu océan pour un niveau zéro.

Oui, il s'agit d'un "height-field" rendu avec des "vertices".
Mais ça n'est pas du tout ce que j'ai fait. Sinon, il n'y aurait
pas de relief à l'intérieur de l'ensemble de Mandelbrot (en noir).

> Dommage que Eurêka ne se lance pas sur ma V4, j'aurai pu comparer.
>
> Guillaume.

Eurêka ne fonctionne pas avec myAES, c'est le principal problème.
Mais en fait c'est parce que Olivier Landemarre s'est arrangé pour
développer myAES de façon à ce qu'il exclue Eurêka 2.12. Puis la V4
est un Amiga et non pas un ATARI. Ça ne me choque pas. Tu sais,
Vincent Rivière m'a envoyé une vidéo de Eurêka 2.12 sur Apple Lisa !

Il y a des problèmes avec le calcul en nombres flottants, sur V4.
Puis avec Eurêka 2.12 je teste des "cookies" qui ne doivent pas
être existants sur ta machine V4 ... Enfin, la V4 n'est pas compatible.

Eurêka 2.12 ne doit pas être l'unique exemple de non-fonctionnement.
La V4 ne doit pas lancer grand chose. Elle n'a pas sa place sur f.c.s.a.

Ici, on parle de machines ATARI =)

[Arachide]

Le vendredi 28 octobre 2022 à 08:38:44 UTC+2, Francois LE COAT a écrit :

> En fait si, parce que la profondeur est une valeur flottante, et non pas
> simplement un entier (la valeur pour l'index de couleur). J'ai implanté
> l'algorithme d"approximation des distances" qui est un algorithme 3D. Il
> s'agit pour la profondeur, de calculer la distance par rapport à la
> frontière de l'ensemble de Mandelbrot. C'est une distance fractale.

Il faudra que je regarde ça.

> Eurêka ne fonctionne pas avec myAES, c'est le principal problème.

J'utilise la V4 avec juste EmuTOS et sans FVDI, elle se lance en 16 couleurs. Mon choix est dicté par l'utilisation en tant que système de développement. Les bugs qui apparaissent inévitablement quand on code sont plus facilement récupérables sur un système simple et engendrent plus de blocages sous Mint et MyAES.
Ensuite, je fais des tests sous MyAES pour vérifier la compatibilité lorsque mon logiciel est assez propre.

Donc l'incompatibilité ne vient pas de là.

> Il y a des problèmes avec le calcul en nombres flottants, sur V4.

Juste la précision qui est à revoir.

> Puis avec Eurêka 2.12 je teste des "cookies" qui ne doivent pas
> être existants sur ta machine V4 ... Enfin, la V4 n'est pas compatible.

Tous les cookies standards y sont. M_PLAYER et le FORTH également en testent pas mal et ça marche.
Quels cookies testes-tu?

> Eurêka 2.12 ne doit pas être l'unique exemple de non-fonctionnement.
> La V4 ne doit pas lancer grand chose. Elle n'a pas sa place sur f.c.s.a.
>
> Ici, on parle de machines ATARI =)

La V4 fait parfaitement tourner le système EmuTOS (comme Aranym) et de nombreux logiciels y tournent:
FORTH
M_PLAYER
MP_STE
EVEREST
VISION
GEMVIEW
ASSEMBLE
PureDebugger
HEXEDIT
KOBOLD
MyAES
MINT
INTERFACE
FRACTALE
HYPVIEW
Pour ceux que j'utilise !

Guillaume.

[Francois LE COAT]

Salut,

Arachide écrit :
> Quels cookies testes-tu?

"LDGM"
"MgMc"
"PSND"
"GSXB"
"MgSn"
"McSn"
"EdDI"
"_MCH"
"USRS"
"SWAP"
"VMEM"
"VRAM"
"_T2W"
"MgPC"
"NOVA"
"fVDI"
"_VDO"
"_CPU"

Je ne suis pas sûr qu'ils soient tous sur la V4 ...

> La V4 fait parfaitement tourner le système EmuTOS (comme Aranym) et de nombreux logiciels y tournent:
>
> FORTH
> M_PLAYER
> MP_STE

Ceux là, tu as dû les adapter.

> EVEREST
> VISION
> GEMVIEW
> ASSEMBLE
> PureDebugger
> HEXEDIT
> KOBOLD
> MyAES
> MINT
> INTERFACE
> FRACTALE

Tu devrais pouvoir faire un zoom 2D sur l'ensemble de Mandelbrot, alors.

> HYPVIEW
> Pour ceux que j'utilise !
>
> Guillaume.

C'est quand même étrange que Eurêka 2.12 ne fonctionne pas. Il y a une
version compilée avec PURE C 1.1, qui marche dans tous les cas ...

<http://eureka.atari.org/eurklite.zip>

Vu les problèmes avec le calcul flottant, c'est sans doute cette version
qu'il faut tester d'abord. Elle est conçue pour le 68000 de base ...

[OL]

Bon François

Quel affabulateur tu fais, pour ne pas dire plus, mes réponses à tes
fantasmes plus bas.

> Salut,
>
> Arachide écrit :
>> Francois LE COAT écrit :
>>> Fort de cette expérience, j'ai réalisé la même chose sur ATARI, avec
>>> le logiciel Persistence Of Vision, et en trois dimensions ...
>>>
>>> <https://www.youtube.com/watch?v=Yf7q2KdAS-4> *POV-Ray*
>>
>> En fait tu pars d'un calcul en 2D et chaque valeur de pixel est convertie en une
>> profondeur et une couleur. Donc ce n'est pas réellement une fractale 3D.
>
> En fait si, parce que la profondeur est une valeur flottante, et non pas
> simplement un entier (la valeur pour l'index de couleur). J'ai implanté
> l'algorithme d"approximation des distances" qui est un algorithme 3D. Il
> s'agit pour la profondeur, de calculer la distance par rapport à la
> frontière de l'ensemble de Mandelbrot. C'est une distance fractale.
>
>> C'est très classique, on se servait de la même technique dans des logiciels de
>> simulation de vol pour représenter un sol avec du relief. A partir d'un tableau
>> 2D, chaque valeur correspondait à une altitude et une couleur (souvent blanc en
>> haut: la neige, puis des dégradés de marron et vert pour la végétation et du
>> bleu océan pour un niveau zéro.
>
> Oui, il s'agit d'un "height-field" rendu avec des "vertices".
> Mais ça n'est pas du tout ce que j'ai fait. Sinon, il n'y aurait
> pas de relief à l'intérieur de l'ensemble de Mandelbrot (en noir).
>
>> Dommage que Eurêka ne se lance pas sur ma V4, j'aurai pu comparer.
>>
>> Guillaume.
>
> Eurêka ne fonctionne pas avec myAES, c'est le principal problème.

Déjà où il est écrit que Guillaume le teste sous MyAES ? Il ne le dit
pas, la V4 ce n'est pas seulement MyAES, c'est Emutos avec ou sans Mint +
soit MyAES, soit XaAES soit NAES soit Atari AES 4.0, accessoirement c'est
aussi Atari AES 4.1 sur Emutos et aussi Geneva même si là il y a un
petit soucis.

> Mais en fait c'est parce que Olivier Landemarre s'est arrangé pour
> développer myAES de façon à ce qu'il exclue Eurêka 2.12.

Pure Affabulation, Eureka fonctionne parfaitement sous MyAES le cocasse de
la chose c'est même sous cet AES qu'il fonctionne le mieux, faut dire que
je me suis fais un plaisir de le faire fonctionner. Maintenant je pourrais
ne pas le faire fonctionner si je voulais, mais si je le faisais bien sur
il ne planterait pas, il y aurait par contre un beau message du style
"étant soumis à la diffamation de cet auteur de manière régulière
depuis des années je ne tiens pas que ce logiciel puisse fonctionner avec
mon AES!" Mais je ne l'ai pas fait et pour une simple raison, je n'en vois
pas l'intérêt et pire je perdrais le petit plaisir de faire mieux que
les autres AES sur ce soft qui tu as écrit! Tu ne veux tout de même pas
me priver de cette petite satisfaction, notes tu pourrais aussi décider
de ne pas fonctionner sur MyAES si tu en avais envi.

Bon revenons à la V4, je l'ai déjà dit Eureka fonctionne sur la V4 sans
soucis, je viens de refaire le teste, mais cela était déjà vrai depuis
que j'ai réussi à faire une configuration pour la V4. Sous Emutos cela
pose problème je ne sais pas pourquoi.

>Puis la V4
> est un Amiga et non pas un ATARI. Ça ne me choque pas. Tu sais,
> Vincent Rivière m'a envoyé une vidéo de Eurêka 2.12 sur Apple Lisa !
>
> Il y a des problèmes avec le calcul en nombres flottants, sur V4.

Ah bon tu en as une ? Non tu reprends ce que dit Guillaume, honnêtement
il n'y a aucun soucis d'affichage de Eureka sur la V4, arrêtes de
fantasmer. Il y a peut être des soucis mais ce que j'en vois non, comme
sur le modeleur Inshape 3, je ne vois pas de soucis.

> Puis avec Eurêka 2.12 je teste des "cookies" qui ne doivent pas
> être existants sur ta machine V4 ... Enfin, la V4 n'est pas compatible.

Ah bon ? Affirmation gratuite tu ne l'as pas testé et puis compatible
cela veut dire quoi ?
Le Falcon n'était pas 100% compatible avec le ST si on va dans ce sens on
n'aurait pas du parler du Falcon, ridicule

>
> Eurêka 2.12 ne doit pas être l'unique exemple de non-fonctionnement.
> La V4 ne doit pas lancer grand chose. Elle n'a pas sa place sur f.c.s.a.

Ah bon ? Quelle plaisanterie, alors il ne faut pas parler de l'Hades non
plus parce que niveau compatibilité la V4 est déjà largement un cran au
dessus de l'Hades du point de vu compatibilité et sur bien des points
plus compatible que Aranym avec fVDI, mais il n'y a pas de règles, j'ai
des softs qui refusent de fonctionner sur la V4 et qui fonctionnent sur
Aranym et inversement comme par exemple Kandinsky plante sur V4 et marche
sur Aranym, mais Papyrus marche sur V4 et plante quand tu arrives en fin
de page sur Aranym + fVDI.

Quand je pense qu'hier tu as oser comparer le résultat d'un processeur
Rizen 9, 12 cores à 3.7Ghz dont le CPU consomme 170W à une machine à
85Mhz simple core qui consomme en tout moins de 2W, mais de qui tu te fout
tu?

>
> Ici, on parle de machines ATARI =)

Ah bah toi tu parles de tout sauf de machines Atari compatible, cela on
l'a compris.

[OL]

Le 27/10/2022 à 22:42, GOOD OLD TOS a écrit :

Je ne sais pas trop faire, la première image prend bien plus de temps que
sur cette démo cela prend environ 4 secondes à s'afficher, ceci dit on
est en 16 couleurs ST je pense que cela n'aide pas.

Je sais que d'autres programmeurs ont fait de l'optimisation aussi, je
pense qu'il y a mieux.

Olivier

[GOOD OLD TOS]

Hello,
effectivement la conversion des orbites en image sur 4 pans joue pas mal, surtout que cette partie n'est pas trop optimisée dans Fractals.
Possible aussi que les calculs en flottants soient pus performants que le codage en entiers 32 bits de la zone réelle.
Encourageant en tout cas.
Merci,
Jean

[OL]

Il y a pas mal de raison possible de la vitesse, déjà ce qu'ils font
c'est en assembleur pour une simple raison aucun autre langage permet
d'optimiser pour ce processeur donc ils le font à la main. La première
chose c'est qu'il est capable de faire jusqu'à 4 instructions en même
temps a condition de bien choisir enchaînement des instructions ensuite
il y a des fonctions type DSP pour faire du calcul à la chaîne je pense
qu'ils doivent utiliser, cela permet d'aller franchement plus vite.

[Arachide]

Le dimanche 30 octobre 2022 à 00:21:47 UTC+2, ol myaes a écrit :

> Il y a pas mal de raison possible de la vitesse, déjà ce qu'ils font
> c'est en assembleur pour une simple raison aucun autre langage permet
> d'optimiser pour ce processeur donc ils le font à la main. La première
> chose c'est qu'il est capable de faire jusqu'à 4 instructions en même
> temps a condition de bien choisir enchaînement des instructions ensuite
> il y a des fonctions type DSP pour faire du calcul à la chaîne je pense
> qu'ils doivent utiliser, cela permet d'aller franchement plus vite.

J'ai regardé le source, c'est du pur 68030+68882. Pas d'instructions spéciales (d'ailleurs PureDebugger l'affiche correctement).
Mais impossible de le faire tourner sous EmuTOS (j'ai rajouté les instructions GEMDOS de début et fin). Il y a bien un changement de résolution, le fond noir devient fond bleu peu à peu mais aucune fractale n'apparaît. Etrange...

Sinon, je pense que la vidéo exagère la vitesse, elle doit être en accéléré. (car le temps de remplissage en bleu foncé est bien long pour la 1ere image)
Je vais demander.

Guillaume.

[Arachide]

Ou alors c'est que ASSEMBLE gère mal les constantes réelles et les encode mal (on serait alors tout le temps dans la zone centrale de la fractale, celle qui ne converge pas, d'ou cette lenteur).

A vérifier...

Guillaume.

[GOOD OLD TOS]

Hello,

y'a le code source quelque part (autre que l'extrait sur la video)?
Je ne vois pas où le point est "ploté" dans la video.

[Arachide]

Ici :
http://www.apollo-core.com/index.htm?page=coding&tl=3

Le programme définit la zone "foto" comme étant l'écran. Et il plotte dans la zone foto (avec (a0)+) dont le début est rangé dans BildPtr après un joli arrondi à 8.

Guillaume.

[Arachide]

Coucou,

Ça y est, je l'ai !!!!!!!
J'ai modifié le programme en entrant les constantes en hexadécimal pour éviter les conversions erronées float->hexa.
J'ai également viré les instructions musicales car je n'ai pas le fichier AIFF d'origine dont il se sert.

La vitesse est bien celle de la vidéo, c'est impressionnant.

Voici le lien pour télécharger le source et l'exécutable V4:

https://gtello.pagesperso-orange.fr/temp/FRACTAL.zip

Guillaume.

[GOOD OLD TOS]

Bien joué!
Le mode video doit etre du chunky alors pour pouvoir faire un truc comme ça. Malheureusement en bitplanes :-(
Je pense que c'est rapide parce que les instructions en flottant sont bien plus performantes que sur un 68882.
Est-ce que tu pourrais vérifier sur le V4 avec Fractals (le mien !) en demandant un calcul sur des flottants?
Ce devrait être même plus rapide car je ne calcule pas forcément tous les points.

A+,
Jean

[Arachide]

Le dimanche 30 octobre 2022 à 09:58:08 UTC+1, GOOD OLD TOS a écrit :

> Bien joué!
> Le mode video doit etre du chunky alors pour pouvoir faire un truc comme ça. Malheureusement en bitplanes :-(
> Je pense que c'est rapide parce que les instructions en flottant sont bien plus performantes que sur un 68882.
> Est-ce que tu pourrais vérifier sur le V4 avec Fractals (le mien !) en demandant un calcul sur des flottants?
> Ce devrait être même plus rapide car je ne calcule pas forcément tous les points.
>
> A+,
> Jean

Exact, du chunky. Bien pratique.
Il serait possible d'en faire une version 16 bits pour le Falcon ou carte NOVA.
On remplacerait le:
move.b d2,(a0)+
Par un:
move.w 0(a1,d2*2),(a0)+
Où a1 pointerait sur la palette transformée en 16 bits.
Ça ferait un peu plus d'accès mémoire, donc moins performant, mais déjà utilisable.

Ça va être difficile d'estimer la vitesse avec le tien : je peux faire la même animation? Ou juste sur une image?

Guillaume.

[GOOD OLD TOS]

Hello,
l'animation avec Fractals n'est pas temps réel, tu définis juste une image de départ et d'arrivée et Fractals calcule les n images intermédiaires.
Mais un simple calcul de l'ensemble de Mandelbrot avec le FPU devrait suffire pour se faire une idée.
En 16 couleurs car je crois que le mode 256c n'est pas supporté à ce jour?
Un truc sympa aussi serait de s'amuser avec la prévisualisation avec l'ensemble initialisateur (fenetre en bas à droite).
Je ne pense pas que sur Falcon ce code soit plus rapide que le mien; il l'est sur la V4 car (à mon avis mais à vérifier) le FPU est bien plus performant que sur un 68882 et même que "l'émulation" 68030 lors du calcul sur des entiers.

A+,
Jean

[OL]

Puré cela va vite!

[Arachide]

Le 30/10/2022 à 12:46, OL a écrit :

>
> Puré cela va vite!

Oui c'est assez bluffant!
En travaillant sur deux écrans et en swappant, on n'aurait pas l'effet
"moche" du redessin et ça serait plus fluide à l'oeil.
A voir....

Guillaume.

[OL]

La vidéo du programme Fractal adapté par Guillaume lancé depuis Atari
sur la V4

http://v4sa-atari.lutece.net/video/fractal_V4.mp4