Je développe pour mon plaisir des petits programmes utilisant OpenGL, j'utilise donc les drivers propriétaires de nvidia, seulement voilà, depuis un moment il y avait un truc qui m'agaçait un peu, c'était cette impression d'avoir une chute du framerate ponctuelle. Le rendu est fluide, sauf à certains moments ou paf! on sent qu'une frame a été plus lourde à dessiner. J'ai alors pensé que je m'y prenais mal, que je codais comme un porc, etc., mais en testant sous un windows, le problème ne semblait pas se produire. J'ai regardé d'autres applications utilisant OpenGL sous linux, genre celestia, même problème ! J'ai essayé Enemy Territory mais bon, trop difficile à voir, il faut avoir un objet en mouvement uniforme pour bien le sentir. J'ai essayé avec SDL et avec glut, pareil (au cas où ça viendrait de la bibliothèque qui gère les fenêtres et évènements).
Je n'ai pas le souvenir d'avoir eu ce problème il y a un an, et j'ai l'impression que plus les pilotes sont récents, et plus ça se sent. Ça me le faisait sur ma GeForce2 MX, ça le faisait sur une autre machine avec une GeForceFX 5600, ça le fait sur ma machine, mais avec une GeForceFX 5500 cette fois. Et plus la scène est complexe, plus ça se fait sentir (le pic est plus important).
J'ai fait mon petit bench maison rapidement cet aprem, histoire de voir. C'est un programme tout bidon qui fait tourner une sphère pendant 5 secondes tout en enregistrant le framerate calculé à chaque frame, et qui l'imprime dans un fichier en quittant. Voici les résultats avec les 66.29 (première colonne : temps ; seconde colonne : framerate) :
- http://tfc.duke.free.fr/divers/nvbench1000.txt(...) : sans restrictions ;
- http://tfc.duke.free.fr/divers/nvbench60.txt(...) : avec un blocage du framerate à 60 fps ;
- http://tfc.duke.free.fr/divers/nvbenchXP.txt(...) : sous WindowsXP (avec des drivers qui doivent avoir plus d'un an d'ailleurs) ;
Les '###' en fin de ligne indiquent une chute anormale par rapport à ce qui est espéré.
Avec des graphiques, on voit tout de suite le truc qui coince (abscisses : temps ; ordonnées : framerate). Ça s'étale sur une durée de 5 secondes :
- http://tfc.duke.free.fr/screens/nvbench60.png(...) : Linux, bloqué à 60 fps par l'application ;
- http://tfc.duke.free.fr/screens/nvbenchXP.png(...) : WindowsXP, bloqué à 60 fps mais par le driver ;
Sous Windows, framerate constant. Sous Linux, on note 7~8 chutes brutales en l'espace de 5 secondes, pour afficher une pauvre sphère qui tourne sans texture ni éclairage. C'est vraiment pénible car on ne peut plus faire une animation en fonction du temps sans que ça saccade. Bon, peut-être que ça ne vient pas des drivers, peut-être le système envoie des messages à ma fenêtre et qui seraient lourd à traiter ? J'en sais rien...
Le truc chiant c'est que c'est comme le pixel mort dans le coin de l'écran, on ne voit plus que ça. Et on ne peut rien faire.
Si le bench vous intéresse, http://tfc.duke.free.fr/divers/bench.c(...)
Il y a une petite bidouille à faire ligne 133 pour retirer le plafond de 60 fps (#if 1 en #if 0) et ligne 86, remplacer le 50 par la valeur moyenne qu'il vous sort, moins des broutilles (genre 480 pour ~500 fps).
Vivement que TechSource sorte sa carte graphique libre.
# un bug report ?
Posté par Victor . Évalué à 6.
je crois bien que ce soit possible, peut etre au travers des forum ou on trouve tout les patchs pour ces drivers : http://www.nvnews.net/vbulletin/forumdisplay.php?f=14(...) (pas sur mais bon :)
[^] # Re: un bug report ?
Posté par Meku (site web personnel) . Évalué à 2.
# Sympa les graphes
Posté par ~ lilliput (site web personnel) . Évalué à 1.
J'ai parcouru ton site a la recherche du programme qui permettait de générer les png à partir des stats.txt mais j'ai pas trouvé.
Pourrais tu expliquer comment tu fais ?
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Sympa les graphes
Posté par Meku (site web personnel) . Évalué à 4.
[^] # Re: Sympa les graphes
Posté par kd . Évalué à 6.
#!/bin/sh
sed 's/;//' benchout.txt >benchout-2.txt
gnuplot >bench.png <<EOF
set terminal png
plot "benchout-2.txt" with lines
EOF
xloadimage bench.png
# Re:
Posté par kd . Évalué à 2.
Je ne peux plus faire de 3D dans des conditions décentes, mais peu importe, au moins ça ne plante pas.
Avec de la 3D software grâce à Mesa, je monte à 30 FPS avec ton bench, et ce avec un petit Pentium III cadencé à 800 MHz
Au moins, moi, j'ai un nombre d'image par secondes qui reste constant :))
# Pas de Pb
Posté par Johann Heymes . Évalué à 3.
J'ai exécuté ton bench.c et voilà mes résultats :
mmm question, c'est normale que cela prenne 100% du processeur juste pour ça ?
[^] # Re: Pas de Pb
Posté par ckyl . Évalué à 4.
Le but d'un programme graphique est d'avoir le meilleur rendu possible. Donc a priori d'utiliser toujours au maximum les ressources que lui alloue le système.
Si la machine a besoin de faire autre chose alors elle donnera moins de temps au programme, qui lui consommera toujours au maximum les ressources que l'on lui donne.
Donc oui c'est normal, un programme graphique ca fait grosso modo un
while(1) redisplay();
Tu remarqueras que dans le cas ou tu bloques le framerate, son test consomme toujours tout le CPU car il n'a pas le temps de faire un nanosleep, il regarde en permanence l'heure courante pour sortir de la boucle au bon moment.
[^] # Re: Pas de Pb
Posté par M . Évalué à 3.
# C'est le scheduler que tu mesures ...
Posté par Lucas . Évalué à 10.
It's not a bug, it's a feature :-)
Avec une granularité si faible (proche du millième de secondes) il faut tenir compte du scheduler (l'ordonnanceur). Pendant que ton programme s'exécute, il n'est pas seul sur la machine. Et de temps à autre, le noyau décide de lui faire passer son tour. Ce qui se traduit par des "trous". Ceux qui ont des valeurs constantes n'avaient juste rien d'autre qui tournait. Et je pense que sous Windows, si tu fais tourner autre chose en //, tu auras le même problème.
Démonstration :
Le programme Ruby en lien [0] execute autant de fois que possible la fonction "busyloop". Après chaque intervalle de temps, il affiche combien de fois elle a été exécutée.
On constate exactement le même phénomène : de temps en temps, les performances chutent brusquement. En graphant [1], on constate même autre chose : à vue de nez, c'est régulier ! Ce qui confirme bien l'hypothèse que, de temps en temps, le noyau laisse la place à une autre appli.
Maintenant, pour résoudre ton problème, tu peux :
- augmenter la priorité de ton programme, et l'executer en tant que root
- fermer toutes tes petites applets qui bouffent tout plein de proc et ne servent à rien de toute facon
- tenir compte du fait que, parfois, il faut laisser les autres s'executer, par exemple en appelant volontairement sched_yield() quand ça t'arrange
- jouer avec les priorités temps réel du noyau, pour ne pas laisser les autres s'executer
Pourquoi ca ne fait pas pareil sous Windows ?
Je ne connais pas le scheduler de Windows. Mais peut-être qu'il autorise une appli à bouffer tout le proc pendant 5 secondes. Ca vaut peut-être le coup d'augmenter la durée du test.
Ou alors, peut-etre que ton Windows est juste moins chargé que ton Linux.
[0] http://bazaar.lucas-nussbaum.net/linuxfr/sched.rb(...)
[1] http://bazaar.lucas-nussbaum.net/linuxfr/sched.png(...)
[^] # Re: C'est le scheduler que tu mesures ...
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
http://members.optusnet.com.au/ckolivas/kernel/(...)
http://freequaos.host.sk/schedtool/(...)
http://rlove.org/schedutils/(...)
[^] # aaaaaaahhhhhh /o/
Posté par Meku (site web personnel) . Évalué à 2.
C'est dommage, je les aimais bien, je vais devoir m'en séparer ;_;
Je les réactiverai pour les screenshots du desktop qu'on présente parmi tous les bureaux windows, sur les forums.
C'était pratique quand même pour voir la mémoire qu'utilisaient mes programmes, quand j'allais swapper, les flux réseau, etc.
Je me demande si ces petits bidules se désactivent eux même quand une application couvre tout l'écran (genre un jeu).
En tout cas, un gros merci !!!
[^] # Re: aaaaaaahhhhhh /o/
Posté par GCN (site web personnel) . Évalué à 2.
[^] # Re: aaaaaaahhhhhh /o/
Posté par Meku (site web personnel) . Évalué à 1.
[^] # Re: aaaaaaahhhhhh /o/
Posté par M . Évalué à 2.
# Truc Imoprtant en 3d
Posté par tuan kuranes (site web personnel) . Évalué à 2.
En 3d, on utilise toujours un temps moyen sur les n dernieres frames, jamais un temps absolu pour l'animation. (et encore plus pour la physque, l'IA, etc)
ET
un max de temps qui permet d'empecher l'execution (si on sort de ton appli et que l'on rentre 2mn plus tard). Si l'ecart de temps est trop important, on annule l'execution de cette frame et on reprend a la nieme prochaine..
Reference : "The Clock: Keeping Your Finger on the Pulse of the Game," Game Programming Gems 4, Charles River Media, 2004.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.