Compiler avec GCC sur Sam440 :Comment optimiser?
-
K-L : Pas faux !
Donc au final 0% sur les tâches prévues mais c’est pas grave, la problématique exposée ici est plus qu’intéressante.
Le 440 supporte bien le prefetch et il y a quelques réglages dans le Core Configuration Register CCR0.
thellier : Après avoir réfléchi et expérimenté à nouveau, tant bien que mal (malheureusement, j’ai peur que des photos où je suis en train de « réfléchir » circulent sur Internet), sur le MicroAOne, j’obtiens 13 fps au lieu de 10, et je descends à 50% de temps passé dans Wazp3D, avec 240 hits, dont 52 dans la fonction PixelsOut16.
On essaie sur la Sam440, 6 fps sans option spéciale … et ma version modifiée semble ne pas fonctionner
thellier: Je peux t’envoyer ma fonction modifiée si tu veux.
Sinon, pour les hits, j’utilise Hieronymus … mon profiler
mais malheureusement il ne fonctionne toujours pas sur Sam440.Ton exemple est hyper intéressant et quelque part, ça valide un peu plus Hieronymus. Après ma modif, j’obtiens :
Percent | Program
12 | SYS:Kickstart/newlib.library.kmod
4 | SYS:Kickstart/timer.device.kmod
65 | LIBS:Warp3D.library
3 | SYS:Kickstart/rtg.library
6 | SYS:Kickstart/kernel
6 | Cow3D-Amiga-ppc
1 | SYS:Kickstart/ATIRadeon.chip
1 | LIBS:Picasso96/emulation.library
0 | LIBS:bsdsocket.library
0 | SYS:Kickstart/graphics.library.kmod
count = 0312, percent = 65, name = LIBS:Warp3D.library
Offset = 0x000540c8, Count = 0002, Function =
Offset = 0x000083c8, Count = 0073, Function = PixelsOut16
Offset = 0x0004bec8, Count = 0026, Function = GetVertex
Offset = 0x00020a74, Count = 0019, Function = Fill_Tex
Offset = 0x000467c0, Count = 0017, Function = Edge_Tex
Offset = 0x00044d5c, Count = 0001, Function = ZbufferCheck
Offset = 0x00045a28, Count = 0011, Function = DrawPolyPix
Offset = 0x00044a34, Count = 0040, Function = SOFT3D_ClearZBuffer
Offset = 0x0000762c, Count = 0034, Function = Ztest_zless_update
Offset = 0x00045510, Count = 0002, Function = PrintPix
Offset = 0x000460dc, Count = 0010, Function = Poly_Persp0_Tex
Offset = 0x00050b9c, Count = 0017, Function = DrawPolyP
Offset = 0x00007644, Count = 0005, Function = Ztest_zgequal_update
Offset = 0x00017aa0, Count = 0009, Function = PixelsTex32ToBuffer
Offset = 0x0000e894, Count = 0001, Function = PrintError
Offset = 0x0004f3c4, Count = 0009, Function = ClipPoly
Offset = 0x0001ab08, Count = 0006, Function = SOFT3D_Flush
Offset = 0x00020fa8, Count = 0010, Function = SetTexStates
Offset = 0x00052c34, Count = 0003, Function = DrawPrimitive
Offset = 0x00051c70, Count = 0010, Function = SOFT3D_DrawPrimitive
Offset = 0x00053f24, Count = 0001, Function = W3D_DrawPoint
Offset = 0x00008408, Count = 0001, Function = PixelsIn8
Offset = 0x000127dc, Count = 0002, Function = SelectMipMap
Offset = 0x00053ebc, Count = 0001, Function = W3D_DrawTriangle
Offset = 0x0001e9f0, Count = 0001, Function = SetDrawFunctions
Offset = 0x00004d94, Count = 0001, Function = LibW3D_DrawTriangle
Donc il semble qu’on passe 2 fois moins de temps dans PixelsOut16 mais que du fait qu’on mette un peu moins de pression sur cette fonction … d’autres fonctions en profitent ! La charge se répartit au sein de l’appli mais elle reste à bloc.
Une autre fonction à regarder pourrait être ClearZBuffer … A ce propos, si le zbuffer n’utilise pas les float, alors MAXZ défini à 0.99999, converti en USHORT … je pense que ça va écrire des zéros.
Si dans ClearZBuffer, on peut tout mettre à zéro, alors le PPC peut bénéficier de l’instruction de clear de cache. Je ne sais pas si c’est vraiment conseillé mais bon … (et il faut faire attention, la taille d’une ligne de cache est usuellement 32 octets, mais 64 sur X1000 et 128 sur G5 je crois).
Il y a aussi une astuce qui permet d’avoir à vider le ZBuffer d’une frame à l’autre … Sur AmigaOS4 cela m’a permis de grandement améliorer le frame Rate de l’AmiDARK Engine
@ +
AmiDARK
Salut Alain,
En fait tu travailles par quart de buffer.
Et tu modifies le test > ou < en conséquence. Voila ma fonction qui gère le schmilblik sous AmiDARK Engine :
void UpdateZTrickMode( int ZTrickADD ){glEnable( GL_DEPTH_TEST );
glDepthMask( GL_TRUE );
// Mode 0 = Aucune optimisation de gestion du ZBuffer.
if ( Core.ZTrick == 0 ){
if ( ZTrickADD != 0 ){ glClear( GL_DEPTH_BUFFER_BIT ); }
glDepthRange( (GLclampd)0.0f, (GLclampd)1.0f );
glDepthFunc( GL_LEQUAL );
}else{
// Mode 1 = Optimisation du ZBuffer par cadrans de 1/4 du buffer total
Core.ZFrameID = Core.ZFrameID + ZTrickADD;
switch( Core.ZFrameID ){
case 1:
glDepthRange( (GLclampd)0.5, (GLclampd)0.75 );
glDepthFunc( GL_LEQUAL ); // Default mode less or equal
break;
case 2:
glDepthRange( (GLclampd)0.25, (GLclampd)0.5 );
glDepthFunc( GL_LEQUAL ); // Default mode less or equal
break;
case 3:
glDepthRange( (GLclampd)0.0, (GLclampd)0.25 );
glDepthFunc( GL_LEQUAL ); // Default mode less or equal
break;
case 4:
glDepthRange( (GLclampd)0.5, (GLclampd)0.25 );
glDepthFunc( GL_GEQUAL );
break;
case 5:
glDepthRange( (GLclampd)0.75, (GLclampd)0.5 );
glDepthFunc( GL_GEQUAL );
break;
case 6:
glDepthRange( (GLclampd)1.0, (GLclampd)0.75 );
glDepthFunc( GL_GEQUAL );
Core.ZFrameID = 0;
break;
case 7:
glClear( GL_DEPTH_BUFFER_BIT );
glDepthFunc( GL_GEQUAL );
glDepthRange( (GLclampd)1.0, (GLclampd)0.75 );
Core.ZFrameID = 0;
default:
break;
}
}
}
Cela permet d’utiliser le ZBuffer sans l’effacer et sans avoir aucun problème.
Si tu as besoin de plus d’explications sur le principe, n’hésite pas à demander
Si tu as besoin de plus de précisions, tu peux travailler en 1/2 de buffer total au lieu de 1/4
@ +
AmiDARK
En fait, c’est pire, je ne le vide jamais…
Je le vide à l’initialisation pour être sûr que tout soit à 0
puis :
7 = Initialisation du ZBuffer.
La commande système qui initialise l’activation du ZTrick active le ZFrameID = 6 (résultat, au 1er appel il passe à 7 et initialise le ZBuffer en le vidant). Puis ça le mets à 0 (compteur qui sera automatiquement à 1 à la prochaine boucle via Core.ZFrameID = Core.ZFrameID + ZTrickAdd )
Puis ça boucle entre 1 à 6:
1. de 0.50 à 0.75 ( 0.50 = proche, 0.75 = loin ) GL_LEQUAL : Less or Equal
2. de 0.25 à 0.50 ( 0.25 = proche, 0.50 = loin ) GL_LEQUAL : Less or Equal
3. de 0.00 à 0.25 ( 0.00 = proche, 0.25 = loin ) GL_LEQUAL : Less or Equal
4. de 0.50 à 0.25 ( 0.50 = proche, 0.25 = loin ) GL_GEQUAL : Greater or Equal
5. de 0.75 à 0.50 ( 0.75 = proche, 0.50 = loin ) GL_GEQUAL : greater or Equal
6. de 1.00 à 0.75 ( 1.00 = proche, 0.75 = loin ) GL_GEQUAL : Greater or Equal + Remise à 0 du pointeur de ZFrameID (compteur qui sera automatiquement à 1 à la prochaine boucle via Core.ZFrameID = Core.ZFrameID + ZTrickAdd )
Donc, j’utilise le ZBuffer dans les 2 sens … Résultat, aucun besoin de le vider. Les valeurs de la gestion précédente étant toujours en dehors du nouveau RANGE et considérée comme distances + loin que la maxi de la nouvelle frame … Aucun besoin de le vider :p
Voila
Maintenant, cette idée ne vient pas de moi … je crois que c’est Corto qui m’en avait parlé (enfin, du principe) et on avait vu ensemble pour optimiser cela :p
@ +
AmiDARK
thellier : Un aperçu de la désormais fameuse vache tournante le week-end dernier
@Thellier : Ok.
Interessant effectivement.
Sinon, j’ai du mal à voir sur les photos et avec le shot que tu as mis en lien.
La vache est un objet 3D ou une texture plaquée (genre un objet 3D plain) ?
PS : Ca m’intéresserait de voir le code source si il est prévu qu’il soit public
@ +
AmiDARK
- Vous devez être connecté pour répondre à ce sujet.
