Discussion :

[Neckara]

Bonjour,

Je suis sous Ubuntu 12.04 LTS avec une RAM de 4Go et une carte graphique dont l’accélération matérielle est activée.

neckara@neckUbu:~$ sudo lspci -v | grep -A 12 VGA
[sudo] password for neckara:
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 0487
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at b0000000 (64-bit, non-prefetchable) [size=4M]
Memory at a0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 3050 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

J'utilise Irrlicht 1.7 et j'essaye d'afficher une scène ayant 56 objets non-animés de 2503 Vertex et 4230 faces.

J'ai un FPS de 16-17 et j'aimerais savoir si ce FPS aussi bas ne viendrait pas un peu de mon ordinateur.
Niveau programmation, j'utilise ceci :

Code :

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

m_node = sceneManager->addMeshSceneNode(sceneManager->getMesh("/home/neckara/Bureau/Socle_non_anime_mis_en_valeur (2).3ds") , parent, -1, position, angle);

Sinon existe-t-il des astuces/conseils pour augmenter le FPS ?

Avec m->setHardwareMappingHint(irr::scene::EHM_STATIC); je passe à 24 FPS (où m est le mesh retourné par getMesh).
Il semblerait aussi qu'utiliser des .mesh au lieu de .3ds serait bien plus performant, qu'en pensez-vous?

[LittleWhite]

Bonjour,

Je pense toujours que les puces d'Intel sont toujours à la ramasse, par contre, je suis pas sur non plus qu'il n'y a pas un autre problème. Il faudrait tester d'autres application Irrlicht pour voir si le fable FPS provient de vous ou du moteur / driver. Il faudrait aussi tester glxgears et d'autres application OpenGL.

Mais en tout cas, le FPS me parait bien bas (même pour une puce Intel)

[Neckara]

Je ne sais pas exactement ce qu'il faut utiliser pour tester.

glxgears me donne :

neckara@neckUbu:~$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
4223 frames in 5.0 seconds = 844.441 FPS
4462 frames in 5.0 seconds = 892.259 FPS
4471 frames in 5.0 seconds = 894.152 FPS
4468 frames in 5.0 seconds = 893.529 FPS
4535 frames in 5.0 seconds = 906.995 FPS
4604 frames in 5.0 seconds = 920.592 FPS

Second essai :

neckara@neckUbu:~$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
4216 frames in 5.0 seconds = 843.026 FPS
4459 frames in 5.0 seconds = 891.767 FPS
4466 frames in 5.0 seconds = 893.030 FPS
4449 frames in 5.0 seconds = 889.605 FPS
4707 frames in 5.0 seconds = 941.395 FPS
4429 frames in 5.0 seconds = 885.660 FPS
4458 frames in 5.0 seconds = 891.560 FPS
4468 frames in 5.0 seconds = 893.595 FPS
4462 frames in 5.0 seconds = 892.317 FPS
4458 frames in 5.0 seconds = 891.503 FPS
4119 frames in 5.0 seconds = 823.718 FPS
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 48891 requests (48891 known processed) with 0 events remaining.

L'erreur est apparue quand j'ai quitté.

[Emmanuel Deloget]

Je ne sais pas exactement ce qu'il faut utiliser pour tester.

glxgears me donne :

Second essai :

L'erreur est apparue quand j'ai quitté.

L'erreur est due au fait que lorsque tu quitte glxgears, celui-ci ne libère pas la ressource XWindow associée au process. Il fait un exit(), qui tue le file descriptor sous jacent (en fait, une socket), ce qui provoque l'erreur que tu vois.

Vis à vis de ta carte graphique, il faut aussi connaître ces possibilités : est-ce que cette carte est de la génération TnL hardware ou pas (pour info, ça ne fait pas si longtemps que les cartes graphiques Intel ne font pas le TnL (vshader) en software).

Ceci dit, 140168 vertex par seconde, ça me parait un peu limité. J'ai le souvenir que Irrlicht a refusé pendant longtemps la possiblité de jouer avec des VB et IB hardware, préférant le pipeline fixe. Il me semble que ça a évolué il y a peu (irrlicht 1.6 ?) donc le bottleneck ne devrait pas se situer ici. Est-ce que tu pourrais communiquer ton code de rendu ?

Merci d'avance !

[screetch]

On a sans doute pas la meme carte graphique (j'ai un processeur core i7 avec carte graphique integree, on dirait le meme que toi, mais je ne sais pas quant a la version)
neanmoins j'obtiens le resultat suivant:

Code :

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

21535 frames in 5.0 seconds = 4306.910 FPS

quelques petits trucs qui peuvent pas mal influer:
- meme en utilisant le driver i915, il est possible que la 3d ne soit pas acceleree; on teste normalement avec la commande glxinfo
si au debut on a une ligne Direct rendering: YES alors je crois que c'est active, sinon c'est le CPU qui fait le boulot.

- les gestionnaires de fenetre qui font de la composition peuvent mettre en l'air le framerate parfois. J'ai opte pour un gestionnaire de fenetre moins congourmand, fxce, qui fait de la composition (transparence et tout) de maniere tres efficace (je passe de 4400FPS a 4200FPS sur mon laptop)

mais si tu as enlightenment ou gnome ou pire, KDE, alors il peut VRAIMENT foirer les performances.

[Neckara]

Vis à vis de ta carte graphique, il faut aussi connaître ces possibilités : est-ce que cette carte est de la génération TnL hardware ou pas (pour info, ça ne fait pas si longtemps que les cartes graphiques Intel ne font pas le TnL (vshader) en software).

Je n'ai pas tout compris, comment vérifier si elle est de la génération TnL hardware ?

Ceci dit, 140168 vertex par seconde, ça me parait un peu limité. J'ai le souvenir que Irrlicht a refusé pendant longtemps la possiblité de jouer avec des VB et IB hardware, préférant le pipeline fixe. Il me semble que ça a évolué il y a peu (irrlicht 1.6 ?) donc le bottleneck ne devrait pas se situer ici. Est-ce que tu pourrais communiquer ton code de rendu ?

boucle de rendu

Code :

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

1
2
3
4
5
6
7
8
9
10
        while (device->run())
        {
            driver->beginScene(true,true,irr::video::SColor(255,100,255,255));    // fond blanc
            sceneManager->drawAll();                    // sceneManager vide
            gui->drawAll();
            driver->endScene();
            irr::core::stringw titre;
            titre += driver->getFPS();
            device->setWindowCaption(titre.c_str ());//for know the frame rate
        }

la vue est un IGUIElement

Code :

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

1
2
3
4
5
6
    void Vue::draw(void)
    {
        driver->setViewPort( AbsoluteRect );
        sceneManager->setActiveCamera(camera);
        sceneManager->drawAll();
    }

ajout d'un socle

Code :

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

1
2
3
        irr::scene::IAnimatedMesh * m = sceneManager->getMesh("/home/neckara/Bureau/Socle_non_anime_mis_en_valeur (2).3ds");
        m->setHardwareMappingHint(irr::scene::EHM_STATIC);
        m_node = sceneManager->addMeshSceneNode( m , parent, -1, position, angle);

@screetch :
DirectRending est bien à 'Yes'
Pour le gestionnaire de bureau j'ai Unity.

[Emmanuel Deloget]

Le coupable est, je dirais device->SetWindowCaption(), qui est excessivement lent (sous Windows tout au moins ; sous Linux, je pense que ça peut être relativement lent aussi).

De plus, te exécute cette fonction à chaque itération de la boucle de rendu - alors que logiquement, une fois par seconde suffit.

Donc je te conseille d'enlever cet appel ou de minimiser son impact

Ensuite, je ne suis pas sûr que le SetViewport() soit vraiment une bonne chose. Il me semble (un spécialise GL peut me seconder ou m'infirmer ici) que ça a un impact assez fort sur ce que fait le driver en interne - et notamment, celà peut demander au driver de recréer un backbuffer. Donc à voir si c'est nécessaire de la faire à chaque itération plutôt que sur les évènement de création et de resize de la fenêtre.

Je ne sais pas comment vérifier si une carte graphique fait le TnL en hard ou en soft. Le fait d'avoir DirectRendering = TRUE ne donne pas se renseignement. En fait, direct rendering n'est pas vraiment la ligne à regarder - ça avertit juste que X ne se met pas en travers de ton chemin, et donc que tu passes par l'architecture DRM de Linux (si DR == No, alors les données sont envoyées au serveur X et non pas au driver ; le serveur X peut alors faire le rendu en soft ou forwarder ces données à un driver spécialisé ; c'est notamment le cas si tu fais du rendu hardware sur un serveur X distant).

Je vais essayer de trouver une réponse à cette épineuse question...

[Neckara]

Le coupable est, je dirais device->SetWindowCaption(), qui est excessivement lent (sous Windows tout au moins ; sous Linux, je pense que ça peut être relativement lent aussi).

De plus, te exécute cette fonction à chaque itération de la boucle de rendu - alors que logiquement, une fois par seconde suffit.

Donc je te conseille d'enlever cet appel ou de minimiser son impact

J'ai mis un :

Code :

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

1
2
3
4
5
6
7
            if(++i == 100)
            {
                irr::core::stringw titre;
                titre += driver->getFPS();
                device->setWindowCaption(titre.c_str ());//for know the frame rate
                i = 0;
            }

Je gagne un "demi-FPS"

Ensuite, je ne suis pas sûr que le SetViewport() soit vraiment une bonne chose. Il me semble (un spécialise GL peut me seconder ou m'infirmer ici) que ça a un impact assez fort sur ce que fait le driver en interne - et notamment, celà peut demander au driver de recréer un backbuffer. Donc à voir si c'est nécessaire de la faire à chaque itération plutôt que sur les évènement de création et de resize de la fenêtre.

J'ai enlevé :

Code :

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

driver->setViewPort( AbsoluteRect );

Mais je n'ai pas de différence de FPS.
Le problème c'est que je considère cet élément comme un objet de gui, je peux donc me retrouver avec plusieurs sceneManager à la fois. (Sur un ordi performant le FPS devrait être correct).

Merci pour ton aide.

[LittleWhite]

Bonjour,

Il serait cool de lancer un gprof, de compiler avec -DNDEBUG et -O2 (pour voir les perfs dans ces cas). Mais le gprof c'est le reflex à avoir lorsque l'on cherche de la performance.
Un petit coup de gDEBugger ça peut être génial aussi, si la latence vient bien du GPU.

Sinon, peut être un code C++ mal fait. Mais c'est gprof qui nous le dira.

Peux tu aussi nous envoyer le log de glinfo, ça sera bien (et le pilote utilisé / sa version, mais glinfo le donne peut être)

[Neckara]

Bonjour,

J'ai mis le résultat de glxinfo en pièce jointe.
Quand je met -O2, je perds 2FPS, j'ai aussi essayé avec gprof mais en rajoutant l'option -pg, aucun fichier n'est généré, je ne comprend pas tout à fait.

[LittleWhite]

Bon, comme j'en parlais à Emmanuel Deloget hier, j'imagine que si on a des shaders (OpenGL 2) on a du TnL. Donc là n'est pas le problème.
Après, Mesa 8 c'est pas mal (je suis sous Mesa 7 et j'arrive à jouer à warsow). Par contre, il va falloir trouver des infos sur IronLake pour savoir la réalité (wikipedia ?).

N'avoir que 800 FPS sur glxgears ... c'est un peu ... inquiétant, quand j'y pense. L'idée de désactiver tous les trucs gourmands (KDE / Compiz) peut être une bonne chose, même si de mémoire ce n'était pas très gourmand. Après, faut explorer Google et les forums pour savoir ce que disent d'autres utilisateurs de la puce.

[Emmanuel Deloget]

En même temps, les chipset intel sont connus pour avoir des performances limitées sous Linux. Il y a eu une avancée en début d'année avec l'apparition de SNA (Sandy Bridge New Acceleration).

D'ailleurs, il faudrait peut-être voir si SNA est activé sur ta machine. Par défaut, c'est un autre type d'accélération (UXA) qui est activé sur les drivers Intel - et cette accélération est assez limitée (bonne en 2D, et encore, pas pour tout).

Est-ce que tu peux poster ton fichier /etc/X11/xorg.conf ?

[LittleWhite]

Sauf que je doute que ce soit un sandy bridge, car glxinfo indique SandyBridge dans son log pour les Sandy Bridge.
Après, oui, les pilotes Intel, ils sont en retard, c'est nul en perf tout ça, mais cela s'est amélioré depuis (un peu, même si c'est toujours pas du NVIDIA ou AMD).

[Emmanuel Deloget]

Sauf que je doute que ce soit un sandy bridge, car glxinfo indique SandyBridge dans son log pour les Sandy Bridge.
Après, oui, les pilotes Intel, ils sont en retard, c'est nul en perf tout ça, mais cela s'est amélioré depuis (un peu, même si c'est toujours pas du NVIDIA ou AMD).

SNA marche pour toute la gamme récente de GPU intel (même si l'accélération est moindre), donc c'est à tester quand même selon moi

[LittleWhite]

J'aimerai bien avoir le nom complet du CPU au final (si c'est un i* ou un Nehalem)

Sinon : https://bbs.archlinux.org/viewtopic.php?pid=1058479

[Neckara]

Je n'ai pas de fichier xorg.conf.
Dans /etc/X11/, je n'ai pas de fichiers .conf

CPU info :

Vendeur : GenuineIntel
CPUs : 2
Model Name : Intel(R) Pentium(R) CPU P6200 @ 2.13GHz
Frequency : 933.000 MHz
L2 Cache : 3072 KB
Bogomips : 4255.78
Numbering : family(6) model(37) stepping(5)
Flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid popcnt lahf_lm arat dtherm

[Je regarde pour le lien]

EDIT : J'ai rajouté CLUTTER_PAINT=disable-clipped-redraws:disable-culling à /etc/environment et j'ai désormais un FPS de 60 sur glxgears.
Je pense qu'il force les applications à faire du vsync.
Mais sur mon programme je ne vois pas de réelle avancée.

Pour le reste :

The SNA and semaphores are both considered unstable at the moment. Perhaps you can try i915.i915_enable_rc6=1 which both saves power and improves framerate a bit (although it doesn't work with certain HW configurations). As for video acceleration, consider using a player that supports VAAPI (mplayer-vaapi or VLC for instance).Does this problem occur outside GNOME 3 as well? Perhaps you could run some benchmarks just from TWM to check if the GPU is really slow for some reason or if there is a problem with Intel HD + GNOME 3 setup.BTW here is a list of all(?) i915 module parameters, maybe you can play around with them and find if any of them gives you some significant speed boost

fbpercrtc:0
i915_enable_rc6:1
lvds_downclock:1
lvds_use_ssc:1
modeset:-1
powersave:1
reset:Y
semaphores:0

Je n'ai pas tout à fait compris quel fichier il faut modifier.

[LittleWhite]

Dans les dernières version de X11, y a plus le fichier xorg.conf (et je ne sais plus trop comment cela fonctionne).
Vive la doc, surtout la partie GPU : http://ark.intel.com/products/50176

Bon je trouve rien de précis.
Je dois dire, va falloir que tu test d'autres programmes Irrlicht pour voir comment ils réagissent

[Neckara]

Bonjour,

3 ans et 2 ordinateurs portables plus tard, je me permet de déterrer ce sujet pour donner une solution.

Sur les ordinateurs portables, il n'est pas rare d'avoir une carte graphique en plus d'une chipset graphique donc d'avoir une nvidia en plus de la chipset intel.

La chipset graphique est utilisée par défaut, pour utiliser la carte graphique, il faut l'indiquer explicitement lorsqu'on lance l'application.

Plus de détails ici : http://www.developpez.net/forums/d15...e/#post8355613