gestion de la carte graphique linux/Xplane eyt frale rate

[Pascal]

Quand une chaine casse, c'est toujours au maillon faible. Ici c'est pareil.

Vu que ce n'est manifestement pas ni la carte graphique ni le processeur qui sont le maillon faible dans la chaine X-Plane, augmenter la puissance de calcul ou la VRAM de la carte graphique ou la puissance de calcul du processeur principal n'a aucune influence au delà du seuil minimal généré par le maillon faible.

Et tout laisse penser que le maillon faible de situe au niveau du programme interne X-Plane lui-même, dans sa façon de gérer l'ensemble, et surtout la communication entre le processeur et la carte graphique qui sature le bus PCIe. Or le bus PCIe est normé et sa vitesse maximale de transfert ne change quasiment pas quelque soit la structure de la machine de même génération de chipset. donc monter en puissance n'apportera rien de mieux.

Les deux seules solutions sont
- agmenter le débit PCIe. Il est parfois possible d'overclocker le bus PCIe, mais c'est l'overclocking le plus délicat à gérer, il impacte TOUS les périphériques connectés au PCIe et je ne me hasarderai pas à le conseiller (ni même à le tester : pas assez de temps et pas envie de changer de carte mère).

- modifier la façon donc X-Plane gère le rendu. Là, on ne peut rien faire si ce n'est de remonter les demandes à Laminar, mais même avec beaucoup de bonne volonté, l'équipe de quelque personnes (3 ou 4) qui écrit le programme de tout le simulateur (et d'autres produits) ne pourra jamais rivaliser avec les équipes plus fournies qui travaillent exclusivement et à plein temps sur les moteurs de rendu 3D. Donc j'ai bien peur qu'il ne faille pas attendre de révolution à ce niveau, sauf en cas de changement de politique interne chez Laminar (utilisation d'un moteur de rendu professionnel en remplacement du leur, ce qui me parait très improbable).

[Ypsos]

Quand une chaine casse, c'est toujours au maillon faible. Ici c'est pareil.

....
Et tout laisse penser que le maillon faible de situe au niveau du programme interne X-Plane lui-même, dans sa façon de gérer l'ensemble, et surtout la communication entre le processeur et la carte graphique qui sature le bus PCIe. Or le bus PCIe est normé et sa vitesse maximale de transfert ne change quasiment pas quelque soit la structure de la machine de même génération de chipset. donc monter en puissance n'apportera rien de mieux.

Les deux seules solutions sont
- agmenter le débit PCIe. Il est parfois possible d'overclocker le bus PCIe, mais c'est l'overclocking le plus délicat à gérer, il impacte TOUS les périphériques connectés au PCIe et je ne me hasarderai pas à le conseiller (ni même à le tester : pas assez de temps et pas envie de changer de carte mère).

...

Merci pour les réponse et le débat.

N'étant pas sur Linux, n'étant pas développeur Laminar, Nous savons qu'un des sujets qui "fâche" est la gestion graphique de xPlane reste la question du maillon, faible que je comprends et qui est logique.

MAIS (scrongneutudieu de ... on y perd son "latin"
-Le maillon, faible pouvant être le bus, certes, mais il n'est sollicité, dans le cas présent, qu'à hauteur de 11% ( 89% sont au repos donc il y a de la marge)
- xPlane lui même? Certes.! Mais pour la configuration dont nous parlons, même en option graphique minimaliste sur paramètre option," favoriser la vitesse" il reste limité à des "fps" bas qui sont inférieures à ma configuration .

Pour mémoire
Je suis sur mac avec 512Go de VRam , bref pas un foudre de guerre.
Mais ma "culture générale" ne comprends pas pourquoi, à comparaison de la configuration dont nous parlons "musclées" de notre ami, et la mienne, je tourne entre 45/60 fps avec 3 moniteurs de connectés en 1920x1080 (ok, avec une carte externe matrox avec seulement 2GO (mais pas 6Go), une connexion thunderbod et pas en Pcie interne) plus une connexion réseau avec plusieurs avions à afficher (voir jpeg) donc je cumule les problèmes potentiels de ralentissement.

Certes ma comparaison serait comme comparer le volume d'une brouette (ma configuration) avec un camion (l'exemple dont nous parlons) mais dont le volume déplacé par le camion est inférieur à celui de ma brouette

Il faut avouer que cela devient incompréhensible (ok même en augmentant la capacité de charge de ma brouette, la roue et la puissance nécessaire au déplacement du volume ne vont pas suivre, mais le débat , n'est pas la , on demande juste au camion de déplacer au minima, le volume des conditions de la brouette mais le camion n'y arrive pas)




Hypothèse: est-ce que xPlane sur Linux se comporterait encore moins bien pour la gestion graphique/fps que sous Windows et Mac?`

[guyt]

Il pourrait déjà faire une mise à jour de son driver de carte graphique (probablement toujours celui de l'installation )
Pour ta question , Ypsos , des tests ont été effectué ici même et les différences ne sont pas à ce point flagrantes , et pas toujours dans le sens de ce post.

Guy

[Pascal]

Si le maillon faible n'est pas le bus PCIe lui même, ni le Cpu, ni le Gpu, alors "la vérité est ailleurs" !
Il y a alors forcement un composant (hard ou soft) qui attend quelque chose et dont les attentes ne sont pas comptabilisées dans l'affichage de la charge.

Là, je n'ai aucune idée de qui attend, ni de ce qu'il attend, ni de comment le localiser.
Chipset qui attend un signalement ? Carte graphique qui attend la fin de balayage écran ? (le vieux VSync, je croyais qu'il n'existait plus avec les cartes modernes)

[Ypsos]

Il pourrait déjà faire une mise à jour de son driver de carte graphique (probablement toujours celui de l'installation )

Merci pour la suggestion et réponse.

Driver à jour (sous réserve de vérification que ce soit bien la dernière version de disponibles pour Linux /Nvidia)

Point à clarifier par Odevillée

Pour ta question , Ypsos , des tests ont été effectué ici même et les différences ne sont pas à ce point flagrantes , et pas toujours dans le sens de ce post.

Guy

Certes et c'est bien pour cette cela que la question est posée . Qu'est ce qui se passe pour cette configuration précise ? Avec toutes les copies d'écrans et explications , on va bien finir par trouver à force d'en parler.

@+

[Ypsos]

Merci pour la suggestion et réponse.

Driver à jour (sous réserve de vérification que ce soit bien la dernière version de disponibles pour Linux /Nvidia)

Point à clarifier par Odevillée




Certes et c'est bien pour cette cela que la question est posée . Qu'est ce qui se passe pour cette configuration précise ? Avec toutes les copies d'écrans et explications , on va bien finir par trouver à force d'en parler.

@+

Merci encore à tous

[Ypsos]

Si le maillon faible n'est pas le bus PCIe lui même, ni le Cpu, ni le Gpu, alors "la vérité est ailleurs" !
Il y a alors forcement un composant (hard ou soft) qui attend quelque chose et dont les attentes ne sont pas comptabilisées dans l'affichage de la charge.

Là, je n'ai aucune idée de qui attend, ni de ce qu'il attend, ni de comment le localiser.
Chipset qui attend un signalement ? Carte graphique qui attend la fin de balayage écran ?

Salut

Merci pour tes réponses,

va falloir creuser

(le vieux VSync, je croyais qu'il n'existait plus avec les cartes modernes)

Pour voir s'il est en cause, est ce qu'Odevilée peu désactiver, desinstaller, remplacer cet ancien vSync?

Serait-il possible que le maillon faible serait:

- simplement la prise de connexion du moniteur sur le PC qui ne sait pas faire sortir autant d'info que lance la carte Graphique?
- le taux de balayage, fréquence ou... du moniteur lui même?

@+

[LoseMagnet]

Bonjour,

À chaud après lecture rapide du sujet et de la configuration graphique, est-ce que ça ne viendrait pas du "HDR Anti-Aliasing"?
En testant sur mon vieux X-Plane (en mode démo et non-mis à jour) et les mêmes pilotes Nvidia 331.38, je constate un écroulement des performances entre le FXAA simple et le "4xSSAA+FXAA".

Exemple : Sur une piste au milieu de l'océan (mode démo...) et avec mes préférences graphiques en l'état (HDR et FXAA), mes fps sont à 120+. Si je passe en "4xSSAA+FXAA", je tombe à 50 images/secondes.

Je suis donc passé à Seattle (la seule scène accessible en mode démo) :
- FXAA : 30+ images/s
- 4xSSAA+FXAA : +-10 images/s

Pour info, j'ai aussi : Extrem res, distance à High, les arbres à Overgrown, les objets et les routes à Extreme.

[Ypsos]

Bonjour,

À chaud après lecture rapide du sujet et de la configuration graphique, est-ce que ça ne viendrait pas du "HDR Anti-Aliasing"?
En testant sur mon vieux X-Plane (en mode démo et non-mis à jour) et les mêmes pilotes Nvidia 331.38, je constate un écroulement des performances entre le FXAA simple et le "........

Merci beaucoup pour ces pistes.

Je confirme que l'option "HDR Anti-Aliasing" est décochée.

@+

[LoseMagnet]

On peut tenter de lancer X-Plane en mode "benchmark" pour voir ce que ça donne. Le mode benchmark permet d'ignorer les réglages du fichier de préférence et de compter le nombre d'images/s. Le résultat est disponible à la fin du fichier de log sous la forme :

----------------------------------
FRAMERATE TEST: time=140.6, frames=10001, fps=71.15
GPU LOAD: time=140.6, wait=0.8, load=0.6%
----------------------------------

Pour lancer les benchmarks, il faut ouvrir une console dans le répertoire Xplane, puis lancer en ligne de commande :

Test 1 :
./X-Plane-x86_64 --fps_test=1 --load_smo=Output/replays/test_flight_747.fdr

Test 2 :
./X-Plane-x86_64 --fps_test=2 --load_smo=Output/replays/test_flight_747.fdr

test 3 :
./X-Plane-x86_64 --fps_test=3 --load_smo=Output/replays/test_flight_747.fdr

Eventuellement joindre un exemple de fichier de logs pour voir si il y a quelque chose de particulier...

[Ypsos]

Salut

merci

en test

débriefing par l'intéressé va venir.

@+

[Fred12]

Bonjour,

Je vais suivre avec intérêt ce sujet car c'est le même problème pour moi bien que je sois sur W7 64bits.

Réinstallation ce matin de X-plane 10.25 et toujours le même souci. (FPS<20) avec tous les paramètres X-Plane au plus bas.

[Ypsos]

Bonjour,

Je vais suivre avec intérêt ce sujet car c'est le même problème pour moi bien que je sois sur W7 64bits.

Réinstallation ce matin de X-plane 10.25 et toujours le même souci. (FPS<20) avec tous les paramètres X-Plane au plus bas.

Salut

Je relève que tu as une carte Graphique avec 6G0 de Vram et que tu as une carte d'une autre marque que celle d'Odevillée.

Donc en toute logique, on devrait pouvoir éliminer la carte graphique et son pilote comme maillon faible (à moins que le seul point commun entre les deux cartes étant les 6 Go de Vram : on pourrait avancer l'hypothèse que cela perturberait xPlane qui lui resterait "bloqué "sur 4Go par exemple? : aux spécialistes de répondre).

Hier soir on a volé en réseau. Tout s'est bien passé, Odevillée a trouvé une piste intéressante qui semble prometteuse. Suite aux différentes réponses sur ce forum, il poursuit des tests complémentaires et va confirmer/infirmer le résultat.

@+

[Fred12]

Bonjour,

Oui, c'est exactement le même problème.

Déjà, en changeant d'avion, il y a une différence de d'environ 10FPS entre le baron58 générique d'Xplane et celui de Carenado. De 30 à 35 FPS pour le générique, on passe à 23 à 25 pour celui de Carenado et c'est pareil pour le B777 et l'A320.

Pour les réglages, les pilotes de la carte graphique sont a jour et voici la copie d'écran des réglages :

<a href="http://www.hostingpics.net/viewer.php?id=275657copie.png"><img src="http://img4.hostingpics.net/thumbs/mini_275657copie.png" alt="Heberger image" /></a>

S'il y a d'autres vérifs possibles, on peut essayer.

[guro]

Bonjour

Faudrait voir si tu as le dernier Catalyst et plus particulièrement pour la Radeon 6Go , parce qu'il peut y avoir des problèmes de compatibilité entre les Radeon et les Catalyst (faut aller consulter les forums qui parlent des compatibilités et des dysfonctionnements).

Concernant les fps en fonction du type d'avion, c'est normal avec "un" Carenado" il est connu qu'il "bouffe" du fps.

Gunther

PS. Piste >> http://www.comptoir-hardware.com/act...-126-beta.html