Journal Drivers nvidia, drivers en carton ?

Posté par (page perso) .
Tags : aucun
0
6
mar.
2005
Bonjour, aujourd'hui je voudrais parler un peu des drivers proprios nvidia.

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) :

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 :

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 . Évalué à 6.

    Peut etre que tu pourrais faire un bug report aupres de nvidia ?

    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 (page perso) . Évalué à 2.

      Bon, en fait ça semble ne pas être un bug mais moi qui lance plein guirlandes clignotantes sur mon bureau GNOME :-)
  • # Sympa les graphes

    Posté par (page perso) . Évalué à 1.

    Salut, bon mis a part le problème sur les drivers, tes testes sont bien fait.
    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 (page perso) . Évalué à 4.

      Avec gnumeric, j'importe les données du fichier. Ne pas oublier de remplacer les '.' par des ',' si gnumeric est configuré pour utiliser la virgule comme séparateur partie entière/partie décimale. Ensuite, graphe, puis capture d'écran :))
    • [^] # Re: Sympa les graphes

      Posté par . Évalué à 6.

      un petit script vite fait pour faire ça (UNIX, shell, tout ça roxors) :

      #!/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 . Évalué à 2.

    Je n'utilise plus les drivers de nvidia depuis que ça a fait planté ma machine. Et pourtant j'en aurais bien besoin pour faire tourner certains programmes.

    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 . Évalué à 3.

    Salut,

    J'ai exécuté ton bench.c et voilà mes résultats :

    0.000 ; 0.000 ###
    0.046 ; 21.739 ###
    0.063 ; 58.824
    0.080 ; 58.824
    ... pas de changement 58.824 partout
    5.010 ; 58.824


    mmm question, c'est normale que cela prenne 100% du processeur juste pour ça ?
    • [^] # Re: Pas de Pb

      Posté par . Évalué à 4.

      > mmm question, c'est normale que cela prenne 100% du processeur juste pour ça ?

      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 . Évalué à 3.

      idem chez moi sur une geforce 4 mx et les derniers drivers nvidia...
  • # C'est le scheduler que tu mesures ...

    Posté par (page perso) . Évalué à 10.

    Stooooooooooooooooop !
    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 (page perso) . Évalué à 5.

      D'autres pistes: tester des schedulers différents, ou utiliser des outils influant sur ce dernier.

      http://members.optusnet.com.au/ckolivas/kernel/(...)
      http://freequaos.host.sk/schedtool/(...)
      http://rlove.org/schedutils/(...)
    • [^] # aaaaaaahhhhhh /o/

      Posté par (page perso) . Évalué à 2.

      pffffffff quel nul je suis ; c'est sûr qu'avec gkrellm et tous les trucs qui clignotent, plus l'appelet gnome avec les mêmes trucs qui clignotent...! En les retirant, on ne trouve plus qu'un pic moyen (qu'on ne sent pas). En effet, il y a un an je ne les utilisais pas (je les ai longtemps cherché avant des les trouver !)

      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 (page perso) . Évalué à 2.

        Je ne sais pas si ça arrangera quoique ce soit, mais il est toujours possible d'essayer de lancer gkrellm avec la priorité la plus basse possible et de voir ce que ça donne....
      • [^] # Re: aaaaaaahhhhhh /o/

        Posté par . Évalué à 2.

        ben non, tu modifie ton programme pour ne pas faire une attente active...
  • # Truc Imoprtant en 3d

    Posté par (page perso) . Évalué à 2.

    "C'est vraiment pénible car on ne peut plus faire une animation en fonction du temps sans que ça saccade"

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.