GPU : interet de storep - Page 1

Bonjour à tous,

je bosse actuellement sur un dev avec plein de sprites ( video exclusive ci dessous )
( les saccades sont liées à l'émulateur phoenix, sur la Jaguar cette version passe nickel en 60 fps)

et forcément au bout d'un moment, j’atteins les limites de l'ensemble création de l' OL au GPU + 68000 qui gère en fond

et je me demandais si je pouvais speeder mes créations d'objet bitmap de sprite en utilisant storep
de ce que je comprends, ça m'oblige à créer mes 8 octets de sprite dans un coin de la ram GPU puis de copier d'un coup avec storep dans la ram centrale
alors qu'actuellement j'écris 2x4 octets avec store ( tout court)

y a t il un gain vraiment significatif ?
( l'existence de l'instruction le suggère sinon pourquoi l'auraient ils créer)

pour utiliser storep, il faut avoir 4octets LOW dans un registre rX et les 4octets HI dans G_HIDATA.

Son utilisation a des avantages comme des inconvénients.

Avantages :
- 1 seul accès mémoire externe au lieu de 2 : si tu as la bande passante saturé, ça peut (un peu) aider
- potentiellement des optimisations d'utilisation pipeline possible

Inconvénients :
- il faut charger G_HIDATA en faisant un store avant (donc au final on fait 2 store quand même, mais l'un est interne et l'autre externe au lieu de 2 externes)
- la valeur n'est pas persistante : si il y a un load externe qui est fait, le G_HIDATA est corrompu (ce qui peut arriver si tu utilises des load externe dans une interruption GPU et que tu fais tes storep en dehors des interruptions)

En bref :
il n'y aura pas de gain significatif.
Il y aura un peu de gain si ton code se prête bien à son utilisation mais ça ne sera pas extraordinaire .

Si tu reconstruis toute ta liste d'OP à chaque frame, une meilleure solution est de ne rafraîchir que ce qui est nécessaire (les parties que l'OP modifie, et ce qui a besoin de changer).

Une autre piste peut être de construire ta liste complète en RAM GPU, et de la transférer en un coup de blitter en RAM principale (comme tu fais une copie, tu n'as plus besoin de rafraîchir ce que l'OP modifie, uniquement ce qui change par rapport à la frame précédente).

Version encore plus bourrin : ne pas utiliser la RAM principale du tout, et laisser l'OP accéder directement à la liste en RAM GPU (mais je ne sais pas si ça fonctionne en pratique, et il est très possible que ça ralentisse suffisamment le GPU pour faire pire que mieux en pratique).

pour la localisation en ram gpu de mon OL, c'est mort, j'ai des tiles de 32x32 sur 3 epaisseurs + 50 sprites d'ennemis + 5 tirs du joueur + 3 tirs ennemis + le vaisseau du joueur + jusqu'a 10 explosions = 309 sprites * 16 octets = 4944 octets
+ les BRAs d'arborescence et les stops
et j'ai 2 object lists, forcément

actuellement je rafraichis uniquement les entrées sprites, pas les BRAs permettant de splitter les blocs.
et comme les sprites bougent ( scrolling des tiles + déplacement de tout le reste), y a pas grand chose qui reste identique entre chaque frame.

Pour les plans à base de tiles, il y a une autre possibilité pour les afficher :

Si le scrolling est vertical par exemple, il te faut un buffer qui soit un peu plus haut que l'écran. À chaque trame, tu ne redessines (en utilisant le GPU ou le Blitter) que les quelques nouvelles lignes qui vont devenir visibles à la trame suivante. Et pour donner l'impression que ça scrolle, tu splittes l'écran en 2 objets à l'affichage : un qui affiche la "fin" de ton buffer en haut de l'écran, et un qui affiche le "début" de ton buffer en-dessous (les hauteurs des deux objets, et l'adresse de départ pour le premier objet, sont changées à chaque trame pour que le résultat soit le même que si le buffer était circulaire).

Bien sûr on peut faire pareil dans le sens horizontal, ou combiner les deux pour pouvoir scroller dans les deux directions.

C'est un peu plus de boulot que de laisser l'OP tout dessiner à la main, et ça utilise plus de mémoire vu qu'il faut des buffers, mais en contrepartie la liste d'OP est beaucoup plus courte.

Je n'ai jamais testé de mettre la liste dans la RAM GPU et l'utiliser directement donc je ne sais pas si ça fonctionne.

Néanmoins, je déconseille fortement car l'accès à la mémoire GPU ne se fait qu'en 16-bit par les composants externes. (il y a qu'en écriture que l'on peut faire à un accès direct 32-bit dans la zone +$8000)

super astuce pour le scrolling ! merci Zerosquare

l'idée de faire des tiles à la Néo-Géo c'est de pouvoir les animer donc chaque tile doit être un sprite possiblement différent à chaque frame.

A voir si ça devient réalité.

Il n'y a rien qui t'empêche de redessiner complètement un tile dans ton buffer s'il a changé. Mais en pratique, je pense que tu ne vas pas t'amuser à changer 100% des tiles 60 fois par seconde