Discussion :

[KevinduC]

Bonjour, je suis en ce moment entrain de développer un simulateur d'orages, et je cherche à modéliser également des tornades, au moyen d'un générateur de particules. Il n'y a pas moins de 100000 particules (Représentées par des triangles équilatéraux) ; pour les modéliser, pas de problème avec les Vertex Arrays ; mais pour les animer, c'est autrechose : Je compte faire pivoter les particules, mais je n'ai d'autre choix que de réaliser cela vertex par vertex dans une boucle pendant le rendu, j'ai essayé cete solution et bien entendu, le rendu est devenu plus lent qu'une tortue.
Mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
void InitTornade(Principale *ptr)
{
    int compteurPart=0;
    int compteurBoucle=0;
    float X,Y,Z;
    float rayonMax,A,htPart,rayon;
    const float largPart=1;           //Longueur côtés triangle équilatéral
    const float htTri=largPart*sin(60*M_PI/180);		//Calcul hauteur triangle
    double angle;
    const int nbToursBoucle=NB_PARTICULES_TORNADE;
 
    ptr->La_meteo.tornade.positionInit[0]=1000;//myRand(0,TAILLE_MAP/2);		//Position initiale de la tornade
    /*if(rand()%2==1)
        ptr->La_meteo.tornade.positionInit[0]*=-1;*/
 
    ptr->La_meteo.tornade.positionInit[1]=0;//myRand(0,TAILLE_MAP/2);
    if(rand()%2==1)
        ptr->La_meteo.tornade.positionInit[1]*=-1;
 
    ptr->La_meteo.tornade.hauteur=myRand(800,1000);			//Calcul caractéristiques tornade
    ptr->La_meteo.tornade.largBase=myRand(40,80);
    ptr->La_meteo.tornade.largHaut=myRand(500,1000);
    ptr->La_meteo.tornade.dureeDeVie=myRand(10,120);
 
    A=(ptr->La_meteo.tornade.largHaut-ptr->La_meteo.tornade.largBase)/pow(ptr->La_meteo.tornade.hauteur,2);
 
    while(1)
    {
        Z=((float)compteurBoucle/nbToursBoucle)*ptr->La_meteo.tornade.hauteur;		//Hauteur particule
 
        htPart=Z;
 
        rayonMax=A*pow(htPart,2)+ptr->La_meteo.tornade.largBase;		//Fonction du second degré permettant d'avoir une forme d'entonnoir
 
        rayon=myRand(0.9*rayonMax,rayonMax);		//Coordonnées polaires particule
        angle=(double)(rand()%360);
 
        X=rayon*cos(angle*M_PI/180);		//Coordonnées cartésiennes particule
        Y=rayon*sin(angle*M_PI/180);
 
        ptr->La_meteo.tornade.particules[compteurPart]=X;					//Calcul des coordonnées de chacun des trois vertices
        ptr->La_meteo.tornade.particules[compteurPart+1]=Y;
        ptr->La_meteo.tornade.particules[compteurPart+2]=Z+(2.0/3)*htTri;
 
        ptr->La_meteo.tornade.particules[compteurPart+3]=X-(largPart/2)*sin(angle*M_PI/180);
        ptr->La_meteo.tornade.particules[compteurPart+4]=Y+(largPart/2)*cos(angle*M_PI/180);
        ptr->La_meteo.tornade.particules[compteurPart+5]=Z-htTri/3;
 
        ptr->La_meteo.tornade.particules[compteurPart+6]=X+(largPart/2)*sin(angle*M_PI/180);
        ptr->La_meteo.tornade.particules[compteurPart+7]=Y-(largPart/2)*cos(angle*M_PI/180);
        ptr->La_meteo.tornade.particules[compteurPart+8]=Z-htTri/3;
 
        ///////////////////////////////////////////////////////////////////////////////////////////////
 
        ptr->La_meteo.tornade.couleurs[compteurPart]=0.3;			//Couleur gris foncé
        ptr->La_meteo.tornade.couleurs[compteurPart+1]=0.3;
        ptr->La_meteo.tornade.couleurs[compteurPart+2]=0.3;
 
        ptr->La_meteo.tornade.couleurs[compteurPart+3]=0.3;
        ptr->La_meteo.tornade.couleurs[compteurPart+4]=0.3;
        ptr->La_meteo.tornade.couleurs[compteurPart+5]=0.3;
 
        ptr->La_meteo.tornade.couleurs[compteurPart+6]=0.3;
        ptr->La_meteo.tornade.couleurs[compteurPart+7]=0.3;
        ptr->La_meteo.tornade.couleurs[compteurPart+8]=0.3;
 
        compteurBoucle++;
        compteurPart+=9;
 
        if(compteurPart==9*NB_PARTICULES_TORNADE)
            break;
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void animTornade(Tornade *tornade)
{
    int compteurPart=0;
 
    while(1)		//Calcul nouvelles coordonnées après rotation (Très long !!!)
    {
        matriceRotation(&tornade->particules[compteurPart],&tornade->particules[compteurPart+1],&tornade->particules[compteurPart+2],tornade->vitesseRotation,AXE_Z);
        matriceRotation(&tornade->particules[compteurPart+3],&tornade->particules[compteurPart+4],&tornade->particules[compteurPart+5],tornade->vitesseRotation,AXE_Z);
        matriceRotation(&tornade->particules[compteurPart+6],&tornade->particules[compteurPart+7],&tornade->particules[compteurPart+8],tornade->vitesseRotation,AXE_Z);
 
        compteurPart+=9;
        if(compteurPart==9*NB_PARTICULES_TORNADE)
            break;
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void tornade(Principale *ptr)
{
    glDisable(GL_TEXTURE_2D);
 
    glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_COLOR_ARRAY);
 
    glVertexPointer(3,GL_FLOAT,3*sizeof(float),ptr->La_meteo.tornade.particules);
    glColorPointer(3,GL_FLOAT,3*sizeof(float),ptr->La_meteo.tornade.couleurs);
 
    glPushMatrix();
    glTranslated(ptr->La_meteo.tornade.positionInit[0],ptr->La_meteo.tornade.positionInit[1],0);
    glDrawArrays(GL_TRIANGLES,0,3*NB_PARTICULES_TORNADE);		//Dessin particules
    glPopMatrix();
 
    glEnable(GL_TEXTURE_2D);
 
    animTornade(&ptr->La_meteo.tornade);
}

Une solution consisterait à se contenter d'un glRotated(), mais je souhaite faire pivoter les particules dans la tornade et non faire pivoter la tornade sur elle-même si vous voyez ce que le veux dire.
Auriez-vous une solution pour animer 100000 particules de manière fluide ?

[Kannagi]

On te le répétera autant de fois , OpenGL 1 est lent , n’espère pas faire mieux avec !

Pour les 100 000 particules c'est normal (si c'est des triangles ça fait donc 300 000 vertex) , je t'ai deja dit que sans instruction SIMD , tu es plus lent qu'une Dreamcast/PS2/Game Cube /XBOX
(c'est juste pour que tu te rend compte que en faisant en FPU ça sera super long , sans thread , sans instruction SSE n’espère pas grand chose sans optimisation de fou avec des petites données...).

Si tu veux absolument le faire en software (ou par curiosité savoir si c'est possible ) alors faudra repenser ton code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
while(1)		//Calcul nouvelles coordonnées après rotation (Très long !!!)
    {
        matriceRotation(&tornade->particules[compteurPart],&tornade->particules[compteurPart+1],&tornade->particules[compteurPart+2],tornade->vitesseRotation,AXE_Z);
        matriceRotation(&tornade->particules[compteurPart+3],&tornade->particules[compteurPart+4],&tornade->particules[compteurPart+5],tornade->vitesseRotation,AXE_Z);
        matriceRotation(&tornade->particules[compteurPart+6],&tornade->particules[compteurPart+7],&tornade->particules[compteurPart+8],tornade->vitesseRotation,AXE_Z);
 
        compteurPart+=9;
        if(compteurPart==9*NB_PARTICULES_TORNADE)
            break;
    }

Sur du code critique , jamais d'appel de fonction , et encore moins avec des arguments de ce type ...
Si tu veux faire des calculs de matrices , utilise les libs spécifique pour les instructions SSE ou code les en asm !
Éviter les structures complexes (a la limite utiliser des pointeurs qui pointe sur les données qu'on travaille).
Le calcul de matrice doit lui être le plus minimum possible (le plus possible serait Load , multiplication de matrice , Store).

Ou utilise OpenGL 2,3 ou 4 est tu fait un vertex shader , plus simple et plus performant :p
Ta carte graphique a une puissance de GFLOPS largement plus grande que celui de ton CPU ,par comparaison un CPU en utilisant le FPU avec 2 GHZ ben tu as 2 GFLOPS au mieux ! (je parle ici d'un programme qui utilise un 'coeur' de la machine).
Une bonne CG fait entre 1000 et 2000 GFLOPS (les meilleurs du marché monte a plus de 10 000 GFLOPS !).

NT: glRotated() est une fonction très lente et pas forcément la plus optimisé , comparé a ce que tu pourrais croire c'est une fonction qui est faite en software en utilisant le fpu.

[KevinduC]

OpenGL 1 est lent certes mais je ne lui demande pas grand-chose tout de même comparé à ce qu'une carte graphique sait faire, avant l'apparition de la deuxième version on avait bien des jeux et simulateurs devant afficher plusieurs centaines de milliers de vertices.

De toute façon le problème n'est pas dans le rendu mais dans le traitement des données.

Sur du code critique , jamais d'appel de fonction , et encore moins avec des arguments de ce type ....

C'est-à-dire ? Comment ça pas d'appel de fontion ?
Tu peux m'expliquer ce qu'est une instruction SIMD ?

[Kannagi]

Alors OpenGL 1 n'exploite pas les GPU donc oui tu lui demande pas grand chose mais le GPU n'est pas exploité je suis même pas sur que les calculs de perspective soit fait coté GPU pour dire !
De plus ce que tu demande n'a rien n'a voir avec la OpenGL ou ta CG tu demande explicitement une optimisation coté CPU , CPU qui est pas fait pour ce genre de calcul !

deuxième version on avait bien des jeux et simulateurs devant afficher plusieurs centaines de milliers de vertices.

Oui parce que les calculs dans la version 2 peut se faire du coter de la CG ,si j'ai donner des chiffres c'est que sans connaissance pointu on devine que 2 c'est plus petit que 1000 même voir 100 (si on vient a de vielle carte graphique).

De toute façon le problème n'est pas dans le rendu mais dans le traitement des données.

Exact et je t'ai expliquer quel était le souci , et que le vertex shader (voir le geometrie shader) peut être une solution.

C'est-à-dire ? Comment ça pas d'appel de fontion ?
Tu peux m'expliquer ce qu'est une instruction SIMD ?

Un appel de fonction c'est lent , entre le push , pop ,le call et le ret , les arguments et la pile, faut mieux s'en passer , de plus les structures complexes oblige au compilo de faire une multitude d'addition pour avoir la bonne valeur.

Il y'a des libs qui exploite les instructions vectoriels de ton CPU , ton CPU peut faire en quelque instruction des calculs matriciels , ces instructions sont ce qu'on appelle des instruction SIMD (donc que tu peux esperer en 1 cycle fait 4 multiplication ou 4 addition) sur d'autre plateforme que le x86 tu peux esperer même faire 4 multiplication et 4 addition en 1 cycle.

[KevinduC]

Je crois que c'est plus clair : Tu me suggères d'utiliser également OpenGL pour le traitement des données, chose que la version 1 ne peut pas faire. Je me trompe ?

OpenGL 1 n'exploite pas les GPU

Euh comment ça ??? Quand je fais glDrawArrays() il se passe quoi alors ?

[Kannagi]

Ben t'es 100 000 particules tu comptes les afficher non ?

Donc tu pourra faire ceci niveau GPU :
-vertex shader permet de faire des calculs sur chaque vertex
-fragment shader qui permet de faire un calcul sur pixel
-geometrie shader permet de créer de nouvelle géométrie

Euh comment ça ??? Quand je fais glDrawArrays() il se passe quoi alors ?

Ben tu envoie au GPU toutes tes donnés , ensuite il les affichent mais techniquement il ne fait pas les calculs de perspectives (on gros pas de 3D).

Donc tu n'exploite pas ta CG , parce que tout les calculs de perspective ou de 3D sont fait coté CPU (alors que le GPU pendant ce temps là ne fait rien donc tu ne l'exploite pas ) ce qui est bête parce que le CPU est très lent pour ce genre de calcul alors que le GPU lui est parfait pour faire des calculs.
Et de nos jours on peut stocker les vertex dans la CG est donc éviter les envoies sur celle ci !
Et que tu ne fait aucun calcul coté GPU comme je l'ai dit.

Donc au mieux ton GPU ne sert dans OpenGL 1 que de Fillrate :p

[dragonjoker59]

Pour te donner une idée, voilà une capture depuis mon moteur 3D (pas super optimisé), sur lequel je calcule les particules via un compute shader :



Là il n'y a que 500'000 particules, simples c'est vrai, affichées en tant que quads, avec 2 textures (opacité + couleur).
Mon moteur n'étant super optimisé, ça ne tourne qu'à 90 FPS, mais de nos jours, on utilise les compute shaders, pour les particules (avec SSBO et atomic counters).

[LittleWhite]

Bonjour,

Je pense que l'on devrait y arriver, 100 000 particules en OpenGL 1.1. Certes, OpenGL 1.1 n'est pas la panacé et on ne peut pas utiliser des techniques avancées pour faire les choses optimisées, mais la puissance brute d'un GPU devrait nous permettre d'y arriver.
J'avoue qu'avec un geometry shader (OpenGL 3) pour transformer un point en quad, ça irait bien plus vite, car moins de donner à transférer au GPU. Avec DirectX 11 (et surement OpenGL 3.2) on peut faire des particules 100 % sur le GPU et ça irait encore mieux. Mais en OpenGL 1, on devrait y arriver (et même sans SIMD, car ça, c'est du ressort du compilateur de générer les bonnes instructions au bon moment ).

Bref, déjà, pourquoi des boucles while(1) Pourquoi pas des boucles for ? (qui seront optimisables, plus facilement, par le compilateur).

Aussi, comme vous avez un souci de performances, pourquoi ne pas utiliser un profileur, pour mieux comprendre là où les performances sont perdues ?
En plus, je vois que vous faites un draw call par particule. Ça, c'est mauvais. Il faudrait faire mieux, mais du coup, comment placer les particules ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
glVertexPointer(3,GL_FLOAT,3*sizeof(float),ptr->La_meteo.tornade.particules);
    glColorPointer(3,GL_FLOAT,3*sizeof(float),ptr->La_meteo.tornade.couleurs);
 
    glPushMatrix();
    glTranslated(ptr->La_meteo.tornade.positionInit[0],ptr->La_meteo.tornade.positionInit[1],0);
    glDrawArrays(GL_TRIANGLES,0,3*NB_PARTICULES_TORNADE);		//Dessin particules
    glPopMatrix();

Ce code me semble faut, sachant le nom de NB_PARTICULES_TORNADES.

Note : OpenGL 1, c'est juste un shader contrôlé par le pilote. Donc y a une partie GPU (le shader fixe qui reproduit le pipeline fixe) et une partie CPU (les PushMatrix et les Translate...). Mais bon, ça c'est souvent le cas. Tant que l'on ne fait pas la multiplication vertex * matrice sur le CPU, c'est déjà bien .

[KevinduC]

je vois que vous faites un draw call par particule

Euh pas vraiment, glDrawArrays() s'occupe de modéliser en une seule fois toutes les particules sous forme de triangles, d'ailleurs :

Ce code me semble faut, sachant le nom de NB_PARTICULES_TORNADES

Je ne vois pas ce qu'il y a de faux, il y a NB_PARTICULES_TORNADES particules donc 3*NB_PARTICULES_TORNADES vertices.
Comme je l'ai dit, le rendu ne pose pas de problème, c'est fluide lorsque je mets la fonction animTornade() en commentaire, le problème vient du fait que les particules sont traitées une à une, mais je ne trouve pas d'autre moyen pour animer ces dernières, c'est là que j'ai besoin d'idées.

[Kannagi]

Même si LittleWhite dit que c'est possible (ce que je n'ai pas prétendu le contraire) .

Mais je dit que les instructions SIMD ne s'active pas par défaut (et le compilo le fait pas forcément automatiquement hein LittleWhite ).
L'option -S fournira le code asm et indiquera la preuve si oui ou non les instructions SIMD sont faite.

Pour faire un calcul rapide pour voir si c'est possible un 2 GHZ fournit 2 GFLOPS , il faut à peu prés 16 multiplication et 16 addition pour faire un matrix*vectex , (et sûrement 8 pour le Load/Store voir plus) sur 60 FPS on à 0.8 millions de vertex (soit 277 000 triangles) , voila bon ça reste quand même chaud , sachant que c'est un chiffre théorique qui ne prend pas compte L'OS et les autres programmes qui tourne en même temps, le calcul du programme (s'il fait autre chose) , la vitesse d'affichage , les transfert sur le GPU , et le 1 cycle/instruction dans le monde idéal , ou il n'y a aucun pipeline stall aucun cache miss
(et surtout pas dans le cas où on appelle une fonction pour chaque vertex , là je préfère même plus compter )

Les instruction SIMD sur x86 c'est théoriquement 4 fois plus rapide en terme de calcul.

[KevinduC]

(et surtout pas dans le cas où on appelle une fonction pour chaque vertex , là je préfère même plus compter )

C'est ça le problème justement ^^, ces instructions SIMD dont tu me parles semblent être la solution.

[dragonjoker59]

La vraie bonne solution, sur GPU moderne, c'est les compute shaders, sinon on utilise le transform feedback, qui sert à ça, et permet d'exécuter un shader (en GPU donc) sans output (donc sans rastérisation, ni fragment shader, par contre les geometry shaders sont possibles, ce qui sert bien, dans le traitement de particules).
Vu ton rendu actuel, ton GPU n'a rien à faire, donne lui du boulot! Ton CPU a d'autres choses plus intéressantes à faire que des bêtes calculs mathématiques de ce genre.

[LittleWhite]

En effet, j'ai mal lu le code.

Je pense que le profileur pourra vous aider à voir la faiblesse de votre code. Peut être vous aurez de meilleure performances avec GLM, peut être pas. Après, la seule solution, c'est de faire plus de calcul sur le GPU et moins sur le CPU, mais en OpenGL 1, je ne vois pas de solution.

[dragonjoker59]

Tu utilises les vertex arrays, tu n'es donc plus en OpenGL 1.X, mais en OpenGL 2.1.
Et en OpenGL 2.1 tu as accès aux shaders.

Si tu n'as pas accès au transform feedback, tu peux toujours effectuer tes calculs dans un fragment shader, stocker le résultat dans une texture, utiliser un PBO pour récupérer ces résultats dans un vertex buffer, que tu utiliseras ensuite comme tu veux...
Mais ça n'a aucun intérêt, autant faire directement ce qu'il faut dans un couple classique vertex/fragment shader, qui fera le boulot plus rapidement, sans copies superflues.

[KevinduC]

Tu peux toujours effectuer tes calculs dans un fragment shader, stocker le résultat dans une texture, utiliser un PBO pour récupérer ces résultats dans un vertex buffer, que tu utiliseras ensuite comme tu veux...
Mais ça n'a aucun intérêt, autant faire directement ce qu'il faut dans un couple classique vertex/fragment shader, qui fera le boulot plus rapidement, sans copies superflues.

Euh d'accord, je vais étudier la question, pour le moment tu me parles en chinois ^^