Triple buffering - Page 2

Un exemple: // C Source File // Created 13/08/2003; 18:42:10 #define USE_TI89              // Compile for TI-89 #define USE_TI92PLUS          // Compile for TI-92 Plus #define USE_V200              // Compile for V200 // #define OPTIMIZE_ROM_CALLS // Use ROM Call Optimization #define SAVE_SCREEN           // Save/Restore LCD Contents #include <tigcclib.h>         // Include All Header Files #include "XLib.h" struct{      short Largeur;      long* teste[15*8*36]; }XBackLevel2; char datas[16*2*2] = { 0b11111111,0b10000001,     0b11111111,0b11111111,     0b11000000,0b00000011,     0b11000000,0b00000011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11001111,0b11110011,     0b11000000,0b00000011,     0b11000000,0b00000011,     0b11111111,0b11111111,     0b11111111,0b11111111 };   // Main Function  void _main(void) {      struct XBackLevel z;       #define z XBackLevel2      unsigned long a;      unsigned short i,k;      z.Largeur = 15;      a=0;      for (i=0;i<15*8*36;i++) z.teste[i]= datas;             XOn();      XTimer5 = 0;       for(k=2560/2;k--;)      {           XBackGround(0,0,&z);           XGSwap();      }      XOff();      a =  (2560/2) * 20 /XTimer5  ; printf_xy(0,0,"%u",(int)a); ngetchx();        } 

PpHd
: Sauf qu'il suffit de bien se debrouiller dans ton code et tu n'en as pas besoin.

Pas besoin de quoi ?

Attendre la synchro je présume ?

Et donc du triple buffering


Merci Sasume pour cette perche^^

Il faut dire aussi que le code de double buffering de tigcc est mauvais alors

Tandis que celui de GenLib ...

[/pub]

Pollux :
bah, je suis ouvert à toute proposition, même celle de Kevin s'il en a de meilleures

La solution est de ne pas présupposer que les 2 plans sont consécutifs. Il est vraiment facile de modifier des routines existentes pour supprimer cette présupposition incorrecte, ça m'a pris 10 minutes pour la Tilemap Engine de ExtGraph.

"meilleure" dans le sens "gagner en vitesse".

PpHd
: Ca sert a quoi le triple buffering sur TI a part perdre de la RAM ?

Sur HW1/VTI, avec le double-buffering par échange de pointeurs, on est obligé de faire un GrayWaitNSwitches(2); après le GrayDBufToggle(); avant de pouvoir dessiner quoi que ce soit sur le plan caché.

Sasume :
Font chier ces HW2 quand même Ça aurait été plus simple avec le système des HW1, non ?

Ce sont justement les HW1, le problème.

Ximoon
: "meilleure" dans le sens "gagner en vitesse".

On ne perd rien en vitesse en ne pas présupposant les plans consécutifs! On a (%an) et (%am) au lieu d'avoir (%an) et 3840(%an), c'est même plus rapide. (Encore une fois: J'ai fait l'expérience sur TileMap.)

pas sûr kevin... Car il faut que tu incrémentes les deux pointeurs en même temps, et ça ne peut se faire en une instruction.
(Et au passage ça serait bien que tu évites de poster pour répéter exactement la même chose que ce qu'on déjà dit certaines personnes dans ce topic...)

De plus, Pollux dit explicitement qu'il gagne en vitesse avec des plans consécutifs.

>Sur HW1/VTI, avec le double-buffering par échange de pointeurs, on est obligé de faire un GrayWaitNSwitches(2); après le GrayDBufToggle(); avant de pouvoir dessiner quoi que ce soit sur le plan caché.
Pas si on s'y prend correctement.

GoldenCrystal
: pas sûr kevin... Car il faut que tu incrémentes les deux pointeurs en même temps, et ça ne peut se faire en une instruction.

Exemples?
* (%an)+ prend 4 cycles de moins que 3840(%an).
* ...,0(%an,%dn.w);...,0(%am,%dn.w) prend 4 cycles de moins que adda.w %dn,%an;...,(%an);...,3840(%an).
* x(%an) et x(%am) prennent autant de cycles que x(%an) et x+3840(%an).
etc.

(Et au passage ça serait bien que tu évites de poster pour répéter exactement la même chose que ce qu'on déjà dit certaines personnes dans ce topic...)

Je n'ai pas répété ce qui a déjà été dit.

Ximoon
: De plus, Pollux dit explicitement qu'il gagne en vitesse avec des plans consécutifs.

Et ben, à mon avis, il n'a jamais essayé, donc je ne lui crois pas. Sasume pensait aussi que TileMap allait perdre en vitesse en abandonnant cette présupposition, et je lui ai montré le contraire.

PpHd :
>Sur HW1/VTI, avec le double-buffering par échange de pointeurs, on est obligé de faire un GrayWaitNSwitches(2); après le GrayDBufToggle(); avant de pouvoir dessiner quoi que ce soit sur le plan caché. Pas si on s'y prend correctement.

On peut utiliser une partie du temps d'attente pour faire des calculs, et puis?

#43> Tu ne connais pas son algo, si ?

et puis ?
Apprendre a designer un jeu par exemple.

Euh stop là, on reste dans le sujet PpHd & Kevin, à savoir le triple buffering merci (et dans le calme).

-

Echanger les pointeurs du buffer de travail et du buffer affiché? Oui c'est possible, après ça dépend peut être de la lib que tu utilises pour générer les nvg.

Kevin Kofler
: Je n'ai pas répété ce qui a déjà été dit.

Tu veux qu'on vérifie ?

Kevin Kofler
:

PpHd
: Ca sert a quoi le triple buffering sur TI a part perdre de la RAM ?

Sur HW1/VTI, avec le double-buffering par échange de pointeurs, on est obligé de faire un GrayWaitNSwitches(2); après le GrayDBufToggle(); avant de pouvoir dessiner quoi que ce soit sur le plan caché.

Alors que:

GoldenCrystal
: Sur HW1 je pense que je vois (éviter les clignottements sans utiliser GrayWaitNSwitches(2), donc sans perte de vitesse), mais sur HW2 ?

Sasume :
Font chier ces HW2 quand même Ça aurait été plus simple avec le système des HW1, non ?

Ce sont justement les HW1, le problème.

Alors que:

Pollux
: Sasume> euh non, au contraire, c les HW1 qui posent pb... sur HW2, au moment où tu viens d'échanger les plans, la copie du plan actuel a déjà été entièrement lue (l'interruption ne se fait pas en parallèle de l'exécution du prog) et le plan suivant sera le plan que tu veux afficher. Alors que sur HW1, quand tu viens d'échanger les plans, l'écran est toujours en train d'afficher le vieux buffer, donc au moment où tu le modifies, ça clignote... En gros sans triple buffering sur HW1 tu dois attendre 1 frame ou 2 suivant que l'écran en cours d'affichage est celui de poids fort ou de poids faible.

Alors ?

Orion_
: c possible ?

Oui, c'est ce que fait le double-buffering de TIGCC. Ça te dirait de lire la documentation?

GoldenCrystal
: Alors ?

Oups...

-

Oui.
Et n'oublie pas les avertissements au sujet des HW1, sinon ton programme va être inutilisable à force de clignoter (mais tu le verras bien sur VTI...).

Kevin Kofler
:

GoldenCrystal
: pas sûr kevin... Car il faut que tu incrémentes les deux pointeurs en même temps, et ça ne peut se faire en une instruction.

Exemples?
* (%an)+ prend 4 cycles de moins que 3840(%an).
* ...,0(%an,%dn.w);...,0(%am,%dn.w) prend 4 cycles de moins que adda.w %dn,%an;...,(%an);...,3840(%an).
* x(%an) et x(%am) prennent autant de cycles que x(%an) et x+3840(%an). etc.

Ce n'est pas de ça qu'il parlait.
Mais de toute façon tes remarques sont fausses cf plus bas (et je pense que tu le sais très bien, mais que tu fais exprès de mentir pour convaincre les autres, puisqu'ils ne risquent pas de vérifier auprès des sources du tilemap engine que tu racontes n'importe quoi).

Ximoon
: De plus, Pollux dit explicitement qu'il gagne en vitesse avec des plans consécutifs.

Et ben, à mon avis, il n'a jamais essayé, donc je ne lui crois pas. Sasume pensait aussi que TileMap allait perdre en vitesse en abandonnant cette présupposition, et je lui ai montré le contraire.

Alors, ce qui m'ennuyait, c'est le fait que les fonctions prennent un paramètre en plus : d'une part, ça risque de pessimiser le code appelant la fonction, d'autre part, pour certaines fonctions (celles qui utilisent les tables DHZ/HDZ), il y avait clairement trop de paramètres à passer à la fonction puisque a0, a1, a2, a3 et a4 étaient utilisés. Sachant que a5 est utilisé par OPTIMISE_ROM_CALLS et que a6 sert de frame-pointer, ces fonctions risquaient de faire planter l'allocateur de registres de TIGCC (il me semble qu'on en avait parlé sur IRC même).
C'était ça le vrai problème.
Ce que tu as dit plus haut est faux, tu n'as pas remplacé des 3840(%an) par des (%am), puisqu'au début de mes fonctions, je faisais un lea.l 3840(%an),%am qui me permettait de me mettre dans la même situation que si j'avais 2 planes différents.
Donc les fonctions modifiées par ton patch ne sont pas plus rapides. Enfin, il y a juste le lea au début qui disparaît, mais ça représente une portion complètement négligeable du code de la fonction, et vu les problèmes que ton patch peut poser (et le problème qu'il pose réellement : pessimisation du code appelant), je pense que ça n'a aucun intérêt de passer par des plans séparés (et je me fous totalement du double buffering de TIGCC qui utilise des fonctions de niveaux de gris qui cachent certaines parties de la programmation à l'utilisateur qui sera perdu ensuite lorsqu'il aura besoin de connaître la notion de heap, enfin, je m'égare là...).

1. -fomit-frame-pointer existe.
2. USE_FLINE_ROM_CALLS existe.
Je n'en dirai pas plus sur l'histoire des registres.

1. Impossible avec les programmes utilisant les float
2. Et tu oses dire que ça ne ralentit pas... Franchement, tu es vraiment de mauvaise foi, c'est réellement insupportable

Pourquoi tu n'en dis pas plus ? Et le fait que ça pessimise le code appelant ? Et le fait que ça peut gêner l'allocateur de registres ?

Sinon, pour revenir au sujet (ou presque) : quelqu'un peut-il expliquer comment faire pour stabiliser les niveaux de gris sur HW2 (sur HW1 c'est compliqué ou non ?) ?
Perso, j'ai beau avoir lu j89hw.txt, j'ai toujours du mal à trouver une méthode efficace pour avoir des beaux niveaux de gris qui ne scintillent pas...

Ben, il y a un port qui te permet de mofifier la hauteur virtuelle de l'écran (on peut faire pas mal de conneries avec d'ailleurs ) Si tu diminues cette hauteur virtuelle, le rafraîchissement sera plus fréquent et les gris scintilleront peut-être un peu moins. Je crois que c'est ce que fait GrayAdjust, donc essaye là avant de tenter un accès direct au hardware.
Mais je pense pas que le scintillement puisse être complètement éliminé. Exposer la calc. au soleil suffit déjà à voir le balayage de l'écran quand il est en n&b alors les nvg...