Résultats de la recherche (Page 15) / Pilote-Virtuel.com - Forum de simulation aérienne

Les NVidia GTX970 (env 300 €) consomment 150 W max donc ca passe avec une alimentation 500 W

Il n'y a pas a discuter Vista est un Os mal développé avec beaucoup trop de process qui tournent en parallèle
Reste sous W7

Oui Lagaffe on ne risque pas de cramer le proc à condition qu'en bidouillant dans le BIOS on n'ait pas désactivé la temp max qui arrête le PC. Ceci dit cramer le proc ou le détiorer lentement mais surement le résultat est le même: le proc est mort

Bien d'accord avec toi Neptune puisque chez moi Affinity Marsk a un impact de 1fps et BufferPool aucun impact

Bonjour Patrick
,

qqs infos

1) AffinityMask
En principe c'est 84 pour un 4 coeurs avec HT et 14 sans HT (HT désactivé). Cette ligne sert à répartir la charge de travail du CPU en lui demandant de consacrer le premier coeur aux autres applications en dehors de fsx. Le fait de désactiver l'HT vient de la conception de fsx qui n'exploite pas l'HT. Chez moi, le gain de fps est très marginal: 1 fps avec AffinityMask=14 vs 84.

2) BufferPool
Un peu d'histoire. Lorsque que fsx est sorti en 2006, les concepteurs avait développé une application censée tourner sur les configurations matérielles futures. Au départ, l'application était quasiment injouable sur les configurations basses et moyennes de l'époque. Je me rappelle les posts de l'époque, ça ralait sec. Beaucoup sont restés sur FS2004 qui fonctionnait beaucoup mieux. Les concepteurs tablaient sur une progression future des monocores en termes de rapidité (cadencement des processeurs) plus que sur les avancées des CG.
Ils ont donc créé une mémoire tampon gérée par l'application fsx (Explicit Vertx Buffer ou BufferPool) censée stocker les informations calculées par le CPU avant de les transmettre à la mémoire de la CG. L'idée était de fluidifier l'arrivée des informations afin de ne pas surcharger la CG qui aurait planté.

Finalement, l'évolution a plus porté sur l'augmentation des coeurs que sur leur vitesse. Bref, rapidement il est apparu que le goulot d'étranglement ne se situait pas au niveau de la CG comme anticipé par les concepteurs de fsx mais du côté du CPU incapable de calculer la complexité des décors.

Jesus Altuve, dans un post célébre d'avril 2010, a mis en lumière cette gestion des mémoires de fsx et a proposé deux lignes révolutionnaires à inclure dans fsx.cfg:
[BufferPools]
PoolSize=0

Bref, il a tout simplement supprimé le BufferPool. Pourquoi ? Parce qu'ainsi il libérait une partie du travail du CPU consacrée à la gestion du BufferPool. La conséquence a été une augmentation significative des fps, le CPU se consacrant davantage au calcul des décors. Toutefois, sur certaines configurations, la CG pouvait ne pas suivre compte tenu de cette absence de filtrage. L'application générait alors des artefacts graphiques voire plantait. Sur ces configurations, il a été recommandé de dimensionner la taille du BufferPool d'où
PoolSize= 100M 200 M 40 M,  on a tout trouver comme recommandation...

Plus tar (on pourrait écrire un roman), les configurations récentes avec les i5, i7 se sont dotées de CPU capables de calculer rapidement les images (à l'execption de quelques bouffeurs de fps type ombres, traffic autoroutier,...) , les préconisation de Jesus sont devenues obsolètes. Toutefois, on a gardé quand même l'idée de soulager une partie du travail du CPU non plus en supprimant complètement le BufferPool (qui existe par défaut avec une taille de 4Mb depuis le SP2)  mais en lui affectant  une franchise (Threshold)au delà de laquelle il envoie les informations à la CG. C'est pour cela que l'on trouve maintenant des instructions du type
[BufferPools]
Threshold= 131072 (128 kb) ou 262144 (256 bb) ....
Evidemment que le Threshold tend vers 0, on se rapproche de PoolSize=0 la franchise devenant de plus en plus basse.

Chez moi, je ne note pas de différence entre ces différents niveaux de franchises. Personnellement je n'ai plus de ligne [BufferPools] dans mon fsx.cfg

James

Juste une précision l'oc d'un proc doit se faire avec le max de précaution sous peine de cramer le proc
Il y a des tutos mais il est indispensable d'avoir occt pour vérifier que le prix ne chauffe pas

Ca me rapelle la GT240 sur mon PC de 2009? J'avais vu 2Go de mémoire sur l'étiquette  !! Et je m'étais précipité

...Résultat fps 6 sur le tarmack

Du coup je doublais les fps avec une GT8800 1GO

Depuis je monte mes configs

Oui absolument même si FSX c'est la règle du 80/20 qui s'applique (80% proc / 20% CG) il faut quand même un CG qui tienne la route. Avec un GT640 c'est 20 fps maxi et 8 fps sur les scènes lourdes.

Au fait un i7 4770 c'est 4 coeurs physiques et 8 en HT

Si j'ai l'occasion je ferais le même test que toi LSGG 05 / Baron FSX avec tout à fond (ca sert à rien mais bon il faut des périmètres comparables) avec DX9 puis DX10. Fraudra aussi que je désactive Geneve de FSDream scene magnifique que je conseille.

Autre chose qui concerne la mesure des fps

Souvent les fps indiqués par fsx ne sont pas fiables. Ils fluctuent beaucoup . Il faut utiliser FRAPS qui mesure réellement le nb d'images par seconde à l'écran

DX10 fait baisser les FPS ???
Ca sent quand même le Venetubo quand je vois le Fiber Frame Time Fraction qui n'est pas d'origine de fsx.cfg !
T'as essayé de voir ce qua ça donne avec un fsx.cfg tout neuf ?

Pour les 2 lignes, tu sauvegardes ton fsx.cgf, tu les vires et si ca marche pas tu remets le fsx.cfg sauvegardé

CQFD

Bonjour Michel

eh bien il faut suivre la reco de Totobarjo.

En gros, il ne sert à rien de dire "mon FSX plante. Pouvez-vous m'aider ?"

Avant tout, il faut en chercher la raison avant de trouver la solution. Donc consulter le journal des évènements, rechercher le module défaillant, puis essayer de réparer