Eval vitesse d'un programme sur differents amigas

15 sujets de 31 à 45 (sur un total de 101)

huggyone76
5 mars 2018 à 18h17 #305896
A600 – Vampire « V2 » premier modèle.

@_sam_, sur le dernier Monkey :

* gcc 2.95.3 – 19.247 fps

* gcc 3.2.2 – 14.144 fps

* vbcc – 17.119 fps

* sasc – 11.460 fps

* gcc 6.3.1b – 21.706 fps

* gcc 6.4.1b – 20.861 fps

* sascc – 7.795 fps

@thellier, sur la vache :

J’ai une fenêtre qui s’ouvre et qui reste vide… ou un « défaillance du logiciel ». Bref, ça ne fonctionne pas sur ma machine, désolé.

A500+ACA500 - A600+Vampire 2+indivision ECS - A1200+Vampire V2 1200 - Mac Mini 1.42 sous MOS - Just CPC 128k - CPC 6128 - Atari STE 4Mo/CosmosEx - Atari Falcon CT60/SuperVidel 🙂
C64C + 1541-II + Lecteur K7 + SD - Sharp X68000 CZ-601C 4Mo + CF - Sharp X68000 CZ-611C 10Mo + CF + ext. MIDI
__sam__
5 mars 2018 à 18h46 #305906
Hum, vbcc et ses 17 fps est pas si mauvais que ca. SAS/C fait moitié moins vite que le meilleur des compilos. Du coup les 21.7 de gcc6 doivent paraitre vraiment très fluides à l’écran 🙂

Merci pour les tests.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
huggyone76
5 mars 2018 à 20h07 #305915
Je confirme, très fluide. 🙂

Par contre, comme GoodChip j’ai une barre grise assez importante sur la droite… et mon écran est un Dell 4:3. Mais peu importe, je ne pense pas que ça change grand-chose au test 😉

A500+ACA500 - A600+Vampire 2+indivision ECS - A1200+Vampire V2 1200 - Mac Mini 1.42 sous MOS - Just CPC 128k - CPC 6128 - Atari STE 4Mo/CosmosEx - Atari Falcon CT60/SuperVidel 🙂
C64C + 1541-II + Lecteur K7 + SD - Sharp X68000 CZ-601C 4Mo + CF - Sharp X68000 CZ-611C 10Mo + CF + ext. MIDI
thellier
5 mars 2018 à 20h29 #305922
@Samuel
J’en sais rien je suis sur WinUAE
J’ai généré l’ASM depuis GCC puis j’ai modifié le source C jusqu’à obtenir le moins d’instructions par pixels selon l’usage des structures,pointeurs,registres… c’est d’ailleurs très instructif

On pourrait tailler dans l’ASM pour enlever qques copies d’un registre à l’autre mais il vaudra mieux passer à l’AMMX direct
Puisque c’est le blend et le modulate qui demandent le plus d’instructions et que le PMULA de l’AMMX vont en dégager la plupart
Ceci libérera aussi des registres dans un cercle vertueux…

PMULA equivalent C Code:
int i;
unsigned char a[8];
unsigned char b[8];
unsigned char d[8];

for( i = 0 ; i<8 ; i++ )
{
d = ( ( a * b ) >> 8 ) + d;
}

@huggyone76
>J’ai une fenêtre qui s’ouvre et qui reste vide
Je suis sur un WB 32 bits RTG dans WinUAE

Au final c’est juste pour voir si on peut envisager un Wazp3D pour la Vampire…
__sam__
5 mars 2018 à 20h49 #305926
@huguyone: cette barre m’intrigue vu que tu es en 4:3. Peux-tu utiliser l’option -win <largeur> <hauteur> pour voir si ca amméliore les choses ?

@Alain: Wazp3D sur la vamp, oui c’est possible. Ca me semble clair. Rien que mon code tout pourri en C tourne à 20fps avec le Suzanne de blender (sensiblement une moitié de vache) sans utiliser les deux pipes ou le superscalaire. Bon par contre, il faut se palucher l’asm, et sur les grosses routines, ca devient assez vite casse gueule.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
thellier
6 mars 2018 à 9h59 #305948
Alors personne n’arrive à faire marcher la vache sur Vampire ?
goodchip
6 mars 2018 à 12h21 #305965
@thellier: j’essaie dans la journée 😉

Sylvain aka goodchip
Jul
6 mars 2018 à 15h08 #305980
Si. J’ose.

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
__sam__
7 mars 2018 à 0h09 #306016
Petite mise à jour: j’ai modifié la routine principale pour qu’elle utilise des entiers au lieu de floats. Les 68k « classiques » (040 et 060) devraient mieux s’en sortir (je suis à 10fps avec uae sans aucun jit), au prix de quelques erreurs de calculs se traduisant par des pixels erratiques.

Téléchargement >>ici<< ou >>là<<.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
goodchip
7 mars 2018 à 11h08 #306045
SuperScalar = ON

gcc.2.95.3 : 15.401 >> 16.191 (à nouveau, bordure grise sur la droite)

gcc-3.4.6 : plante >> plus présent dans la nouvelle archive

gcc-3.2.2 : 16.487 >> 15.487 (à nouveau, bordure grise sur la droite)

gcc-6.3.1b : 10.169 >> 17.502 (A PRESENT, bordure grise sur la droite)

gcc-6.4.1b : 10.210 >> 17.519 (A PRESENT, bordure grise sur la droite)

sasc : 13.583 >> 13.754 (à nouveau, bordure grise sur la droite)

sascc : 7.688 >> plus présent dans la nouvelle archive

vbcc : 17.804 >> 16.322 (à nouveau, bordure grise sur la droite)

(le 1er chiffre est celui de la précédente archive pour comparaison).

Je pense qu’il y a un lien de cause à effet entre cette bordure et le nombre de FPS, voir les nouveaux résultats de GCC 6.

Ci-dessous, le snapshot de la barre grise présente sur mon écran :
Attachments:

IMG_1660.jpg
Sylvain aka goodchip
goodchip
7 mars 2018 à 11h16 #306050
@thellier: voici le résultat pour le Cow3D, à peine 1 FPS, normal ?
Attachments:

IMG_1656-1.jpg
Sylvain aka goodchip
__sam__
7 mars 2018 à 11h29 #306054
Je n’ai pas la bordure grise dans UAE. On voit que la tête est centrée dans la zone noire. J’écris en mémoire video et ca ne dépasse pas la zone noire. La bande grise est apparue sur Vamp quand j’ai demandé à l’OS un écran RGB(24) et pas ARGB32. La largeur où je dessine est obtenu en demande le nb d’octets d’une ligne.

Je soupçonne un soucis entre le ARGB32 et le RGB24, style la ligne qui fait 320*4 octets en ARGB32 serait calculée à 320*3 en RGB24 par le driver picasso96 de la vamp. Sauf que même en RGB24 un pixel occupe 32octets (du moins dans le code.) Résutat: on a une zone inutilisée d’1/4 d’écran. Est-ce bien la largeur de la zone grise ? (il y a peut-être un lièvre caché dans cette zone grise.)

Sinon, c’est curieux goodchip, tes fps sont bien en dessous de ceux de huggyone. Par exemple avec gcc-6.4.1b tu avais 10fps, mais lui avoisinais 20fps (et tu es à 17fps à présent.) Flype m’a aussi retourné que le fps était un peu plus bas avec la version « en entier » du rasterizer. Comme il n’y a pas de retours sur 040 avec la nouvelle version, je ne serais pas affirmatif, mais j’espère que la version entière marche mieux sur 040 et 060. Sur vamp, probablement que passer en entier est moins performant que sur la fpu tant elle est performante.

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
goodchip
7 mars 2018 à 12h04 #306055
Mon sentiment est que mon souci de performance vient uniquement lorsque l’écran est ouvert en ARGB32 (souci que ne rencontre peut-être pas huggyone sur V600 et/ou sur une autre distribution que la R48).

Les différences (en plus ou en moins) entre la dernière version venant de l´utilisation des entiers.

Sylvain aka goodchip
thellier
7 mars 2018 à 15h27 #306070
Merci Goodchip

Oui c’est lent vu la taille de l’objet (5000 triangles) mais je suis un peu déçu j’aurai espéré qques fps
Bon faut voir que ce code converti en AMMX fera facilement 5 fois moins d’instructions donc il devrai aller au moins 5 fois plus vite. En plus il fera moins d’accès mémoire puisque il manipulera des données plus grosses en une seule passe
Enfin là j’écris dans un buffer RGBA puis je fais un WritePixelArray
Il vaudrait mieux écrire directement dans la bitmap ecran comme Samuel. C’est du ARGB sur Vampire en RTG ?

Alain
__sam__
7 mars 2018 à 16h52 #306075
Perso, au lieu de WritePixelArray, j’utilise aussi un bitmap hors-écran ami du bitmap écran (cf AllocBitMap) auquel je rattache un rastport créé de toute pièces, et pour l’affichage je fais un BlitBitmapRasport(ou dans le genre) avec le magic-number indiquant qu’on veut copie. Cela est intercepté par la couche cybergfx/picasso96 qui effectue alors la copie au plus vite entre les deux bitmaps amis (soit via le DMA de la carte gfx, soit via le 68k).

Oui le RTG de la vamp connait ARGB. Mais peut-être accepte-t-il aussi un écran BGRA. Il a l’air assez souple au niveau des modes gfx je crois (mais je ne suis pas certain.)

[EDIT] oui Gunnar vient de me confirmer sur IRC que BGRA est supporté, mais c’est pas le meilleur mode quand on code 68k (mauvais byte-order)

[EDIT2] Flype me dit que le driver picasso96 ne supporte pas les bytes order PC. Donc finalement c’est non 🙁

Samuel.

Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)