Logicielsmoto.com

Nous sommes le 28 Mar 2024, 19:01

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 32, 33, 34, 35, 36, 37, 38 ... 40  Suivante
Auteur Message
MessagePosté: 04 Nov 2022, 11:55 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
ah ok les points sont normaux.

En fait la SD "en mode streaming", c'est ce que j'utilise dans SDVideo. C'est un fichier SD comme les autres, ce qui permet d'en avoir autant qu'on veut sur une carte SD, mais il ne contient qu'une seule face bootable au format thomson. Cette face contient le loader, mais ce dernier, au lieu de passer par les API du moniteur pour lire les pistes des autres lecteurs émulés, passe le disk SD en mode stream. La carte SD nous envoie alors les octets du reste du fichier SD les uns à la suite des autres sans tenir compte de l'abstraction "diskette".
https://github.com/Samuel-DEVULDER/SDVi ... r.ass#L285

En gros le fichier SD ne contient qu'une face, suivie de plein de datas. Datas qu'on lit à pleine vitesse pour remplir la RAM super vite (ou qu'on donne au décompresseur peu importe). Ce sont des fichier SD mixe: Thomson-DOS + Données.

[edit] ok avec les deux fichiers manquants ca compile.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 04 Nov 2022, 12:10, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Nov 2022, 11:58 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
non c'est ma faute je t'ai livré le properties linux du projet avec le define debug ...
il faut le retirer ! surtout si on fait du profiling :D

A la racine sonic-2 dans s2-EHZ-halfline2-linux.properties :
remplacer
builder.lwasm.define=halfline,debug
par
builder.lwasm.define=halfline


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Nov 2022, 12:01 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Samuel Devulder a écrit:
Ce sont des fichier SD mixe: Thomson-DOS + Données.


ça me semble le bon compromis effectivement :good:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Nov 2022, 12:30 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Bentoc a écrit:
A la racine sonic-2 dans s2-EHZ-halfline2-linux.properties :
remplacer
builder.lwasm.define=halfline,debug
par
builder.lwasm.define=halfline
Ok c'est fait.

Voici le profile avec Sonic allant à fond dans les décors de gauche à droite pendant 32s, ce qui fait une moyenne des routines:
https://www.cjoint.com/doc/22_11/LKelqD ... emmap.html

Je l'analyse comme suit:
* 25% du temps c'est l'affichage des tuiles "vides". On y fait essentiellement des PULU D,X pour se rendre compte que B=0 lors du STB $E7E6
* 11% du temps c'est l'affichage de tuiles "pleines" avec le JSR

Au total ca nous fait 36% du temps dans l'affichage des tuiles. Je soupçonne qu'on peut gagner un peu en moyenne sur les premiers 25% car le PULU lit des trucs intuiles. Si on chargeait B et se rendre compte qu'il est nul tout de suite on a pas besoin de charger A et X (3 cycles en trop). Par contre "LDB 1,U" coute à lui seul 5 cycles contre 9 pour le PULU. Ok on ne fait pas de STB $E7E6 dans ce cas ce qui économise 5 cycles, mais on perds 5 cycles à cause du LEAU 4,U qu'il faudrait rajouter. Humm c'est pas certain qu'on arrive à gagner significativement quelque chose. Et pourtant 25% de tuiles vides semble être un endroit où gagner du temps.
[EDIT] j'ai une idée...

Ensuite viennent:
* 9% dans un code ($7DE8) qui ressemble furieusement à celui que j'ai optimisé pour les tuiles, mais qui est utilisé ailleurs. C'est la gestion des sprites ?
[EDIT] non c'est Find_Tile
* 4.7% et moins dans des trucs pas significatifs.
* 3% dans un truc bizarre:
Code:
83D6   8426   ----   6516   109EC3   6   LDY   <$C3
83D9   ----   ----   6516   ECC1     8   LDD   ,U++
83DB   ----   ----   6516   2608     3   BNE   $83E5
83DD   ----   ----   2223   CC0000   3   LDD   #$0000 <=== en ce point D est forcément à 0. Pourquoi le recharger ?
83E0   ----   ----   2223   EDA4     5   STD   ,Y
83E2   ----   ----   2223   7E8414   4   JMP   $8414

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Nov 2022, 13:44 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
pour le ldd #0 effectivement il n'a pas de raison d'être ... un oubli certainement
cette méthode est celle qui valorise le buffer dont tu as optimisé la lecture.
C'est un peu plus haut dans le code.

Find_Tile c'est ce qui permet de trouver les données de collision pour un tile. Ici on travaille sur une map différente, mais le principe reste le même.
Cette méthode est appelée ne nombreuses fois par boucle principale.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 04 Nov 2022, 15:05 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Justement, je viens de gagner quelques cycles pour FileTile.

la version d'origine coute 89 cycles sur cette portion de code:
Code:
Find_Tile                                             * Find_Tile:
        lda   glb_map_chunk_pge
        _SetCartPageA   
        ldd   glb_d2                                  *         movea.w d2,d0   ; y_pos
        ; unlike original no interlace of background
        ; and foreground in tilemap                   *         add.w   d0,d0
        anda  #$0F
        andb  #$80                                    *         andi.w  #$F00,d0        ; rounded 2*y_pos
        std   glb_d0
        ldd   glb_d3                                  *         movea.w d3,d1   ; x_pos
        _lsrd
        _lsrd                                         *         lsr.w   #3,d1
        stb   @d4_b                                   *         movea.w d1,d4
        _lsrd
        _lsrd
        _lsrd
        _lsrd ; shift only by 6 (64px not 128px)      *         lsr.w   #4,d1   ; x_pos/128 = x_of_chunk
        anda  #0
        andb  #$7F                                    *         andi.w  #$7F,d1
        addd  glb_d0                                  *         add.w   d1,d0   ; d0 is relevant chunk ID now
                                                      *         moveq   #-1,d1
        ldx   glb_map_chunk_adr                       *         clr.w   d1              ; d1 is now $FFFF0000 = Chunk_Table
        leax  d,x                                     *         lea     (Level_Layout).w,a1
        lda   ,x                                      *         move.b  (a1,d0.w),d1    ; move 128*128 chunk ID to d1
        bpl   @a

Ici une version où j'ai juste un peu réorganisé le calcul pour réduire les accès mémoire et les opérations
Code:
Find_Tile                                             * Find_Tile:
        lda   glb_map_chunk_pge
        _SetCartPageA
        ldd   glb_d2                                  *         movea.w d2,d0   ; y_pos
        ; unlike original no interlace of background
        anda  #$0F
        andb  #$80                                    *         andi.w  #$F00,d0        ; rounded 2*y_pos
        addd  glb_map_chunk_adr
        tfr   d,x                                     *         lea     ((Level_Layout).w,d0.w),a1 +
        ldd   glb_d3    ; D=zzzzzzyy yyyyyyyy         *         movea.w d3,d1   ; x_pos
        _lsrd
        _lsrd           ; D=00zzzzzz yyyyyyyy         *         lsr.w   #3,d1
        stb   @d4_b                                   *         movea.w d1,d4
        ; and foreground in tilemap                   *         add.w   d0,d0
        _lsrd           ; D=000zzzzz zyyyyyyy
        _lsrd           ; D=0000zzzz zzyyyyyy
        _lsrd           ; D=00000zzz zzzyyyyy
        lsrb            ; D=-------- 0zzzyyyy         *         lsr.w   #4,d1   ; x_pos/128 = x_of_chunk
                                                      *         andi.w  #$7F,d1
        lda   b,x
        bpl   @a
coute 72 cycles. Résultat on passe de 9.95% à 8.81% du temps. Un peu plus de 1% de temps et quelques octets gagnés. C'est toujours ca.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Nov 2022, 08:03 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
C’est toujours bon à prendre !

Pour les tuiles vides /pleines il vaut mieux prioriser les performances sur les tuiles pleines, même si c’est au détriment des vides. Car dans le cas des vides il y a moins de traitement derrière (pas d’affichage).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Nov 2022, 10:46 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
FindTile apparait toujours très haut dans mes derniers profiles. Par exemple, dans ce dernier, j'ai réduit le DrawBufferedTile à 20%, et le FindTile en 2e place coûte à lui-seul rien moins que 9%. C'est juste énorme.
https://www.cjoint.com/doc/22_11/LKewMj ... .html#7DE8

Il n'y a pas de boucle dedans. Juste du calcul brut. J'ai l'intuition que cela doit pouvoir se calculer plus rapidement car c'est un traduction 1 pour 1 du code 68000. Je vais essayer de comprendre l'ensemble du calcul pour voir si on ne pourrait pas faire plus court et plus rapide en écrivant directement pour le 6809.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 05 Nov 2022, 11:00 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Le fonctionnement est décrit ici : http://info.sonicretro.org/SPG:Solid_Tiles
Si ça peut aider …


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 06 Nov 2022, 17:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Bon j'ai avancé. Cette routine est partagée en deux parties qui assemblent des bouts de glb_d2 et glb_d3 pour obtenir les bons offset dans divers tableaux
Code:
[5]     5939            ldd   glb_d2                                  *         movea.w d2,d0   ; y_pos
                        ; unlike original no interlace of background
                        ; and foreground in tilemap                   *         add.w   d0,d0
[2]     5941            anda  #$0F
[2]     5943            andb  #$80                                    *         andi.w  #$F00,d0        ; rounded 2*y_pos
[5]     5948            std   glb_d0
[5]     5953            ldd   glb_d3                                  *         movea.w d3,d1   ; x_pos
                        _lsrd
[2]     5955            lsra
[2]     5957            rorb
                        _lsrd                                         *         lsr.w   #3,d1
[2]     5959            lsra
[2]     5961            rorb
[5]     5966            stb   @d4_b                                   *         movea.w d1,d4
                        _lsrd
[2]     5968            lsra
[2]     5970            rorb
                        _lsrd
[2]     5972            lsra
[2]     5974            rorb
                        _lsrd
[2]     5976            lsra
[2]     5978            rorb
                        _lsrd ; shift only by 6 (64px not 128px)      *         lsr.w   #4,d1   ; x_pos/128 = x_of_chunk
[2]     5980            lsra
[2]     5982            rorb
[2]     5984            anda  #0
[2]     5986            andb  #$7F                                    *         andi.w  #$7F,d1
[6]     5992            addd  glb_d0                                  *         add.w   d1,d0   ; d0 is relevant chunk ID now                                                      *         moveq   #-1,d1
[6]     5998            ldx   glb_map_chunk_adr                       *         clr.w   d1              ; d1 is now $FFFF0000 = Chunk_Table
[8]     6006            leax  d,x                                     *         lea     (Level_Layout).w,a1
[4]     6010            lda   ,x                                      *         move.b  (a1,d0.w),d1    ; move 128*128 chunk ID to d1
TOTAL=76 cycles
et
Code:
[2]     6052            andb  #0 ; shift right to get x128
                        _asrd    ; instead of using a LUT             *         add.w   d1,d1
[2]     6054            asra
[2]     6056            rorb
[8]     6064            leax  d,x                                     *         move.w  word_1E5D0(pc,d1.w),d1
[4]     6068            ldb   glb_d2_b                                *         movea.w d2,d0   ; y_pos
[2]     6070            andb  #$70                                    *         andi.w  #$70,d0
[3]     6073            abx                                           *         add.w   d0,d1
[2]     6075            ldb   #0
                @d4_b   equ   *-1
[2]     6077            andb  #$E                                     *         andi.w  #$E,d4  ; x_pos/8
[3]     6080            abx                                           *         add.w   d4,d1
                        ; x is loaded with address of block ID        *         movea.l d1,a1   ; address of block ID
TOTAL=28 cycles
A elles deux, cela coute 104 cycles. C'est peu, mais comme la routine est appelée super souvent, la routine Find_Tile se retrouve en 3e position (10% du temps passé dedans) juste après le remplissage des tuiles lors d'un profiling de 30s de la course de Sonic sur tous les tableaux vers la droite. (https://www.cjoint.com/doc/22_11/LKgpwL ... .html#7DEB)

La routine en soi est déjà bien optimisée, mais c'est une traduction fidèle de ce que fait le code 68000. Là dedans deux choses me semblent optimisables: les décalages, certes peu couteux sur 6809, mais très nombreux, et les accès mémoire 16 bits qui sont vraiment lents. Tout va plus vite si on peut travailler au max de registre à registre sans passer par la mémoire (cf le glb_d0 qui sert de temporaire).

J'ai décidé de me focaliser sur les décalages. Le 1er décalage intéressant est à droite six fois sur 16bits, soit 24 cycles. C'est pas beaucoup mais cela coute 1/3 du temps de calcul, alors qu'on ne retient de ces 16 bits que 7 bits seulement. On pourrait convertir ce décalage à droite 6 fois en 2 décalages à gauche et retrouver ces mêmes bits non pas sur B, mais sur A. C'est ce que je fais dans cette réécriture du 1er calcul:
Code:
[6]     5940            ldx   glb_map_chunk_adr
[5]     5945            ldd   glb_d3
                        _lsld
[2]     5947            lslb
[2]     5949            rola
                        _lsld
[2]     5951            lslb
[2]     5953            rola
[2]     5955            anda  #$7F
[5]     5960            leax  a,x
[5]     5965            ldd   glb_d2
[2]     5967            anda  #$0F
[2]     5969            andb  #$80
[8]     5977            lda   d,x
TOTAL=43 cycles
On tombe à 43 cycles au lieu de 76. C'est vachement mieux. Le hic est qu'alors on a pas @d4_b qui est calculé pour la 2e partie. Il faut donc adapter le 2e calcul en conséquence en le recalculant depuis glb_d3. Mais là on peut retrouver la même valeur sans travailler sur 16bits, mais sur la partie basse de glb_d3 qui contient tout les bits recherchés. J'en profite pour l'ajouter directement à X sans le combiner à A pour rester au max sur des calculs 8 bits. Ca donne ceci:
Code:
[4]     6021            ldb   glb_d2_b
[2]     6023            andb  #$70
[3]     6026            abx
[4]     6030            ldb   glb_d3+1
[2]     6032            lsrb
[2]     6034            andb  #%00011100
                        _lsrd
[2]     6036            lsra
[2]     6038            rorb
[8]     6046            leax  d,x
TOTAL=25 cycles
Et on gagne même 3 cycles par rapport au calcul de cette 2e partie par rapport à l'original. Au final ces deux calculs font en 68 cycles ce qu'on faisait en 104. Ca n'a l'air de rien, mais dans le profiling, cette méthode tombe alors à 7.67% du temps. Ca nous fait entre 2 et 3% de gain :bien: (https://www.cjoint.com/doc/22_11/LKgpiw ... .html#7DEB)

J'ai mis le code source dans le ZIP ci-joint. Le hic, c'est que le calcul n'est plus fait dans l'ordre du 68000 et les commentaires associés ne sont pas bon. Aussi j'ai utilisé un "if 0" pour garder le code d'origine commenté pour référence.
Fichier(s) joint(s):
collision.zip [4.63 Kio]
Téléchargé 67 fois


Une dernière note: les hotspots #1 (25% du temps) et #2 (10% du temps) font partis de la routine d'affichage des tuiles. La partie à 25% correspond au cas ou STB écrit un 0 en $E7E6. L'autre correspond au cas où B écrit une vrai numéro de page et qu'on saute à la routine de sprite compilé (JSR ,x). Ca fait quand même pas mal de cas où on trouve un 0. Il faudrait que je vois s'ils sont consécutifs ou éparpillés au hasard. S'ils sont consécutifs, on pourrait imaginer détecter plusieurs tuiles consécutivement vides rapidement (en ajoutant ORB 1,U + ORB 5,U + ORB 9,U pur 4 tuiles consécutives) et sauter au dessus de plein de tuiles vides d'un coup. Ca pourrait faire gagner pas mal de temps sur la traversée de la carte.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Nov 2022, 00:25 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Merci sam c'est extra !

Je vais tester ça au plus vite. Je vais aussi regarder attentivement les résultats du profiling.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Nov 2022, 11:51 
Hors ligne

Inscription: 12 Fév 2021, 15:54
Messages: 78
Localisation: Rennes
Sam c'est un tueur quand même :beuh:

_________________
Fan de Atari 2600, Thomson MO5, Thomson TO8, Atari STE.
Retro-Codeur à mes heures perdues. https://www.fxjavadevblog.fr


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Nov 2022, 12:28 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Peut-être, mais ca ne sont que des optims à quelques %. Ca libère du cpu pour les phases plus couteuses dont on aura besoin plus tard (collisions avec les plantes ou les poissons, etc).

Mon test sur les tuiles vide est difficile à interpréter.
https://www.cjoint.com/doc/22_11/LKhkw2 ... .html#84E4

Ce que je vois sur cette instruction est que 36 000 fois sur 46 000, le BEQ n'est pas pris. Ca nous donne une densité de tuile vides de (46 000 - 36 000)/46 000 = 21% sur l'ensemble de la traversée. Mais au final à cause des tests sur le compteur de boucle, le wrapping de U, on arrive à sauter de 2 en 2 (ici) uniquement 7800 fois (17%) au lieu de 10 000 mais les gains sur les LEAY et le DEC compteurs sont marginaux.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Nov 2022, 16:53 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
@Bentoc: de ton coté comment évalue tu les perfs du rendu ? J'avoue ne pas trop sentir à l'écran si ca va plus ou moins vite en fait.

Je n'arrive pas à savoir si cette version de TilemapBuffer est plus rapide ou si c'est marginal:


Fichiers joints:
Commentaire: Plus rapide ou pas ?
TilemapBuffer.zip [5.27 Kio]
Téléchargé 68 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Nov 2022, 16:54 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
@Bentoc: de ton coté comment évalue tu les perfs du rendu ? J'avoue ne pas trop sentir à l'écran si ca va plus ou moins vite en fait.

Je n'arrive pas à savoir si cette version de TilemapBuffer est plus rapide ou si c'est marginal:
Fichier(s) joint(s):
Commentaire: On ne modifie glb_alphaTiles qu'une fois par groupe de tuiles vides.

Est-ce plus rapide ou pas ?

TilemapBuffer.zip [5.27 Kio]
Téléchargé 67 fois

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 32, 33, 34, 35, 36, 37, 38 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 29 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com