Re: Acorn archimedes 3010

[Tryphon]

J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur

[drfloyd]

J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur

également avec du basic.... meme si en dessous du C

[Tryphon]

J'ai été assez étonné des résultats qu'on peut obtenir sur MD avec du C pur

également avec du basic.... meme si en dessous du C

La Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.

Cependant,

* le langage ne permet certainement pas aisément certaines constructions du C (comme les pointeurs, en particulier les pointeurs sur fonctions) et du coup, même si c'est possible, les codeurs Basic les utilisent peu

* je pense probable que la bibliothèque SGDK de Stef soit mieux codée et efficace que les routines internes des Basics (pure spéculation)

[Invité]

La Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.

Une erreur un peu souvent lu , comme c'est compilé c'est aussi rapide que du C :p
Cela dépend du langage (même le java compilé reste plus lent que du C ou C++ compilé).

Mais surtout la grosse dif c'est que le C profite d'un certain compilateur (GCC) qui permet de faire de grosse optimisation que ferait un programmeur assembleur expérimenté

Alors que le basic c'est transcodé tel quel et donc "super long" (c'est un peu l'équivalent entre l'option -O0 et -O3 de GCC , la dif entre les deux sont énorme en terme d'optimisation).

Programmer en assembleur ne garantie pas que ton code sera rapide ,si tu ne fait pas les optimisations nécessaire (comme GCC) , ben l'asm peut être bien plus lent que du C pour un programmeur débutant/moyen face au C.
(enfin même expérimenté parce que le compilo C va dans des opti assez poussé).

[Tryphon]

La Basic de la MD étant COMPILÉ, il n'y a pas de raison qu'il soit fondamentalement plus lent que le C.

Une erreur un peu souvent lu , comme c'est compilé c'est aussi rapide que du C :p
Cela dépend du langage (même le java compilé reste plus lent que du C ou C++ compilé).

J'ai simplifié pour le doc : ce sont deux langages très proches (pas de construction haut-niveau : c'est pas du CaML ou du Python, ni même du java), compilés. Donc on peut très bien imaginer un compilateur Basic optimisant tout aussi bien que GCC (on pourrait par exemple faire une traduction Basic -> C quasiment immédiate). Et pourtant, je pense qu'on observerait des programmes C toujours plus rapides, principalement pour les raisons que j'ai évoquées, et pas pour l'optimisation fournie par GCC.

Par exemple, pour Shinobi, j'ai commencé mon développement avec une vieille version de SGDK qui utilise GCC 2, et je n'activais pas les options d'optimisation. Ça m'empêchait pas d'atteindre les 60fps, même en debug.

La principale optimisation à faire, c'est dans les algorithmes utilisés, et il est plus facile et naturel d'utiliser des algorithmes efficaces en C (parce que le fait de coder avec des pointeurs t'oblige à réfléchir aux manipulations de la mémoire ; le basic est plus transparent pour ça)

Programmer en assembleur ne garantie pas que ton code sera rapide ,si tu ne fait pas les optimisations nécessaire (comme GCC) , ben l'asm peut être bien plus lent que du C pour un programmeur débutant/moyen face au C.
(enfin même expérimenté parce que le compilo C va dans des opti assez poussé).

Oui, je suis d'accord avec ça. Tout comme il est parfois possible de faire du Python ou du Java plus rapide que du C. Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES )

[Invité]

La principale optimisation à faire, c'est dans les algorithmes utilisés

Je suis totalement d'accord avec ça  , c'est la premier optimisation à faire avant de se concentrer sur la génération du code produit :p

Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES )

Le comptage de cycles, je le fais partout même sur des consoles puissante comme le Dreamcast /PS2.
Quand tu veux faire de la transformation de perspective en temps réel , un gain de 5 cycles peut te donner des milliers de triangles supplémentaires  

[Tryphon]

Je ne savais même pas qu'il y avait eu des consoles après la SNES

[ArchieForEver]

La principale optimisation à faire, c'est dans les algorithmes utilisés

Je suis totalement d'accord avec ça  , c'est la premier optimisation à faire avant de se concentrer sur la génération du code produit :p

Mais c'est plus une question d'algorithme que du comptage de cycles (ça c'est bon pour la SNES )

Le comptage de cycles, je le fais partout même sur des consoles puissante comme le Dreamcast /PS2.
Quand tu veux faire de la transformation de perspective en temps réel , un gain de 5 cycles peut te donner des milliers de triangles supplémentaires  

Tout comme sur Archimedes quand tu veux afficher un sprite : quelques cycles gagnés par série horizontale de pixels composant ton sprite, au final tu peux afficher entre 4 et 8 fois voire bien + de sprites à l'écran.
Pas grand'chose * bcp ça finit par faire.

[Invité]

C'est le cas de toute les machines où tu vas coder quand tu as beaucoup d'élément a gérer quelque cycles est important.

Mais l'archimede aura une optimisation plus facile , vu que tout fait 1 cycle , sauf les accès mémoire (qui doivent faire sûrement entre 2-3 cycles).

Il n'y a pas comme le 6502 ou le M68000 où tu vas devoir privilégier certaine instructions (parce qu'elles ont un taux de cycle bas) , ou sur des consoles PS1/Saturn et les suivantes où l'ordre des instructions détermine la vitesse des instruction ce qui cause que rajouter quelque instruction sur ton code t'oblige à le réécrire de zero quelque fois

Mon conseil pour optimiser (et savoir si on peut aller plus loin ) c'est de connaître le max théorique.
On peut calculer le max théorique du taux de fillrate de l'archimede , sachant qu'il est de 4MIPS (pour le 8 MHz) , tu as du coup un fillrate de 8 Mpixels/s (chaque instruction peut écrire sur 2 octets vu que c'est la taille du bus de données) mais dans les fait t'aura forcément moins si on compte les load/store + calcul , techniquement je le verrai à 3-4 Mpixels/s
Je parle ici pour 256 couleurs ,c'est le double pour du 16 couleurs.

L'Amiga est de 4 Mpixels/s et la MD/SNES de 13 Mpixels/s par seconde

[Tryphon]

Je ne comprends pas cette histoire de fillrate : à quoi correspondent ces nombres et en quoi sont-ils pertinents ?

[Invité]

On va prendre la MD comme exemple alors
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).

Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).

La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).

[ArchieForEver]

C'est le cas de toute les machines où tu vas coder quand tu as beaucoup d'élément a gérer quelque cycles est important.

Mais l'archimede aura une optimisation plus facile , vu que tout fait 1 cycle , sauf les accès mémoire (qui doivent faire sûrement entre 2-3 cycles).

Il n'y a pas comme le 6502 ou le M68000 où tu vas devoir privilégier certaine instructions (parce qu'elles ont un taux de cycle bas) , ou sur des consoles PS1/Saturn et les suivantes où l'ordre des instructions détermine la vitesse des instruction ce qui cause que rajouter quelque instruction sur ton code t'oblige à le réécrire de zero quelque fois

Mon conseil pour optimiser (et savoir si on peut aller plus loin ) c'est de connaître le max théorique.
On peut calculer le max théorique du taux de fillrate de l'archimede , sachant qu'il est de 4MIPS (pour le 8 MHz) , tu as du coup un fillrate de 8 Mpixels/s (chaque instruction peut écrire sur 2 octets vu que c'est la taille du bus de données) mais dans les fait t'aura forcément moins si on compte les load/store + calcul , techniquement je le verrai à 3-4 Mpixels/s
Je parle ici pour 256 couleurs ,c'est le double pour du 16 couleurs.

L'Amiga est de 4 Mpixels/s et la MD/SNES de 13 Mpixels/s par seconde

Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
Et ...
... comme tu as 16 registres ( R0 à R15 )
... que R15 c'est le PC, donc il t'en reste 15 utilisables pour tes routines de sprites
... qu'il te faut 1 registre pointant sur tes pixels, et 1 registre pointant là où tu voudras écrire ton sprite
... ça te laisse 13 registres, de 32 bits
... en mode 256 couleurs ou 1 pixel est représenté sur 8 bits, tu peux donc utiliser 13 registres contenant chacun 4 octets, ça fait donc 52 pixels, qui vont te prendre
4 cycles pour ton 1er registre puis
12 x 1 cycle pour les 12 autres, donc 12 cycles
soit au total 16 cycles pour mettre dans les registres 52 pixels
et autant quand tu vas stocker le contenu de tes registres en mémoire
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}
Le '!' fait automatiquement l'incrémentation de l'adresse, et ça coûte 0 cycle
Ceux qui connaissent me diront 'Mais tu utilises R13 habituellement retenu pour être pointeur de pile, et R14 qui contient ton adresse de retour de sous-routine'
ce à quoi je répondrai que sauvegarder R13 et R14 avant ce n'est pas fait pour les chiens.
Tu les recharges à la fin du tracé de ton sprite.

Ca c'est vrai quand tu vas écrire des paquets de 4 octets sur des adresses multiples de 4 (typiquement les bandes de parallax dans SOTB, une image de fond, en décor pour un jeu où une démo).
Ca devient moins bon quand c'est un sprite, puisque ses segments horizontaux de pixels ne vont :
1/ Pas être de tailles multiples de 4
1/ Pas être naturellement toujours écrits en mémoire sur des adresses multiples de 4 ( les instructions de transferts rapides travaillent sur adresse source ou destination multiples de 4 )
et c'est là où des routines optimisées vont faire toute la différence :
- pas de masque, pas de chargement du 'fond', pas de trouage, de ORR etc ... c'est lamentablement lent
- usage de sprites compilés qui évite ci-dessus et vont quand nécessaire ( 3 fois sur 4 on va dire ) charger ce qui est immédiatement à gauche et à droite du sprite pour compléter les bords gauche et droit du sprite à concurrence de 4 pixels 'remplissant 'entièrement des adresses multiples de 4, et ainsi maximiser les écritures multiples par paquet de 4 pixels, sur adresses multiples de 4
Le rapport de vitesse entre la méthode crasse et le sprite compilé c'est minimum 1 à 4
La méthode la + crasse (enfin presque, on peut encore faire pire, genre manipulation pixel par pixel) c'est celle de Pacmania qui shifte les tiles de fond à la volée.
Et malgré tout ça le jeu reste en 50 fps, tellement l'Archie est puissant.
J'imagine qu'il shifte aussi les sprites, leurs masques, charge le fond, troue le fond avec le masque, ORR le sprite avec le fond troué, et balance le résultat à l'écran.
Ca donne envie de vomir rien que d'y penser, quel gâchis.


Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'

[ArchieForEver]

On va prendre la MD comme exemple alors
Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).

Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).

La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).

En mode 16 couleurs et en 320x224 je pense que l'Archie écrit 3 fois l'écran par VBL, ou alors pas loin, vraiment, vraiment, pas loin.
Je répète à nouveau que dans les idées fondamentales de la conception de l'ARM et de son contrôleur mémoire, le MEMC, il y avait le fait de maximiser l'usage de la bande passante des mémoires DRAM de l'époque.
Regarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.
Certes, mode graphique 50 Hz, pas 60 Hz comme la MD. ( Superbe bécane, rien à voir avec les copros tout limités de l'Amiga. Oui, oui j'ai bien eu un Amiga et quand j'ai eu la MD j'ai quasi arrêté de jouer sur Amiga, aucun intérêt face à ce qui se faisait sur MD, vu que c'était les shoot em up qui me plaisaient. L'Amiga m'a servi à regarder des démos, et écouter des MODs, jusqu'à ce que j'ai un PC avec une Gravis, où je suis passé aux S3M et l'Amiga 500 m'a définitivement fait totale pitié, ayant de surcroît expérimenté la programmation sur Archie, et compris à quel point cette machine était sous exploitée en 2D. Le 1200 je le trouve assez cool, lui ).

[Invité]

Je vais pas répondre point par point
Mais merci je connais sûrement l'ARM2 mieux que toi mais effectivement pour :

Regarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.

La vitesse du CPU est secondaire sur l'affichage des sprite (même si elle est non nélgigable) , c'est surtout la bande passante qu'il faut regarder

Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.

Cela doit être alors une version modifié de l'ARM2 , parce que l'ARM2 fait tout sur un cycle (même les accès RAM) , le seul truc qui fait les accès RAM sont plus "lente" et un conflit de bus entre les data de données et des instructions , du coup l'ARM2 bloque les instructions le temps de lire les données.
ce qui fait que cela fait plus de 1 cycles (normalement 2) , mais apparemment cela fait plus sur l'Archie (sauf si on parle du 32 bits)

Et du coup cela baisse le fillrate  

Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}

Justement si tu fait un load /store ,t'es pas à 1,6 pixel cycle  
un load/store fait 4 cycle chaqu'un  tu dis ? donc on a 8 cycles au total
Sur 256 couleurs , 1 pixel = 1 octet donc là tu écrit sur 4 octet à l'écran , donc on est plus sur du 4 pixel/8 cycles  
Ou 8 pixel/8 cycles sur 16 couleurs.

Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'

Je ne dis pas le contraire , je dis que elle aura comme toute machine des limites , mais si tu la compare à une MD ou une SNES, elle sera loin de celle ci.
Pour te dire que ces MIPS ne veulent rien dire quand on parle de rendu, compare là à la NG , c'est plus flagrant
La Neo Geo c'est du 2 MIPS , mais t'arrivera jamais afficher 1536 pixel/ligne avec le CPU seul

[ArchieForEver]

Je vais pas répondre point par point
Mais merci je connais sûrement l'ARM2 mieux que toi mais effectivement pour :

Regarde ma démo des bouboules c'est du 320 x 256 16 couleurs.
Par VBL :
- je recopie tout l'écran pour le fond ( donc 320 x 256 pixels )
- j'affiche 80 bouboules 32x32 (en ayant à lire le décor pour le faire, comme expliqué + haut ) et ça couvre tout l'écran 320 x 256
et il me reste encore plein de cycles, alors que je joue un MOD ce qui prend 10% à 12,5% du temps CPU dispo par VBL.
Et là on parle bien d'une machine à 8 Mhz, 4,5 MIPS.

La vitesse du CPU est secondaire sur l'affichage des sprite (même si elle est non nélgigable) , c'est surtout la bande passante qu'il faut regarder

Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.

Cela doit être alors une version modifié de l'ARM2 , parce que l'ARM2 fait tout sur un cycle (même les accès RAM) , le seul truc qui fait les accès RAM sont plus "lente" et un conflit de bus entre les data de données et des instructions , du coup l'ARM2 bloque les instructions le temps de lire les données.
ce qui fait que cela fait plus de 1 cycles (normalement 2) , mais apparemment cela fait plus sur l'Archie (sauf si on parle du 32 bits)

Et du coup cela baisse le fillrate  

Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}

Justement si tu fait un load /store ,t'es pas à 1,6 pixel cycle  
un load/store fait 4 cycle chaqu'un  tu dis ? donc on a 8 cycles au total
Sur 256 couleurs , 1 pixel = 1 octet donc là tu écrit sur 4 octet à l'écran , donc on est plus sur du 4 pixel/8 cycles  
Ou 8 pixel/8 cycles sur 16 couleurs.

Ca fera 10 € pour le cours et vous me copierez 1000 fois 'L'Archimedes est une bécane de ouf au potentiel inutilisé en 2D'

Je ne dis pas le contraire , je dis que elle aura comme toute machine des limites , mais si tu la compare à une MD ou une SNES, elle sera loin de celle ci.
Pour te dire que ces MIPS ne veulent rien dire quand on parle de rendu, compare là à la NG , c'est plus flagrant
La Neo Geo c'est du 2 MIPS , mais t'arrivera jamais afficher 1536 pixel/ligne avec le CPU seul

non, ce que j'ai dit est parfaitement exact, et tu peux vérifier dans la doc de VLSI qui est en ligne.
Je le reposte ici :
Et non, sur Archie les accès mémoire par paquets, c'est 4 cycles pour le 1er registre, et seulement 1 (oui : UN) cycle pour chaque registre supplémentaire.
Et ...
... comme tu as 16 registres ( R0 à R15 )
... que R15 c'est le PC, donc il t'en reste 15 utilisables pour tes routines de sprites
... qu'il te faut 1 registre pointant sur tes pixels, et 1 registre pointant là où tu voudras écrire ton sprite
... ça te laisse 13 registres, de 32 bits
... en mode 256 couleurs ou 1 pixel est représenté sur 8 bits, tu peux donc utiliser 13 registres contenant chacun 4 octets, ça fait donc 52 pixels, qui vont te prendre
4 cycles pour ton 1er registre puis
12 x 1 cycle pour les 12 autres, donc 12 cycles
soit au total 16 cycles pour mettre dans les registres 52 pixels
et autant quand tu vas stocker le contenu de tes registres en mémoire
Au final ça fait 16 x 2 = 32 cycles pour lire et afficher 52 pixels à l'écran, soit une moyenne de 1,6 cycle par pixel
Typiquement
si R0 contient l'adresse source des pixels
si R14 contient l'adresse mémoire destination
tu fais ton chargement puis ton écriture avec
LDMIA R0!,{R1-R13}
STMIA R14!,[R1-R13}
Le '!' fait automatiquement l'incrémentation de l'adresse, et ça coûte 0 cycle
Ceux qui connaissent me diront 'Mais tu utilises R13 habituellement retenu pour être pointeur de pile, et R14 qui contient ton adresse de retour de sous-routine'
ce à quoi je répondrai que sauvegarder R13 et R14 avant ce n'est pas fait pour les chiens.
Tu les recharges à la fin du tracé de ton sprite.

Je vais rajouter des smileys, ça fera cool :

[Invité]

Inutile de me copier ton pavé a chaque fois ,je sais que l'ARM2 à 16 registres merci  
Et encore heureux qu'il a 16 registres ,c'est le minimun syndical pour les processeurs RISC (qui ne peuvent pas fonctionné avec peu de registre comme le z80,le x86 ou le 65xx).
D’ailleurs les ARM suivant sont passé à 32 registres

Mais tu explique très mal , je te le dis au cas où
Mais je comprend où tu veux en venir donc oui tu peux te rapprocher des chiffres théorique de la bande passante grâce aux instructions de LDMIA/STMIA.
L'explication brouillon du reste n'était pas nécessaire

[ArchieForEver]

Inutile de me copier ton pavé a chaque fois ,je sais que l'ARM2 à 16 registres merci ,  
Et encore heureux qu'il a 16 registres ,c'est le minimun syndical pour les processeurs RISC (qui ne peuvent pas fonctionne avec peu de registre comme le z80,le x86 ou le 65xx).
D’ailleurs les ARM suivant sont passé à 32 registres

Mais tu explique très mal , je te le dis au cas où
Mais je comprend où tu veux en venir donc oui tu peux te rapprocher des chiffres théorique de 8/16 Mpixel/s du coup grâce aux instruction de LDMIA/STMIA.

Ah bon j'explique mal ?
Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.
Aucun.
Dommage.
Perdu.
Mets des pièces et essaie encore.

[Invité]

J'ai du relire la doc de l'ARM2 de larchie pour savoir où tu voulais en venir

Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.

C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.

Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.

Mais dire que  le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM

[drfloyd]

essayez de vous mettre d'accord en toute amitié si vous etes fans tous les deux de l'architecture ARM :)

[Tryphon]

On va prendre la MD comme exemple alors

C'est un excellent exemple

Mais le fillrate (remplissage) est important que ça soit en 2D ou 3D parce qu'il est le principal bottleneck (goulot d'étranglement).

Sur MD , tu peux remplir 3 fois l'écran , c'est une réso de 320x224 , donc tu peux dessiner 320x224*3 (2 BG + 80 sprite qui peuvent remplir l'écran).
Et si tu veux connaityre le nombre de pixel/s que fait la MD tu fait donc 320x224*3*60
Si tu voudrais faire pareil sur micro , ça serait pas possible , parce que dessiner autant à l'écran avec les co-proc ou le CPU ne peuvent pas le faire (ou alors tu vise pas le 60 fps).

La 3D c'est un peu pareil , tu as souvent sur certaine machine , plus de calcul de triangle que de draw qui est capable de suivre (techniquement la gamecube qui peut calculer plus de triangle que la PS2 et la XBOX , mais le GPU en dessine juste 2 fois moins que les deux autres).

Je vois, mais je conçois quand même pas la pertinence de l'information pour le développeur, ni en quoi c'est le principal goulot d'étranglement.

Typiquement, la MD, tu ne peux pas modifier intégralement au CPU les 2 BG + les sprites en une frame (au mieux quelques ko).

De même, sur micro, tu vas pas organiser ton affichage en 2 BG complet, tu vas plutôt utiliser des algos pour savoir ce qu'il faut rafraîchir ou pas, et minimiser les réécritures.

Du coup :

* pris séparément chaque nombre me semble inutile (le goulot d'étranglement me semble plutôt être la puissance CPU pour gérer les différents objets, et la vitesse de transfert en VRAM)

* les comparer entre eux me semble non pertinent (vu que tu n'utilises pas du tout les mêmes méthodes pour gérer l'affichage)

D'ailleurs je ne me suis jamais posé la question de leurs valeurs quand je développe sur une machine ou une autre (j'ai un peu tâté de l'Amiga par le passé)

C'est certainement différent en 3D.

(ma remarque n'est pas agressive, je comprends juste pas en quoi ce nombre est important et ce qu'il implique pour le dev)

[Invité]

J'ai pas dit que c'était une comparaison pertinente (vu lesn ombreux effet hard des consoles ) , ce qui peut être intéressant c'est juste de se dire "est qu'on peut faire comme la MD donc 2 BG + 80 Sprite" qui rempli l'écran.

Et remplir l’écran dépend de la bande passante, alors sur MD , c'est le VDP qui s'en charge tu n'as pas à t'inquiéter mais sur micro (voir même sur PC de l'époque) , c'est intéressant de savoir ce que peut faire la machine au maximum (on regardant rien que la bande passante).

C'est un goulot d'étranglement parce que les calculs du CPU pour définir un BG ou des sprites sont relativement rapide , par contre les dessiners prend plus de temps.
Donc tu as une grosse dif entre les calcul de sprite/BG (lesp ositionner , les tiles utilisé ) et combien tu peux en dessiner

[Tryphon]

J'ai pas dit que c'était une comparaison pertinente (vu lesn ombreux effet hard des consoles ) , ce qui peut être intéressant c'est juste de se dire "est qu'on peut faire comme la MD donc 2 BG + 80 Sprite" qui rempli l'écran.

Je comprends mieux, je n'avais pas compris qu'on souhaitait répondre à cette question.

C'est juste que pour moi elle n'a tellement aucun sens (je veux dire : en imaginant que tu les affiches, tes 2 BG et tes sprites, s'il ne te reste plus de puissance CPU pour les gérer de façon un tant soit peu complexe, quel intérêt, à part pour une démo assez vaine ? Autant faire comme les devs SNES : des jeux avec moins de sprites, mais on compense autrement) (typiquement, je trouve que le Supa Zazai Da du Doc est un très bon exemple de quelque chose qui tourne très bien sur un STE, et que je vois pas trop comment reproduire simplement sur une MD par exemple. Et le jeu est bon, de ce que j'ai compris).

[Invité]

Autant faire comme les devs SNES : des jeux avec moins de sprites, mais on compense autrement.

C'est un troll ?
Non mais la SNES est intéressant sur ce point là , le GPU de la SNES est vraiment trop puissant pour le CPU (je l'avoue ) , c'est tout l'inverse des autres machines (et des micro/PC) où la limite était bien souvent atteinte sur ce qu'on peut dessiner à l'écran.

Surtout pour le mode7 est très gourmand en calcul , pour ça que sur Super Mario Kart ils ont rajouté une puce pour gérer les calcul du mode 7

[ArchieForEver]

J'ai du relire la doc de l'ARM2  de larchie pour savoir où tu voulais en venir  

Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.

C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.

Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.

Mais dire que  le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM

Doc VLSI page 2-20 [url=http://home.marutan.net/arcemdocs/datasheets/ARM-1bpp 300 2of2.pdf]http://home.marutan.net/arcemdocs/datasheets/ARM-1bpp%20300%202of2.pdf[/url]
Les chiffres sont encore meilleurs, LDM et STM coûte 1 cycle de moins, chacun
Load Multiple : ns + 1 N +1 I
Store multiple (n-1)S + 2N
-
Dans celle de VLSI ultérieure, ISBN 0-13-781618-9 qui correspond aux systèmes avec MEMC1A, page 2-11 :
LDM (n+1) S + 1N
STM (n-1)S + 2N

voir 1er lien pour comprendre ce que signifie les lettres.

J'ai raison et tu te plantes.

[Invité]

(typiquement, je trouve que le Supa Zazai Da du Doc est un très bon exemple de quelque chose qui tourne très bien sur un STE, et que je vois pas trop comment reproduire simplement sur une MD par exemple. Et le jeu est bon, de ce que j'ai compris).

Parce que ça montre la flexibilité d'un blitter par rapport au hard borné d'une console . 

[ArchieForEver]

J'ai du relire la doc de l'ARM2  de larchie pour savoir où tu voulais en venir  

Tu viens de comprendre que tu as posté n'importe quoi surtout : aucun de tes commentaires n'est valide.

C'est vraiment mal connaître l'architecture de l'ARM2 alors, je te conseille de lire ceci :
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
Ce que je dis ne vient que de ce wiki donc sauf si tu considère que cet article est faux.
Mais il n'est pas exhaustive.

Tu peux voir sur ce wiki toute les instructions ARMv1 et v2 :
https://en.wikichip.org/wiki/arm/armv1
https://en.wikichip.org/wiki/arm/armv2
Donc que LDMIA/STMIA permet de faire un load/store par paquet n'est pas expliqué.

Mais dire que  le fonctionnement de LDR/STR est faux , c'est que tu connais mal l'ARM

C'est ton, problème si tu prends des sites qui n'expliquent pas que LDMIA et STMIA marchent par paquets, pas le mien.

LDR / STR je connais bien mieux que toi, et ce n'est pas ce dont je te parlais, puisque je parlais d'instructions de transferts par paquets, LDM / STM et toi tu me donnes les chiffres pour transferts 'simples' LDR / STR : du coup
1/ Tu es hors sujet
2/ Tu ne maîtrises pas le jeu d'instructions de l'ARM2, puisque tu ne sais pas comment fonctionnent les familles d'instructions LDM et STM et je dois te l'expliquer, te le rappeler de nouveau, avec exemple et comptages des cycles à l'appui, ce qui est, au contraire de tes dires, hautement intelligible, à moins d'être limité intellectuellement, et / ou de ne pas savoir lire ( normalement, si on est allé + loin qu'une 3è, la lecture et compréhension d'un court texte explicatif sont maîtrisées )
3/ Au final tu te ridiculises en exposant ta méconnaissance du sujet ; et de surcroît tu es arrogant en pensant que tu vas m'apprendre quoi que ce soit, et en affirmant à de multiples reprises que je connaitrais mal l'ARM, alors que c'est bien toi qui pédales dans la choucroute, prouvé par A+B

Qu'est ce qu'on rigole ici 

Au suivant.
Y a un volontaire pour jouer au + malin ?

[Invité]

Non non j'ai bien raison sur ce que tu dis , le taux de cycle n'a aucun sens sur un processeur ARM ou les suivants , c'est un processeur avec une pipeline et cette doc est assez incomplète , elle n'indique pas la pipeline des instructions.

Techniquement un ARM fait tout sur 3 cycles (je suppose il y'a rarement une explication exhaustive de la pipeline) et il va paralléliser certaine instructions. (et donc réduire tout à 1 cycle au mieux).
Et comme je l'ai dit avant LDR/STR ne pourra jamais faire un cycle , parce qu'il y a une contrainte physique qui l’empêche (le bus) qui entre en conflit avec les autres instructions exécuter en //.
Le taux de cycle est une question de contexte sur ce genre de proco.

[ArchieForEver]

Non non j'ai bien raison sur ce que tu dis , le taux de cycle n'a aucun sens sur un processeur ARM ou les suivants , c'est un processeur avec une pipeline et cette doc est assez incomplète , elle n'indique pas la pipeline des instructions.

Techniquement un ARM fait tout sur 3 cycles et il va paralléliser certaine instructions. (et donc réduire tout à 1 cycle au mieux).
Et comme je l'ai dit avant LDR/STR ne pourra jamais faire un cycle , parce qu'il y a une contrainte physique qui l’empêche (le bus) qui entre en conflit avec les autres instruction exécuter en //.
Le taux de cyle est une question de contexte sur ce genre de proco.

Je ne t'ai jamais parlé de LDR ou STR.
Je t'ai parlé de LDM ou STM, alors utiliser les timings de LDR et STR pour contredire ce que j'ai écrit et qui concerne LDM et STM : c'est ton problème de dissonance cognitive, et pas le mien.

[Invité]

Apprend à lire ce qu'est une dissonance cognitive ,ce qui n'est pas le cas ici

Et j'ai bien dit que oui je n'avais pas compris que tu parlais de LDM/SDM ton explication n'était pas clair , on plus d’être très poli sur la forme

Et j'ai ensuite dit que oui avec ces instruction tu peux atteindre une  bande passante correct sur la RAM , et tu as continué en disant que je disais n'importe quoi ce qui n'est pas le cas (rien ce que j'ai dit était faux ,au mieux non exhaustive), vu que je parlais de load/store normal dans mon explication et j'ai basé mes calculs dessus (ce qui semble assez évident si tu avais bien lu).

ensuite on parle d'un processeur ARM et donc j'ai rajouté des détails technique sur la pipeline des instructions , le bus , et les processeurs RISC , mais c'est pas un sujet que tu connais apparemment

[ArchieForEver]

Apprend à lire ce qu'est une dissonance cognitive ,ce qui n'est pas le cas ici

Et j'ai bien dit que oui je n'avais pas compris que tu parlais de LDM/SDM ton explication n'était pas clair , on plus d’être très poli sur la forme

Et j'ai ensuite dit que oui avec ces instruction tu peux atteindre une  bande passante correct sur la RAM , et tu as continué en disant que je disais n'importe quoi ce qui n'est pas le cas (rien ce que j'ai dit était faux ,au mieux non exhaustive), vu que je parlais de load/store normal dans mon explication et j'ai basé mes calculs dessus (ce qui semble assez évident si tu avait bien lu).

Mon explication est totalement limpide puisque je parle de chargements par paquets multiples.
Tu ne sais pas lire et / ou ne comprends pas un texte simple, même avec un exemple complètement détaillé et commenté, comme celui que j'ai rédigé.
Je l'ai dit : c'est ton problème ; pas le mien.

[Invité]

Ne sois pas prof à l'avenir , c'est mon conseil