GpSurfaceFlip(); source de ralentissement ? - Page 1

-

Essaie de réécrire une fonction GpSurfaceFlip aussi (elle fait quoi cette fonction ?)

-

ThunderZ s'était déjà rendu compte de ce problème et avait quantifié la durée d'un flip. Si ma mémoire est bonne c'était de l'ordre de 20ms. A confirmer auprès de TZ.

-

erf ben bonne chance si tu toruve
Et puis fait tourner ta soluce si tu trouve sinon peut etre voir dans la SDL je pense aps qu elle s'appuie sur gamepark cette lib(ou alors ja i rein compris, ce qui ets ofrt probable car je ne me susi pas incliné dessus )).

r1, r2, r3, r4, r5, r6, r7, r8, pc} En gros voila que fait GpSurfaceFlip() @ hmm... will be copied into System RAM @ GpSurfaceSet or GpSurfaceFlip 00001BF0: E92D41FE     stmdb     sp!, {r1, r2, r3, r4, r5, r6, r7, r8, lr} 00001BF4: E3A01010     mov     r1, #16     ; 0x10 00001BF8: E3A02070     mov     r2, #112     ; 0x70 00001BFC: E3A03014     mov     r3, #20     ; 0x14 00001C00: E3A040A0     mov     r4, #160     ; 0xa0 00001C04: E1826401     orr     r6, r2, r1, lsl #8   @ r6 = 0x00001070 00001C08: E5965000     ldr     r5, [r6]             @ r5 = 0x0C7B0000 00001C0C: E5850050     str     r0, [r5, #80]        @ 0x0C7B0050 = ptr to GPDRAWSURFACE 00001C10: E1846403     orr     r6, r4, r3, lsl #8   @ r6 = 0x000014a0 00001C14: E1A06806     mov     r6, r6, lsl #16      @ r6 = 0x14a00000 00001C18: E5904000     ldr     r4, [r0]             @ r4 = GPDRAWSURFACE.ptbuffer 00001C1C: E1A03004     mov     r3, r4               @ r3 = r4 = GPDRAWSURFACE.ptbuffer 00001C20: E1A01B23     mov     r1, r3, lsr #22      @ r1 = GPDRAWSURFACE.ptbuffer >> 22 00001C24: E1A020A3     mov     r2, r3, lsr #1       @ r2 = GPDRAWSURFACE.ptbuffer >> 1 00001C28: E1A01A81     mov     r1, r1, lsl #21      @ r1 =  00001C2C: E1A02582     mov     r2, r2, lsl #11      @ r2 =  00001C30: E1A025A2     mov     r2, r2, lsr #11      @ r2 = 00001C34: E1811002     orr     r1, r1, r2           @ r1 =  00001C38: E5952054     ldr     r2, [r5, #84]        @ r2 = GPLCDINFO.buffer_size (0x0C7B0054) 00001C3C: E0833002     add     r3, r3, r2           @ r3 = ptbuffer + buffer_size 00001C40: E1A030A3     mov     r3, r3, lsr #1 00001C44: E1A03583     mov     r3, r3, lsl #11 00001C48: E1A025A3     mov     r2, r3, lsr #11 00001C4C: E5965000     ldr     r5, [r6]             @ 00001C50: E3150001     tst     r5, #1     ; 0x1        @ test ENVID i.e. is the LCD on 00001C54: 1A000002     bne     00001c64 00001C58: E2863014     add     r3, r6, #20     ; 0x14 00001C5C: E8830006     stmia     r3, {r1, r2} 00001C60: E8BD81FE     ldmia     sp!, {r1, r2, r3, r4, r5, r6, r7, r8, pc} 00001C64: E10F5000     mrs     r5, CPSR 00001C68: E38540C0     orr     r4, r5, #192     ; 0xc0 00001C6C: E5963000     ldr     r3, [r6] 00001C70: E1A03923     mov     r3, r3, lsr #18 00001C74: E3530000     cmp     r3, #0     ; 0x0 00001C78: C12FF004     msrgt     CPSR_fsxc, r4 00001C7C: E5963000     ldr     r3, [r6] 00001C80: E1A03923     mov     r3, r3, lsr #18 00001C84: E3530000     cmp     r3, #0     ; 0x0 00001C88: CA000001     bgt     00001c94 00001C8C: E12FF005     msr     CPSR_fsxc, r5 00001C90: EAFFFFF5     b     00001c6c 00001C94: E2864014     add     r4, r6, #20     ; 0x14 00001C98: E8840006     stmia     r4, {r1, r2} 00001C9C: E3A0700C     mov     r7, #12     ; 0xc 00001CA0: E3A0807B     mov     r8, #123     ; 0x7b 00001CA4: E1888407     orr     r8, r8, r7, lsl #8 00001CA8: E1A08808     mov     r8, r8, lsl #16 00001CAC: E3A07001     mov     r7, #1     ; 0x1 00001CB0: E0888507     add     r8, r8, r7, lsl #10 00001CB4: E2488068     sub     r8, r8, #104     ; 0x68 00001CB8: E12FF005     msr     CPSR_fsxc, r5 00001CBC: E3A01000     mov     r1, #0     ; 0x0 00001CC0: E3A02000     mov     r2, #0     ; 0x0 00001CC4: E1A00282     mov     r0, r2, lsl #5 00001CC8: E1800D01     orr     r0, r0, r1, lsl #26 00001CCC: EE070F5E     mcr     15, 0, r0, cr7, cr14, {2} 00001CD0: E2822001     add     r2, r2, #1     ; 0x1 00001CD4: E3520008     cmp     r2, #8     ; 0x8 00001CD8: 1AFFFFF9     bne     00001cc4 00001CDC: E2811001     add     r1, r1, #1     ; 0x1 00001CE0: E3510040     cmp     r1, #64     ; 0x40 00001CE4: 1AFFFFF5     bne     00001cc0 00001CE8: EE070F15     mcr     15, 0, r0, cr7, cr5, {0} 00001CEC: E5987000     ldr     r7, [r8] 00001CF0: E353002A     cmp     r3, #42     ; 0x2a 00001CF4: D2877003     addle     r7, r7, #3     ; 0x3 00001CF8: DA000006     ble     00001d18 00001CFC: E3A05090     mov     r5, #144     ; 0x90 00001D00: E1A05285     mov     r5, r5, lsl #5 00001D04: E0010593     mul     r1, r3, r5 00001D08: E0877821     add     r7, r7, r1, lsr #16 00001D0C: E5985000     ldr     r5, [r8] 00001D10: E1550007     cmp     r5, r7 00001D14: CA000009     bgt     00001d40 00001D18: E5965000     ldr     r5, [r6] 00001D1C: E1530925     cmp     r3, r5, lsr #18 00001D20: 0AFFFFF9     beq     00001d0c 00001D24: E2433001     sub     r3, r3, #1     ; 0x1 00001D28: E5985000     ldr     r5, [r8] 00001D2C: E1550007     cmp     r5, r7 00001D30: CA000002     bgt     00001d40 00001D34: E5965000     ldr     r5, [r6] 00001D38: E1530925     cmp     r3, r5, lsr #18 00001D3C: AAFFFFF9     bge     00001d28 00001D40: E8BD81FE     ldmia     sp!, {

Je ne vais pas vraiment commenter puisque j'ai encore pas mal de mal a lire l'asm.

-

Enlever le dernier bge (Ligne 85) et remplacer le par un nop. Normalement, ca ne fait qu'enlever la synchro finale.
Attention! L'ecran reellement affiche par la GP est encore l'ancien, donc avant de faire un appel a des fcts graphiques, faites beaucoup de calcul. Le temps que le hardware ait eu le temps de vraiment faire le flip.
PS: Ceci n'est qu'une conjecture. Je sais pas du tout si ca va marcher.
PPS: C'est mal ecrit
PPPS: Peut etre la ligne 78 aussi. Faudrait que j'y passe un peu plus de temps.

en fait, le surface flip attend le vblank avant de flipper, l'ecran est a 50hz -> 1sec = 50*20ms -> tu as 20 milisecondes pour afficher une frames, si c plus long, le flip va devoir attendre 1 vblank de plus, et le fps va baisser dangeureusement ...

heu, sur gp ya pas moyen de vraiment swapper les buffers video? sans les _recopier_ ?
la gp va pas chercher un pointeur a une addresse speciale en mem et afficher a l'ecran ce qui se trouve a l'addresse referencee par le pointeur?

Si j'ai bien lu, c'est apres qu'il attend, pas avant.
sBibi: Va lire le code.

grumf...

heu oue et?
il le recopie la le buffer nan?

y a pas d'autre moyen de le faire?

desole pour le... hem... temps de reponse, mais mon maitre de stage c pointe et plante derriere moi alors que gt en train de regarder la source
"- ckoi ca?"
"- heuuuuuu... c une routine de recopie de buffer <menteur>en asm PPC pour pouvoir accelerer ce putain de CopyBits de macos qui fait ramer mon video digitizer </menteur>"

ahem...

PpHd> si j'ai bien lu aussi, c'est apres qu'il attend oue... et il attend deux trucs visiblement...
le refresh se fait en deux fois?

edit:
r0v43v> si l'ecran est a 50Hz, tout ce qui tournera a un frame rate constant meme legerement en dessous de 50 fps, sera limite a 25 fps maximum, et ne pourra pas passer au dessus, a moins d'avoir un fps >= 50 ou non constant...

-

-

sBibi -> alors c pas des Hz lol mais des frames, il en affiche 50/sec donc on a ~20ms par frame ^^
Orion -> ptet ca affiche en TVS

Orion_ :
j'avait soupçonner le SDK de gamepark trés lent, mais la c'est carement l'arnaque.
j'imagine même pas si on rajoute une surcouche SDL ou GDL qui utilise le SDK par dessus comment ça peut etre lent

c pas si lent que sa ac gdl, les images sont découpées au minimum et le transbitblt est utilisé le moins souvent possible ^^
sdl lui utilise des fct de blit en asm... ^^

"sBibi -> alors c pas des Hz lol mais des frames, il en affiche 50/sec donc on a ~20ms par frame ^^"

heu tu sais ce que ca veut dire Hz? on dirait pas

Orion_ :
j'ai commencer a apprendre l'asm arm mais bon d'ici a ce que je reprogramme MyTransBlt en asm y'a du boulot

Salut je recherche des docs ou des tutos sur l'assembleur arm mais le web en est plutôt avare, qu'utilises-tu comme documentation pour l'apprendre ?

Merci d'avance

non, la je c plus ce que c, les cours sont tres loin lol :-)

google mon ami
Hertz
Le Hertz signifie "fois par seconde", example: l'electricité en france est du 240V 50 Hz, ca veux dire que l'electricité de EDF, passe de 240V à -240V, 50 fois par seconde.

sachant que l'ecran de la gp est fait pour afficher 50 images/sec ca me parais corect de dire qu'il est a 50Hz

sBibi
r0v43v> si l'ecran est a 50Hz, tout ce qui tournera a un frame rate constant meme legerement en dessous de 50 fps, sera limite a 25 fps maximum, et ne pourra pas passer au dessus, a moins d'avoir un fps >= 50 ou non constant...

en fait j'avais pas tt compris a ton post tt a l'heure.
ué c le cas, il y a plusieurs 'palier' de fps possible : 50~53 (c le max) 45~46 (si on utilise un GpRectFill sur tout l'ecran), ~33, ~20, ~16

tout va dependre du temps que dure une frame, si le temp est < 20ms ca sera affiché a 50~53fps.

tout va dependre du temps que dure une frame, si le temp est < 20ms ca sera affiché a 50~53fps.

oui, et si le temps est > 20ms, le fps sautera de 50 a 25, et pourra pas monter au dessus de 25 tant qu'une frame ne mettra pas 20ms ou moins a se calculer...

montybots
:

Orion_ :
j'ai commencer a apprendre l'asm arm mais bon d'ici a ce que je reprogramme MyTransBlt en asm y'a du boulot

Salut je recherche des docs ou des tutos sur l'assembleur arm mais le web en est plutôt avare, qu'utilises-tu comme documentation pour l'apprendre ?

Merci d'avance

va sur le site de mr.spiv

Si tu veux de la doc sur l'asm arm, va donc la chercher à la source http://www.arm.com

Merci

hehe bon code vieux