Problème de perf.

Version imprimable

Problème de perf.

Bonjour à tous,

Je me suis mis à tester un truc bête comme chou dans mon programme opengl : afficher 10000 quad coloré par frame . Je les affichent simplement au même endroit, pour vérifier si ca passait et la je passe de 5000 fps à 5.
Je sais que 5000 n'est aps représentatif de grand-chose mais bon quand même ...

J'affiche mes fps à 5000, comme à 5 à l'aide d'une simple fonction en bitmap font. ( Je passe a 2000 et à 5 avec un std::cout , donc le problème ne vient pas de ma fonction d'affichage de texte je pense.

Mon affichage :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	for (int i = 0 ; i < 10000 ; i++ )
	{
		glBegin(GL_QUADS);
 
			glColor4f(1.0, 0.0, 0.0, 1.0);
 
			glVertex3f(0.0, 0.0, 0.0);
			glVertex3f(0.0, 1.0, 0.0);
			glVertex3f(1.0, 1.0, 0.0);
			glVertex3f(1.0, 0.0, 0.0);
 
		glEnd();
	}

Je possède 4 go de ram, une ati 4870 en 1go et un core duo a 3.1, je pense que mon pc dit pouvoir gérer 10k+ de poly sans trop de problème :)

Je n'ai rein d'autre qui tourne qui pourrait justifier ce ralentissement dans mon prog. L'écrat entre 1 quad et 1 print et 10k quad et 1 print me parait vraiment trop important .

J'ai oublié d'activer une option quelquonque?

1 quad = 5k fps
10 quad = 3k fps
100 quad = 500 fps
1000 quad = 60 fps
10k quad = 5 fps

Pour fino, voici ma fonction d'init opengl

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
 
	if ( SDL_InitSubSystem(SDL_INIT_VIDEO)== -1 )
	{
		std::cout << "SDL_VIDEO have failed on initialisation" << std::endl ;
	}
 
	std::string WindowsName = "Demo openGL" ;     
	bool FullScreen = Application::Instance().m_Settings.m_FullScreen ;
	unsigned int ColorBits = Application::Instance().m_Settings.m_ColorBits ;
	unsigned int ScreenWidth = Application::Instance().m_Settings.m_ScreenWidth ;
	unsigned int ScreenHeight = Application::Instance().m_Settings.m_ScreenHeight ;
 
	// Setting up some parameters
	SDL_GL_SetAttribute( SDL_GL_ALPHA_SIZE, 8 );
	SDL_GL_SetAttribute( SDL_GL_RED_SIZE, 8 );   
	SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE, 8 );
	SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE, 8 ); 
	SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );  
	SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, ColorBits ); 
	SDL_GL_SetAttribute( SDL_GL_BUFFER_SIZE, ColorBits );  
 
	// Center the windows on the screnn
	_putenv("SDL_VIDEO_WINDOW_POS=center"); 
 
	// Name the windows and give it an icon
	SDL_WM_SetCaption(WindowsName.c_str(),WindowsName.c_str()); 
 
	// SDL_VIDEO flags
	int VideoFlags = SDL_OPENGL | SDL_ANYFORMAT ;
	if ( FullScreen )
		VideoFlags |=   SDL_FULLSCREEN ;
 
	// Creating the ScreenSurface 
	m_ScreenSurface = SDL_SetVideoMode( ScreenWidth, ScreenHeight, ColorBits, VideoFlags );
 
	if ( !m_ScreenSurface )
	{
		std::cout << "SDL_VIDEO have failed creating the ScreenSurface" << std::endl ;
	}
 
	// OpenGl init settings 
	glClearColor(0,0,0,1);
	glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); 
	glViewport(0,0,ScreenWidth,ScreenHeight);
	glClearDepth(1.0);
    glEnable(GL_DEPTH_TEST);
	glDepthFunc(GL_LEQUAL);	
 
	glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
	gluPerspective(60.0,(float) ScreenWidth/ScreenHeight,0.1,100.);
	glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
 
	glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 
	// can we use AA ?
	if (SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, 1) == -1)
	{
		std::cout << "Cant Init SDL_GL_MULTISAMPLEBUFFERS to 1" << std::endl ;
	}
 
	if (SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, 8) == -1)
	{
		std::cout << "Cant Init SDL_GL_MULTISAMPLEBUFFERS to 8" << std::endl ;
	}
 
	std::cout << "RenderTask :: Init :: OK " << std::endl ;

Merci !

14/11/2008, 12h10
bafman

tu utilise la pire méthode d'affichage, dans le pire configuration aussi

l'affichage en mode immédiat est le plus lent, et en plus, tu fait un glBegin/glEnd par quad, forcement, ça ne va pas aller vite.

regarde ça, tu devrait avoir de meilleurs perfs : http://raptor.developpez.com/tutorial/opengl/vbo/
14/11/2008, 12h22
Clad3

Effectivement, je fais de l'affichage vraiment peu soigné, mais est-ce que cela justifie d'aussi grands écarts de performances compte tenu de ma machine?

Au fait ; j'avais testé de mettre le "for" entre les glBegin, et glEnd, histoire de voir si le problème changeait mais non.
14/11/2008, 12h40
Klaim

Citation:

Effectivement, je fais de l'affichage vraiment peu soigné, mais est-ce que cela justifie d'aussi grands écarts de performances compte tenu de ma machine?

Oui, tout à fait.

D'abord, tu ne devrais avoir qu'un couple begin/end par rendu d'image, pas un par objet à afficher.

Ensuite effectivement le mode immédiat est lent parcequ'il bloque inutilement le travail de la carte graphique de manière intempestive (dans ce genre de cas j'entends).

Pour comprendre les problemes de perfs avec OpenGL ou DirectX, il faut comprendre aussi le pipeline graphique et savoir le coup des manipulations (comme changer de shader, ou changer de texture dans le pipeline fixe).

Je t'invite à chercher des infos sur le pipeline graphique, ou sur les techniques utilisées par "tous" les moteurs graphiques actuels.

Je déplace cette discussion, ce n'est pas une question C++.
14/11/2008, 12h47
Clad3

Oula, oui j'avoue que moi et le piepline graphique on a jamais été de bon copains...et pourtant c'est pas faute d'avoir eu des cours dessus :/
Je vais me rencarder, merci pour les infos.
14/11/2008, 15h01
ShevchenKik

Bonjour,

ta réponse m'intrigue, Klaim:

Citation:

D'abord, tu ne devrais avoir qu'un couple begin/end par rendu d'image, pas un par objet à afficher.

Je suis bien conscient qu'il faille MINIMISER les paires glBegin/glEnd, mais n'en avoir qu'une seule par frame, est-ce vraiment jouable?? Ou alors je t'ai mal compris...

Par exemple, en travaillant en c++ j'ai tendance à implementer mes "objets" 3D en classes c++, chacune ayant sa methode d'affichage. Dans ce cas je ne vois pas comment eviter au moins une paire glBegin / glEnd par objet...(MAIS je ne dis pas que mon implementation est la meilleure hein, justement je cherche à optimiser d'où ma réponse à ton post)
14/11/2008, 15h20
bafman

en fait, l'ideal, c'est d'avoir un draw call par render state.
en gros, si on utilise des glBegin/glEnd, ca consiste a n'avoir qu'un seul appel par groupe de polygone utilisant les même paramètres pour le rendu (textures, blending, shader et autre)

de toute façon, tu aura au moins 1 glBegin/glEnd par changement de render state...
14/11/2008, 18h06
Klaim

Et si je ne me trompe pas, dans le cas présenté ci-dessus, tous les quads ont exactement le même render state (ils sont semblables).

Citation:

Par exemple, en travaillant en c++ j'ai tendance à implementer mes "objets" 3D en classes c++, chacune ayant sa methode d'affichage. Dans ce cas je ne vois pas comment eviter au moins une paire glBegin / glEnd par objet...(MAIS je ne dis pas que mon implementation est la meilleure hein, justement je cherche à optimiser d'où ma réponse à ton post)

Ben en fait ce que font la plupart des moteurs graphiques consiste justement à recenser les differents render states dans la scène ( les différentes combinaisons de l'etat de rendu, donc les textures utilisés, les paramettres utilisés etc).
Ensuite, ils font un arbre qui permet d'organiser ces etats de manière à mettre les mêmes parties détats sous les mêmes branches (par exemple tous ceux qui utilisent le même shader sous la même branche, puis ensuite en dessous tous ceux qui utilisent la meme texture etc).
On connait les opérations qui coutent le plus cher sur les cartes graphiques (changer de pixel shader > changer de vertex shader > changer de texture > etc) donc l'arbre est organiser de manière à limiter les changements d'etats couteux en les mutualisant.

Avec cet arbre, il suffit ensuite de le parcourir en changeant d'état à chaque noeud pour avoir l'ordre d'affichage le plus "court" pour une scène (cela n'incluant pas les optimisations de frustum culling par exemple, qui déjà limitent les objects à rendre).

Je sais pas pas si j'ai été très clair, mais en gros comme on change d'état a caque noeud, c'est là qu'on fait les begin/end.

Du coup yen a un minimum par scène.
15/11/2008, 19h23
LeGreg

1000 quads par frame : 60 fps
=> 0.016 millisecondes par quad (maths de niveau collège, j'espère que ça ne désarme pas trop :)).

Règle de trois : 10000 quads doivent donc théoriquement être rendus en 166ms (10000 fois 0.016ms). 166ms par frame = 6 frames par seconde.

Donc à une frame par seconde près tu as une prédiction parfaite de ta performance avec cette modélisation simple.

Comment améliorer tes perfs :
- ati -> remplace par une geforce (support OpenGL bien meilleur, hein, juste pour dire).

- 10000 quads = 20000 triangles, une carte moderne pourrait sans problème afficher un million de triangles par frame à 60 frames par secondes (tout dépend si tu es attribute fetch limited, vertex processing limited ou triangle setup limited ou limité par une toute autre partie du pipeline : CPU, pixels ou PCI-E). Pour le coût du begin/end par quad, cela peut-être problèmatique si tu es PCI-E bandwidth limited ou CPU limited, mais tout d'abord il faut déterminer si c'est ton cas avant de faire des plans sur la comète!

PAR CONTRE, si tes triangles ont une certaine surface à l'écran et que tu les affiche les uns par dessus les autres, tu seras peut-être limité par le pixel fill rate ou le fragment processing ou les deux.

Exemple si ton quad fait 1000x1000 pixels (1 million de pixels). Si tu affiches 10000 quads, cela fait 10 milliards de pixels à colorer par frames. Avec une carte graphique qui peut colorer 32 pixels par cycle (carte hypothétique proche ou pas de ta config) et qui tourne à 500 millions de cycles par secondes (autre cas hypothétiques), tu peux donc colorer 16 milliards de pixels par secondes. 16 milliards de pixels par secondes divisés par 10 milliards de pixels par frames, cela donne 1.6 frames par secondes (refais les calculs dans ton cas pour voir si c'est une bonne prédiction de la performance). Si ça semble être le cas, essaie donc de réduire la taille du quad à l'écran, etc avant de te préoccuper du coût CPU.

Toutes les infos sur comment trouver le bottleneck (goulet d'étranglement) de ton application dans le GPU programming guide à lire absolument ici :
http://developer.nvidia.com/object/g...ing_guide.html

LeGreg
17/11/2008, 12h06
shenron666

Citation:

Envoyé par LeGreg

Comment améliorer tes perfs :
- ati -> remplace par une geforce (support OpenGL bien meilleur, hein, juste pour dire).

si on pouvait éviter d'aller à l'extrême, déjà que ce cas de figure n'est plus d'actualité

au choix, les drivers geforce ont régressés dans leur support opengl ou les drivers ATI se sont améliorés

mais de plus, il a ce qu'il se fait de mieux sur le marché grand public comme GPU : HD4870
si encore il avait une vielle carte vidéo mais là... :roll:

question pour ShevchenKik : dans quelle résolution configures tu ton affichage ?
17/11/2008, 12h12
ShevchenKik

Re,

Citation:

question pour ShevchenKik : dans quelle résolution configures tu ton affichage ?

Je ne suis pas sûr de comprendre ta question: sur mon ordi de developpement j'ai du 1680*1050 et 1280*1024 (2 écrans), mais ma fenêtre OpenGL est intégrée dans une interface en .NET, donc même en plein écran je ne suis jamais à la résolution maximale.
17/11/2008, 12h28
shenron666

au temps pour moi, je suis mal réveillé, c'est à Clad3 que j'aurai dû poser cette question :aie:
:pataper:
17/11/2008, 13h10
ShevchenKik

Hehe oui là du coup je comprends mieux ;)
19/11/2008, 22h25
Clad3

oula, j'avais manqué quelques réponses :)

Je suis donc en 1920*1200 sur le bureau et en 1024*768 sur ma fenêtre de test, mes quad faisait environ 50 pixel sur 50 pixel, de mémoire.

@LeGreg Merci des précision, en fait j'avais tendances à avoir de fausses croyances sur les CG :)
19/11/2008, 23h06
LeGreg

50x50x10000 ça fait "juste" 25 millions de pixels par frames. ça devrait passer à plus de 100 fps sur une carte haut de gamme. Ceci dit tu utilises le multisampling 8x apparemment. Ça va réduire la perf (entre 0% et 80% suivant le cas pathologique).

- tente de réduire le multisampling (essaie avec aucun multisampling), tente de diminuer la taille de ton quad pour voir si le nombre de pixels influe sur la performance, teste ton programme sur une autre machine (avec une carte graphique d'un autre vendeur pour vérifier que ce n'est pas un problème de driver) etc.

LeGreg
20/11/2008, 22h45
shenron666

Citation:

Envoyé par LeGreg

Ceci dit tu utilises le multisampling 8x apparemment. Ça va réduire la perf (entre 0% et 80% suivant le cas pathologique).

ouh pinaise, j'avais pas vu, il active un FSAA à 8 :aie: :scarymov:
je veux bien que les radeon HD4xxx soient bonnes en FSAA mais c'est pas une raison pour les martyriser ;)

de mon avis perso, mieux vaut une bonne grosse résolution plutot que d'activer le multisampling
surtout pour du temps réel où on n'a pas le temps de s'attarder à regarder les piexls à la loupe :mrgreen: