SDL-openGL latences temporaires

Version imprimable

Bonjour,

Je reprends un programme que j'ai commencé il y a quelques années.

Le problème cité ci-dessous est apparu à mon changement de PC (compilateur, carte mère, graphique, réinstallation windows, ...).

Le problème donc est le suivant : le programme est un doom-like, la navigation dans les menus (restitution openGL) se passent bien, par contre quand j'ouvre une Map l'affichage est très saccadé (en gros une image toutes les secondes) pendant une minute puis il devient fluide.

J'ai mesuré les temps consommés et ceux sont les lignes ci-dessous qui sont incriminées :
Code:

1 2 3 4 5 6 7 8 9 10 11 for( int i=0; i < m_NumFaces ; i++ ) // dessine toutes les faces de la map { glNormal3fv( &m_TabVectNormaux[(9*i)] ); glArrayElement( m_TabFaces[3*i] ); glNormal3fv( &m_TabVectNormaux[(9*i)+3] ); glArrayElement( m_TabFaces[(3*i)+1] ); glNormal3fv( &m_TabVectNormaux[(9*i)+6] ); glArrayElement( m_TabFaces[(3*i)+2] ); }
La valeur de m_NumFaces est fixe (un peu plus de 20000), cette boucle d'affichage prend 700ms à chaque restitution la première minute après l'ouverture de la map, puis après une minute environ elle ne prend plus que 3 à 4 millisecondes sans que rien n'est changé d'autre.

Je sais plus trop par où chercher... mes drivers de carte graphique sont à jour.

Ma config est la suivante :
- Athlon 64 X2 dual core 3800+
- Gigagyte 7600 GT
- carte mère K9N-Platinium
- ram 1Go
- Windows XP Pro SP2

Info supplémentaires

Voici ma procédure d'initialisation SDL dont j'ai enlevé ce qui n'apporte rien pour cette question :

Code:

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
putenv("SDL_VIDEODRIVER=directx");	// A FAIRE A FAIRE A FAIRE : code compatible Linux
 
if( SDL_Init( SDL_INIT_VIDEO|SDL_INIT_TIMER|SDL_INIT_NOPARACHUTE ) < 0 )	// First, initialize SDL's video subsystem
{
	exit( 1 );
}
 
const SDL_VideoInfo* info = SDL_GetVideoInfo( );	// Let's get some video information
if( !info )
{
	exit( 1 );
}
 
bpp = info->vfmt->BitsPerPixel;
 
flags = SDL_OPENGL;
 
if( config.Display.Fullscreen() )
	flags |= SDL_FULLSCREEN ;
 
	// Get available fullscreen/hardware modes
SDL_Rect **modes = SDL_ListModes(NULL, SDL_FULLSCREEN|SDL_HWSURFACE);
 
		// Check if there are any modes available
if( modes == (SDL_Rect **)0 )
{
	exit( 1 );
}
 
if( !SDL_VideoModeOK( config.Display.X, config.Display.Y, bpp, flags ) )
{
	cout << endl << "WARNING : Mode video indisponible =>";
	cout << "mode choisi par defaut, corrigez la configuration" << endl;
	config.Display.X = modes[0]->w;
	config.Display.Y = modes[0]->h;
}
 
screen = SDL_SetVideoMode( config.Display.X, config.Display.Y, bpp, flags );	// Set the video mode
if(  screen == 0 )	
{    
	exit( 1 );
}
 
char txt1[50];
cout << "\nDriver video :\t\t";
if( SDL_VideoDriverName( txt1, 50 ) )
	cout << txt1;
 
cout << "\nVideo memory :\t\t" << info->video_mem/1024 << " Mo" << endl;

Et voici mon initialisation openGL :

Code:

1
2
3
4
5
6
7
8
9
int width = config.Display.X, height = config.Display.Y;
cout << "Version openGL :\t" << glGetString( GL_VERSION );
cout << "\nVersion GLU :\t\t" << gluGetString( GLU_VERSION );
 
glClearColor( 0.0f, 0.0f, 0.0f, 0.0f );	// Vide le tampon chromatique
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
glShadeModel( GL_SMOOTH );	// Mode dégradé pour le remplissage des polynomes
glPixelStorei( GL_UNPACK_ALIGNMENT, 1 );
glViewport( 0, 0, width, height );

Voici le code de l'affichage :

Code:

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
glEnableClientState( GL_VERTEX_ARRAY );
glVertexPointer( 3, GL_FLOAT, 0, m_TabVertex );
glDisable(GL_TEXTURE_2D);
 
	// Marquage de la lumière dans la scène par une boule
glPushMatrix();
glTranslatef( fff[0], fff[1], fff[2] );	// Positionnement de la lumière
glDisable( GL_LIGHTING );
glColor3f( 0.0f, 1.0f, 1.0f );
gluSphere( gluNewQuadric(), 0.05, 64, 64 );
glPopMatrix();
 
glEnable( GL_LIGHTING );
glEnable(GL_LIGHT0);	// Activation de la lumière
 
	// Paramétrage de la lumière
glLightfv( m_refLight, GL_POSITION, fff );
glLightfv( m_refLight, GL_AMBIENT, m_ColorAmbient );
glLightfv( m_refLight, GL_DIFFUSE, m_ColorDiffuse );
glLightfv( m_refLight, GL_SPECULAR, m_ColorSpecular );
 
	// Définition du materiau
glMaterialfv( GL_FRONT_AND_BACK, GL_AMBIENT, m_Ambient );
glMaterialfv( GL_FRONT_AND_BACK, GL_DIFFUSE, m_Diffuse );
glMaterialfv( GL_FRONT_AND_BACK, GL_SPECULAR, m_Specular );
glMaterialf( GL_FRONT_AND_BACK, GL_SHININESS, 50.0f );
 
glBegin(GL_TRIANGLES);
 
initTemps();	// Calcul du temps consommé, initialisation du chrono
 
for( int i=0; i < m_NumFaces ; i++ )	// dessine toutes les faces de la map
{
	glNormal3fv( &m_TabVectNormaux[(9*i)] );
	glArrayElement( m_TabFaces[3*i] );
 
	glNormal3fv( &m_TabVectNormaux[(9*i)+3] );
	glArrayElement( m_TabFaces[(3*i)+1] );
 
	glNormal3fv( &m_TabVectNormaux[(9*i)+6] );
	glArrayElement( m_TabFaces[(3*i)+2] );
}
 
setTemps(m_Nom);	// Calcul du temps consommé, relevé du chrono
 
glEnd();
 
glDisable( GL_VERTEX_ARRAY );

16/01/2007, 01h58
theidiot

La seule hypothèse est probablement l'utilisation de la fonction
glNormal3fv et glArrayElement qui sont rendu totalement obsolet avec les cartes graphique actuelle.

Utiliser plutot les VBO et la fonction "glDrawArrays" ou "glDrawElements" , tu gagnera beaucoup plus en performence.;)
16/01/2007, 09h47
Sivrît

L'évolution des performances dans le temps est quand même étrange. Est-ce que cela pourrait venir de driver récents qui privilégient les VBO & co et torpillent les "vieilleries" comme glNormal3fv ? Et au bout d'un certain temps ils s'apperçoivent que l'application n'a pas le profil attendu et revoient leur façon de faire... c'est tordu comme explication :?
16/01/2007, 13h02
bafman

tu verifie que tu n'a pas d'erreur opengl (avec glintercept par exemple) ?
ton problème peut très bien venir d'une erreur qui passait sur des anciens drivers mais qui est reperée par les plus recents...
16/01/2007, 21h32
Erwin

C'est un projet que je reprends, je ne savais pas qu'il y avait de nouvelles fonctions j'en étais resté naïvement à OpenGL 1.2. Merci pour ces info je vais voir si ça règle mon problème.

Concernant les erreurs je les check avec glGetError qui ne m'en remonte pas. Mais même remarque que ci-dessus pour glintercept, je vais mettre ça dans mon code.

Ca marche :), mais...

Ca marche maintenant avec glDrawElements, c'est à dire qu'il n'y a plus de période saccadée. Par contre je n'avais jamais pu utiliser glDrawElements (qui n'est pas une fonction nouvelle d'ailleurs) avant car mes vertex sont indexés, mes sommets de textures mais pas mes vecteurs normaux. D'où la boucle for que j'avais dans mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 for( int i=0; i < m_NumFaces ; i++ ) // dessine toutes les faces de la map { glNormal3fv( &m_TabVectNormaux[(9*i)] ); glArrayElement( m_TabFaces[3*i] ); glNormal3fv( &m_TabVectNormaux[(9*i)+3] ); glArrayElement( m_TabFaces[(3*i)+1] ); glNormal3fv( &m_TabVectNormaux[(9*i)+6] ); glArrayElement( m_TabFaces[(3*i)+2] ); }
où je donne chaque fois l'index pour les vertex et les tvertex mais où je spécifie explicitement le vecteur lui-même pour les normales.

La seule solution que je vois est d'indexer mon tableau de normales mais si quelqu'un connait une autre solution je suis prenneur. Celle-ci étant compliquée à mettre en oeuvre. Je préférerais conserver l'indexation des vertex et tvertex sans celle des normales.

Merci en tout cas pour la solution à mon problème premier.

17/01/2007, 00h03
theidiot

Citation:

La seule solution que je vois est d'indexer mon tableau de normales mais si quelqu'un connait une autre solution je suis prenneur.

Non tu ne peut pas donner une indexation propre à chaque tableau different dans un même appelle avec glDrawArray ou glDrawElement. La seule solution est d'associer un vecteur de normal pour chaque vecteur de position.
17/01/2007, 01h13
theidiot

Citation:

Envoyé par Sivrît

L'évolution des performances dans le temps est quand même étrange. Est-ce que cela pourrait venir de driver récents qui privilégient les VBO & co et torpillent les "vieilleries" comme glNormal3fv ? Et au bout d'un certain temps ils s'apperçoivent que l'application n'a pas le profil attendu et revoient leur façon de faire... c'est tordu comme explication :?

Hmm... je ne pense pas qu'il faut expliquer le fonctionnement de certain driver graphique de cette manière. Je me rappelle que quelqu'un avait de la difficulté à intégrer son picking parce qu'il utilisait les VBO et testait son application sur des cartes différentes (de niveau différent). Cela marchait parfaitement sur certaine carte mais sur d'autre pas du tout.

En faite, le domaine la conception des drivers graphique ainsi que la carte elle-même (je parle de leur technologie propre et leur particularité ) sont des savoirs qui sont réserver à leur concepteur. Secret industriel. :roll:
17/01/2007, 10h12
shenron666

je ne suis pas d'accord, je pense comme Sivrît que les drivers ne sont plus optimisés pour recevoir des centaines de glVertex et autres, tout est fait pour utiliser des batchs ou mieux des (vertex) buffer object

à la limite, c'est peut-etre une mise en cache que le driver fait après un certain temps qui améliore les perfs, mais là dessus difficile d'en être sûr, les drivers c'est secret industriel comme le dit theidiot ;)
17/01/2007, 11h29
bafman

Citation:

Envoyé par shenron666

je ne suis pas d'accord, je pense comme Sivrît que les drivers ne sont plus optimisés pour recevoir des centaines de glVertex et autres, tout est fait pour utiliser des batchs ou mieux des (vertex) buffer object

à la limite, c'est peut-etre une mise en cache que le driver fait après un certain temps qui améliore les perfs, mais là dessus difficile d'en être sûr, les drivers c'est secret industriel comme le dit theidiot ;)

en fait il faut plutot voir le problème dans l'autre sens :
l'optimisation de flux de vertex arbitraire (glBegin/glEnd) est tellement complexe (voir impossible etant donnée qu'on ne peut pas faire de prediction de la taille du flux et autre) qu'ils ont crée les batch/VBO qui permettent des optimisation plus faciles ;)
17/01/2007, 14h39
shenron666

c'est pas faux
en même temps, les batchs réduisent considérablement les appels de fonction et donc la dépendance CPU
ça permet également d'avoir la géométrie sur la carte ce qui réduit les transferts sur le port graphique (PCI, AGP, PCIe, ...) au strict minimum : paramétrage de la machine à états et appel du batch