Essai effectué sur Orly (Aerosoft) avec UT2 (70% et 50%) avec le PMDG JS4100

Résultat au décollage : Bof ! La moyenne se situe aux alentours de 14-15 fps, à vue de nez avec des chutes (brèves mais quand même) à 8-9 fps.
La fluidité n'est toujours pas au rendez vous, I7 OC ou non, malgrè l'optimisation du FSX.CFG.
(J'ai optimisé mon cfg sur la même scène, sans UT2, et je tourne à 18-20 fps. Même là, pas de quoi sauter de joie ....)

Avec mon ancien Quad Core OC à 3.9GHz, j'avais des résultats comparables. C'est incroyable. Sur ces scènes, lourdes, je n'observe pas vraiment d'amélioration notable... Peut-être des chutes de fps moins fréquentes ?.... Le ressenti, en tous cas est un peu le même. C'est tout juste un peu plus "jouable", "confortable", mais ç'est toujours loin très loin d'être fluide.
Après mes essais sur Nice ces derniers jours, où j'avais de très bonnes perfs, ça me refroidit un peu ....

Si l'un d'entre vous à la même scène, le même zingue et UT2, une comparaison serait interessante .....

Dernière modification par lumat (22-06-2011 16:42:05)

Hello,
Lumat, je ne comprend pas tes résultats sur fsx, pourrai tu me donner le descriptif complet de ton installe.
Sans oc le 2600 K et en restant raisonnable dans les réglages, fsx tourne bien mieux que ça.
a+
steph

oki,
C'est quoi ta carte mère ? La carte graphique pour moi n'est pas en cause, sauf peu etre si c'est la gamme SE et encore pas sur,  par contre attention les pilotes sont diffèrent.  Tes réglages sont pas gourmand dans ton fsx, je pencherais plus sur un problème dans le fichier cfg. je vais mettre mon cfg sur ton poste, j'ai casi rien changé et mes réglages fsx sont au max, je tourne a 60 fps (limité à 90) en moyenne et 30 sur du lourd environs.

Dernière modification par steph738 (22-06-2011 22:55:52)

Mystère résolut : les saccades avec FPSlimiter venaient que j’avais 30 comme limitateur et non 90 pour trois écrans. Merci lumat c'est grâce à ta remarque que je l'ai vu.
Apparemment cela ne change pas grand chose mais comme c'est préconisé par les réglages de Jesus je le garde.

Steph il me semble qe tu as aussi FPSSlimiter et sauf erreur de ma part tu as ton config la limitation à 70 FPs au lieu de illimité ?

Amicalement

yankeeromeo a écrit:

Hey les Amis,
Impossible ne visionner les pics de Yann Solo concernant Orbx, suis-je seul ?
Cheers.

Hier je voyais les images sans problème, là je ne les vois plus.

bonjour !

J'étais absent quelques jours. Mais que Yann Solo, mais aussi lumat et Zigou, soient remerciés pour leurs bonnes adresses. Conversation passionnante. Vous faites réellement envie d'y aller ( à l'O.C...).

lol, un avis peu diplomate mais que je partage aussi

Non, tout n'est pas à droite. Et, même si je ne regrette pas l'I7 à 4.7Ghz, je suis un tantinet déçu par la différence de performances obtenues par rapport à mon Quad/DDR2 Oc à 3.9Ghz. C'est mieux, un peu plus fluide mais disons que je m'attendais à quelque chose de plus marquant.

Il faut dire que mes tests sont faits sur du lourd. Mega Airport Orly + PMDG J41, c'est pas ce qui se fait de plus light.

C'est vrai qu'avec le Quad, vers Nice, je n'ai jamais eu des fps à plus de 100. Je plafonnais à 70-80. Un taux pareil ne sert à rien mais c'est juste une remarque qui prouve quand même une différence entre les deux proc.
Le jour où on aura ces taux de fps sur orly, CDG ou Heathrow ........

Cela me fait penser: ça fait quand même une sacrée différence entre les 2 scènes d'Aerosoft, Nice et Orly avec le J41. Grosso modo maxi 70fps d'un côté et 22fps de l'autre, c'est dingue ça ..... Non ? Vous ne trouvez pas ça bizarre ?

Dernière modification par lumat (23-06-2011 18:25:29)

lumat a écrit:

[Display]
TEXTURE_BANDWIDTH_MULT=70 --------------- meilleure fluidité par rapport aux 40. Plus haut n'apporte rien chez moi
UPPER_FRAMERATE_LIMIT=0
WideViewAspect=True

Je limite mes fps donc je n'ai pas testé moi même, mais en fps illimité, il semblerait que TEXTURE_BANDWIDTH_MULT ne soit pas utilisé, à la place, il faut utiliser TextureMaxLoad (mais encore une fois, je n'ai pas vérifié moi même cette info).

a+

Luc,

n'ayant pas le même proc, je ne prendrai donc pas part à vos analyses.

Néanmoins, deux petits points sur les quels je voudrai te tuyauter...

lumat a écrit:

[BufferPools]
UsePools=0 ------------------ J'ai de meilleurs résultat avec cette combinaison qu'avec Poolsize =0
RejectThreshold=131072

Là, c'est normal!....
UsePool : c'est le commutateur [ON/OFF] qui te permets d'utiliser ou pas les 'Explicit vertex buffers'

Dans le cas ou tu l'utilises (UsePools=1), là tu doit tailler un buffert...... C'est le rôle de PoolSize (ex. PoolSize=15000000).

Par contre Poolsize =0, n'as aucun sens.

lumat a écrit:

[BufferPools]
En revanche, je force la synchro vertical via Nvidia Inspector et j'utilise FPS_limiter à 45fps
P

Pendant toute ta phase de test, je te conseille de ne pas mettre de syncho verticale (nul part!...).
Les phénomènes sont déjà suffisamment compliqués à analyser sans avoir le code de FSX, qu'il faut éviter de s'en rajouter une sur couche avec ceux de la synchro....

lumat regarde la traduction de Jesus (lien sur le forum) il explique le pourquoi et le rôle du core 0 avec le 14.
A+++

lumat a écrit:

Une question me vient à l'esprit
[JOBSCHEDULER]
AffinityMask=14

Pourquoi 14 ?
14 oblige FSX à utiliser les coeurs 2, 3 et 4
Donc
Pourquoi pas 15 et le faire travailler sur les 4 coeurs ?
Surtout si aucun autre programme ne fonctionne en fond

Afin de corriger la non prise en compte du multi core de la version RTM de FSX, les équipes ont fait un super boulot de répartition de tâches dans le SP1 pour corriger cette erreur stratégique.

Pour arriver à cela, ils ont utilisé deux spécificités du scheduler. A savoir :
- Thread Affinity
Qui force un tread à s'excecuter sur un sous ensemble spécifique de processeurs.
Le réglage de ce sous ensemble se fait par un masque appelé : affinity mask



- Thread Ideal Processor
Demande au scheduler d'utliser un core particulier (s'il le peut...) pour faire tourner le thread considéré.

Concrétement dans FSX, ils ont "batché" un certain nombre de tâches et les ont réparties sur d'autres cores (si ceux ci sont présent sur la machine ... Of course!...).
Ils ont également "scotché" le thread principal (fsx.exe) sur le premier core de l'affintyMask.

Dans cette grosse opération de répartition, est ce par oubli ou il y a t'il une logique, là je n'ai pas trouvé la réponse.... Il y a donc  3 threads qui non pas bénéficiés de l'utilisation de ces deux commandes et qui de ce fait laissent le scheduler travailler nativement.
Contrairement à ce que dit Jesus Altuve sur ces threads, ils ne sont pas "scotchés" au core 0, En fonction du paramétrage choisi, même sur un 4 cores, ont peu très bien voir leurs répartitions se faire par le scheduler.

Par contre, je ne suis pas réellement d'accord avec lui sur la meilleur logique d'utilisation de notre produit préféré. Pour moi, le produit tourne plus efficacement en laissant tous les cores travailler (sans Affinitymask).

Dernière modification par Ptipilot (07-04-2012 11:26:53)

lumat a écrit:

zigou a écrit:

lumat a écrit:

[Display]
TEXTURE_BANDWIDTH_MULT=70 --------------- meilleure fluidité par rapport aux 40. Plus haut n'apporte rien chez moi
UPPER_FRAMERATE_LIMIT=0
WideViewAspect=True

Je limite mes fps donc je n'ai pas testé moi même, mais en fps illimité, il semblerait que TEXTURE_BANDWIDTH_MULT ne soit pas utilisé, à la place, il faut utiliser TextureMaxLoad (mais encore une fois, je n'ai pas vérifié moi même cette info).

a+

A vérifier effectivement. C'est important. Es tu sûr que les pramètres "fps illimités" d'une part et  TEXTURE_BANDWIDTH_MULT ou TextureMaxLoad d'autres part soient liés ?

Sur ? non, je l'ai dit.
Je me base uniquement sur les deux formules de calculs donnees par jesus (d'ou les sort il ? sont elles fiables ? aucune idee):

MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMIT

ou si fps illimite

MAX_TEXTURE_DATA = TEXTURE_MAX_LOAD * TextureMaxLoad

fabrice