XPLANE 10: paramétrages graphiques

[Spock1]

Faudrait que je prenne le temps d'expliquer, mais ce n'est pas une bonne comparaison.
PhM

A mon avis Austin a voulu dire qu'un cœur peut faire tout le travail, mais neuf cœurs ne le peuvent pas, mais il ne peu pas te le dire comme cela, vu que c'était un argument de vente,
bref 4 cœurs c'est peut être même de trop,
n'oublions pas que pour un jeu, c'est la carte vidéo qui est l'élément le plus important,

Le problème des multi cœurs c'est que lorsqu'ils fonctionnent tous,
la température du processeur augmente beaucoup,
ce qui oblige la machine a réduire la fréquence de fonctionnement,
qui justement est le paramètre le plus important pour les fps.
(argument a verifier)

[Pascal]

Pour mieux expliquer, il faut entrer dans des détails très techniques. Je vais un peu résumer :

Les 4 principaux composants intervenant dans notre simu sont :

- le nombre de cœurs
Plus le nombre de cœurs sera élevé, plus le traitement sera rapide ... si l'application est parfaitement scindée en de multiples "tâches" qui peuvent s'exécuter en parallèle.
Mais scinder une application en tâches l'alourdit : il faut gérer les collisions d'accès multiples aux mêmes données par les tâches, du temps est perdu chaque fois qu'on bascule d'une tâche vers une autre, des tâches sont extrêmement difficiles à fractionner, etc...
Du côté matériel augmenter le nombre de cœurs dans un même processeur a aussi des limites car lorsque plusieurs coeurs accèdent à la même mémoire commune, un étranglement se fait sur ces accès mémoires : ils ne peuvent pas y accéder tous en même temps, c'est chacun son tour.

-> Manifestement, X-plane 10 utilise mieux les cœurs que X-Plane 9, surtout lorsqu'il y a beaucoup d'avions actifs, mais la version actuelle n'est pas encore au niveau de ce qui pourrait en être attendu.

- la vitesse des coeurs
Plus la vitesse de chaque cœur est importante, plus le traitement sera rapide ... à condition que l'ensemble des périphériques connectés au processeur suivent. Il faut que la carte mère, la mémoire, les bus de connexions, les cartes périphériques, etc... soient homogènes : c'est le maillon faible qui va limiter l'ensemble de la machine.
Point positif : les fabricants intègrent de plus en plus un système d'ajustement dynamique de la fréquence en fonction du nombre de cœurs utilisés, ce qui permet de récupérer de la vitesse quand moins de cœurs sont actifs.

-> Si X-plane peut exploiter plusieurs cœurs, ses performances sont directement liées à la fréquence processeur, surtout pour les tâches qui s'exécutent sur un seul cœur. Augmenter le nombre de cœurs ne permet pas de diminuer leur fréquence.

- la carte graphique
La carte graphique assure la construction de l'image à partir des points qui délimitent les triangles, des textures, des éclairages, etc.... Il faut impérativement qu'elle comporte assez de mémoire pour contenir toutes les textures utilisées à chaque image, plus tous les points délimitant les triangles, plus les zones de calcul interne, etc... faute de quoi le processeur devra passer beaucoup de temps à lui envoyer les textures manquantes pour chaque image. dans ce dernier cas, le frame rate s'effondre brusquement.

-> d'après les essais, on peut considérer qu'une carte avec 1 à 1,5 Go de mémoire devrait permettre le fonctionnement correct de X-Plane 9 comme 10 dans la grosse majorité des cas. La fenêtre "Paramètres graphique" de X-plane affiche combien de mémoire vidéo est consommée par X-Plane (pour les textures seulement), mais n'oubliez pas que si vous avez d'autres tâches en arrière-plan qui comportent des fenêtres actives, chacune grignote aussi des morceaux de mémoire vidéo, et d'autant plus qu'elle affiche de la 3D (je pense particulièrement à Google Earth).
J'ai l'impression que la puissance de la carte graphique n'est actuellement pas un frein majeur pour X-Plane (9 ou 10), au moins pour les cartes qui ne sont pas trop anciennes (je ne saurait pas fixer une limite exacte) et lorsqu'elles génèrent une image de taille raisonnable, par exemple inférieure ou égale à 1920x1080 (ce qui est déjà beaucoup, presque 4 millions de pixels).

- Le bus de la carte graphique
Il permet la transmission des données entre le processeur et la carte vidéo. Normalement, les textures et fichiers associés (normales, réflexions, tesselation, etc) ne sont chargées qu'une fois dans la carte graphique (voir ci-dessus).
Par contre, pour chaque image à générer, tous les points qui délimitent les surfaces doivent lui être être envoyés. Ils sont plusieurs centaines de milliers, voire des millions, avec souvent 5 coordonnées par point. Toutes ces informations transitent par un seul bus, en général au format PCI Express 2.

Trois solutions existent pour diminuer son encombrement
- utiliser plusieurs cartes graphiques en "SLI" ou "Crossfire". Mais pour fonctionner correctement, cette configuration impose des contraintes logicielles qui ne sont pas encore supportées par X-Plane. Aucun gain ne sera constaté s'il faut envoyer le même volume de données à plusieurs cartes (en parallèle) qu'à une seule.
- utiliser un bus plus rapide. Le bus PCI Express III est sortit, des cartes mères sorties depuis novembre 2011 le supportent, les cartes vidéo avec ce bus commencent à apparaitre (AMD Radeon HD 7970).
- réduire le volume de données envoyés pour construire chaque image par élimination des trop petites surfaces, des faces et objets cachées, réutilisation de groupes de points (objets), etc... Cela demande la mise en place de calculs lourds à faire par le processeur, qui seraient souvent traités plus efficacement par la carte graphique. Mais c'est un compromis... Je n'ai aucune idée de ce qui est fait dans X-Plane à ce niveau et de ce qui serait améliorable.

-> actuellement ce bus me semble être LE goulot d'étranglement de X-Plane sur les machines haut de gamme. A notre niveau on ne peut qu'espérer que la phase "optimisation" de X-Plane 10 ira dans le bon sens... et éventuellement faire remonter nos constats.

Pascal

[PhM]

Il faudrait reprendre tout à zéro ou presque et ça je ne pense pas qu'Austin en est envie

Je pense également que le code existant n'est absolument pas prêt pour être parallélisé. Je l'ai vécu sur un projet, si ce n'est pas pensé parallèle dès le début il y a beaucoup à faire pour le rendre parallélisable. Et, manque de bol, à par quelques illuminés dans des université où des industries bien précises, personne ne pense parallèle.

PhM

[PhM]

J'ajoute mon grain de sel :

- le nombre de cœurs
Plus le nombre de cœurs sera élevé, plus le traitement sera rapide ... si l'application est parfaitement scindée en de multiples "tâches" qui peuvent s'exécuter en parallèle.

En fait le gain théorique est fonction de la proportion de "séquentialité" restante dans l'ensemble du processus. Voir le graphique ici. La ligne verte est l'idéal, on gagne de façon linéaire en fonction du nombre de processeurs.

On voit que s'il reste la moitié du processus qui est séquentiel on peut obtenir au mieux un gain d'un peu moins de deux fois avec dix processeurs ! Si seulement un dixième du processus est séquentiel le gain est bien meilleur. Par exemple avec mes six processeurs le gain serait de quatre fois.

Attention : ce graphique ne tient pas du tout compte des particularités matérielles telles que les mémoires caches par exemple. Mal paralléliser peut détruire le gain en introduisant une pollutions constantes des mémoires caches.

Mais scinder une application en tâches l'alourdit : il faut gérer les collisions d'accès multiples aux mêmes données par les tâches,

Il existe des techniques permettant de minimiser la perte de temps lors d'accès parallèles. Dans le cas où rien n'a été étudié alors oui cela ajoute une lourdeur supplémentaire, c'est ce qui arrive lorsque l'on parallélise une application écrite pour un fonctionnement séquentiel sans la repenser en profondeur.

du temps est perdu chaque fois qu'on bascule d'une tâche vers une autre,

C'est pour cette raison qu'il vaut mieux choisir une architecture où l'on minimise les changements de contexte. Utiliser des threads est la solution communément employée, probablement parce que c'est le niveau de parallélisation minimum connu par la majorité des programmeurs. Mais cela implique justement des changements de contexte qui peuvent être couteux. Il existe d'autres techniques utilisant un nombre minimal, voire nul, de changements de contexte.

... un étranglement se fait sur ces accès mémoires : ils ne peuvent pas y accéder tous en même temps, c'est chacun son tour.

Je suppose que tu parles des accès à la mémoire principale. C'est effectivement un point important. Même pour une machine ne disposant que d'un processeur, aux vitesses actuelles la mémoire ne peut pas fournir aussi vite que le processeur peut bouffer des données.

C'est pour éviter cet étranglement qu'il y a plusieurs niveaux de mémoire cache, le processeur n'accède jamais directement à la mémoire principale, il n'accède qu'à la cache de niveau 1 cf ici. Les unités qui font le travail dans le processeur sont sur la droite du graphique, on voit qu'elles n'ont accès aux données qu'à travers la cache d'instructions de niveau 1 (petite flèche de gauche à droite entre L1 I-cache et Fetch), et la cache de données de niveau 1 à travers la load-store queue (Grosse flèche en bas à gauche entre Load-Store Queue et AGU). Les accès en mémoire principale se font à travers le bloc vert sous la cache de niveau 3.

Chaque processeur peut donc accéder en parallèle aux données dans les caches, encore faut-il avoir conscience de ce fonctionnement pour ne pas ruiner les avantages qu'il apporte. Malheureusement beaucoup des techniques logicielles les plus utilisées ruinent ces gains. Certes elles permettent d'arriver facilement à quelque chose qui fonctionne, mais dans le cas d'application temps réel intensives, comme X-Plane, elle ne sont pas les meilleures.

-> Manifestement, X-plane 10 utilise mieux les cœurs que X-Plane 9, surtout lorsqu'il y a beaucoup d'avions actifs, mais la version actuelle n'est pas encore au niveau de ce qui pourrait en être attendu.

Les tests que j'ai fait à ce niveau montrent même que la v10 est moins bonne que la v9 jusqu'à un certain nombre d'avions. Ils montrent que l'augmentation du temps de rendu graphique est linéaire en fonction du nombre d'avions ce qui indique que ce traitement est majoritairement séquentiel. Ce n'est effectivement pas au niveau de ce qui pourrait en être attendu. Ce traitement étant facilement parallélisable soit c'est mal fait, soit autre chose ruine les gains.

...-> Si X-plane peut exploiter plusieurs cœurs, ses performances sont directement liées à la fréquence processeur, surtout pour les tâches qui s'exécutent sur un seul cœur. Augmenter le nombre de cœurs ne permet pas de diminuer leur fréquence.

Euh ? Pouvez répéter la question ? Là je ne comprends pas.

Par contre, pour chaque image à générer, tous les points qui délimitent les surfaces doivent lui être être envoyés. Ils sont plusieurs centaines de milliers, voire des millions, avec souvent 5 coordonnées par point.

Pourquoi devrait-on transférer plusieurs fois ce qui ne change pas ? Le modèle issu de notre fichier obj ne change pas, seule la façon dont il sera projeté sur le plan de l'écran change en fonction de la position et de l'orientation de la caméra. Et cette transformation est faite dans le GPU à partir de calculs matriciels dans les vertex shaders. Tant qu'un objet est dans le view frustrum il devrait rester en mémoire vidéo justement parce qu'il est utilisé dans le rendu. D'accord openGL n'est pas trop transparent sur sa gestion de mémoire et cela oblige le programmeur a penser comment faire en sorte qu'il n'aille pas nous sortir ce qui est essentiel de cette mémoire vidéo, cela oblige à tenir compte de la carte avec laquelle on travaille. C'est sur que tout balancer à openGL en se reportant sur la mémoire virtuelle pour que ça se passe bien est plus que chercher les ennuis.

- utiliser un bus plus rapide. Le bus PCI Express III est sortit, des cartes mères sorties depuis novembre 2011 le supportent, les cartes vidéo avec ce bus commencent à apparaitre (AMD Radeon HD 7970).

Ca ne sera qu'une solution temporaire. Tout est extrêmement plus rapide et pourtant on arrive toujours à ne pas avoir assez de vitesse.

- réduire le volume de données envoyés pour construire chaque image par élimination des trop petites surfaces, des faces et objets cachées, réutilisation de groupes de points (objets), etc... Cela demande la mise en place de calculs lourds à faire par le processeur, qui seraient souvent traités plus efficacement par la carte graphique. Mais c'est un compromis... Je n'ai aucune idée de ce qui est fait dans X-Plane à ce niveau et de ce qui serait améliorable.

C'est LE point à considérer en premier lieu. Il faut chercher à utiliser au mieux plutôt que demander du matériel plus rapide. Ce n'est pas tant que cela apporte des calculs lourds, c'est surtout qu'il faut penser l'architecture du logiciel dans ce sens. A mon avis cela n'a jamais été le cas pour X-Plane. Austin a fait son simulateur avec ses méthodes plutôt bordéliques, et je pense que c'est plutôt un patchwork de chose modifiées au fil des versions.

-> actuellement ce bus me semble être LE goulot d'étranglement de X-Plane sur les machines haut de gamme. A notre niveau on ne peut qu'espérer que la phase "optimisation" de X-Plane 10 ira dans le bon sens... et éventuellement faire remonter nos constats.

Je pense également que X-Plane est API / IO bound, c'est à dire que soit il passe trop de temps à faire des appels openGL, soit il n'utilise pas correctement le bus PCI et ne profite pas de sa vitesse, soit il cherche à transférer beaucoup trop de chose et atteint les limites. Mais changer cela ne se fait pas au niveau de l'optimisation mais à celui de la conception.

On aimerais tellement que notre X-Plane pète le feu comme pas possible .

PhM

[Sarkis]

J'ajoute mon grain de sel :


C'est LE point à considérer en premier lieu. Il faut chercher à utiliser au mieux plutôt que demander du matériel plus rapide. Ce n'est pas tant que cela apporte des calculs lourds, c'est surtout qu'il faut penser l'architecture du logiciel dans ce sens. A mon avis cela n'a jamais été le cas pour X-Plane. Austin a fait son simulateur avec ses méthodes plutôt bordéliques, et je pense que c'est plutôt un patchwork de chose modifiées au fil des versions.


PhM

Je voudrais apporter mon sentiment sur cette question. J'ai assisté pendant les vacances de Noël, à une démo du jeu "Lockon Flaming Clift 2" sur un PC. Je n'aime pas les jeux de guerre. J'ai été bluffé par les possibliltés graphiques de ce logiciel qui ne mettent pas à genoux un PC moyen. Paysage, nuages, simulation de flou de l'air chaud de la sortie des tuyères. Atc et possibilité de de demander des actions plutôt primaires mais elles existent. Comme sur Xplane il y a des addonn qui apportent des plus sur le plan graphique : nuages comme ceci, paysage comme cela, etc en plus chiadé m'a-t-il semblé.
En observant les possibilités de ce soft qui doit être plutôt moyen (je ne connais rien en simul aérienne sur PC, j'ai abandonné FS lorsqu'il a abandonné le Mac) , je finis par me demander si Austin n'aurait pas intérêt à ouvrir sa petite entreprise à d'autres programmeurs et/où ouvrir Xplane à des addons qui le modifient plus en profondeur pour gagner en qualité.

[lebelge]

C'est vrais que quand je vois, sur la console de jeux de mon fils (une PS3 qui doit avoir maintenant plus de 4 ans), ils ont 10 ans d'avance sur X-Plane en terme de fluidité et de qualité d'images... Mais bon, pour le moment, en simulateur de vol sur PC/MAC ou Linux, y pas beaucoup mieux me semble-t'il ?

lebelge (qui remercie au passage nos deux grands experts "hardware" de nous donner autant d'information TRES intéressantes, merci à eux)

[Pascal]

-> Si X-plane peut exploiter plusieurs cœurs, ses performances sont directement liées à la fréquence processeur, surtout pour les tâches qui s'exécutent sur un seul cœur. Augmenter le nombre de cœurs ne permet pas de diminuer leur fréquence.

Euh ? Pouvez répéter la question ? Là je ne comprends pas.

Ce n'est pas parce qu'on vise l'achat un processeur avec plus de cœurs qu'on pourrait faire quelques économies sur sa fréquence de fonctionnement.
X-Plane comporte encore trop de sections non parallélisées qui n'utilisent qu'un seul cœur, il faut donc viser un processeur dont la fréquence de fonctionnement est aussi élevée que possible ... avec les contraintes du porte-monnaie.

J'irai même jusqu'à avancer qu'en l'état actuel de X-Plane, à investissement égal il vaut mieux privilégier la fréquence du processeur sur le nombre de cœurs, avec quand même une limite basse à 4 cœurs (ou 2 cœurs hyper-threading)...

Pascal

[ecoflyer]

Merci a vous pour ces infos, les choses sont mieux comprises.
Ayant un mal fou à vendre mon Mac, je vais etre obligé de le garder, je souhaiterais savoir si parmi vous certains ont constaté des différences de performances que l'on soit sur lion, windows 7 ou Linux?

[PhM]

Ce n'est pas parce qu'on vise l'achat un processeur avec plus de cœurs qu'on pourrait faire quelques économies sur sa fréquence de fonctionnement.

Ok, maintenant c'est clair.

PhM

[beber]

Merci a vous pour ces infos, les choses sont mieux comprises.
Ayant un mal fou à vendre mon Mac, je vais etre obligé de le garder, je souhaiterais savoir si parmi vous certains ont constaté des différences de performances que l'on soit sur lion, windows 7 ou Linux?

Tous ceux qui ont essayé semblent dire que l'utilisation d'X-Plane sur un Mac via une partition Windows (bootcamp) offre de meilleures performances... mais c'était avec X-Plane 9, avec la nouvelle gestion matérielle d'X-Plane 10 ça reste à tester.

[ecoflyer]

Merci Beber,

Je vais essayer, et je vous tiens informé.

[ecoflyer]

hello à tous.
Alors, mes essais sont une véritable cata sous win7.
Tout d'abord le temps de chargement de x-plane est boublé.
Quant aux perfos, elles semblent identiques.
Je ne sais que trop penser.
Je vais essayer de vendre mon Mac, sans le brader
À+

[Sarkis]

On ne sait jamais... Apple pourrait se décider à améliorer ses pilotes graphiques : MacBidouille.com - Bidouille hardware sur Mac - Apple pourrait grandement améliorer ses pilotes graphiques
Je sais, je ne remonte pas le moral des troupes macusers dont je suis depuis longtemps. Mais je n'aurai pas les vendre.
Question à écoflyer : as-tu fait la mise à jour de DirectX sous Bootcamp ? D'après des amis ça améliore beaucoup la fluidité. D'ailleurs on aimerait avoir un DirectX Mac...Bons vols.

[solon]

Ce serait dommage de vendre ton mac juste pour un logiciel qui ne donne pas entière satisfaction.

Et je suis étonné aussi que tu n'arrives à faire tourner correctement xplane 10 (qui n'est quand même pas une révolution graphique) sur bootcamp. J'ai installé la démo sur mac OSX. Première chose à faire virer la scène par défaut (qui est, autant le dire, une catastrophe tant visuelle qu'en terme d'optimisation) et tenter l'expérience avec de très belles scènes d'XPFR.

Ensuite bien vérifier tes réglages, si tu as déjà x-plane 9, commences par remettre les même paramètres, puis fais varier. Et l'autre point à vérifier les drivers et directX (il existe un logiciel dédié pour cela). J'arrive à faire tourner starcraft 2 sur bootcamp très correctement avec un bon rendu, je ne vois pas pourquoi xplane ne passerait pas, sauf si les paramètres sont très élevés.

De mon côté le gros problème sur mon MBP qui me fait rester sur la version 9 est surtout que la version X met les ventilo aux taqués, soit à 6200 tr/min, assez affreux et énervant au bout de quelques minutes de jeu.

AH! si Apple pouvait vraiment optimiser ses pilotes graphiques !!!!! ce serait enfin une bonne nouvelle.

Maintenant ce qui serait pas mal, c'est que nos amis ayant des MBP et satisfaits d'x-plane 10, nous postent une impression écran de leur page de paramètres graphiques vu qu'on est sur des modèles de machines plutôt standards et normés (contrairement aux autres PC).

[ecoflyer]

Merci à tous les deux. Bonnes idées que je vais tester.
J'ai x-plane 9, mais je trouve que x-plane 10 avec le HDR est chouette.
Justement, c'est ce fameux HDR qui me pose problème. Sans cette option j'ai de bonnes perfos.
Je confirme également que les ventillos tournent à fond.
En parlant de pilotes ATI sous bootcamp, utilisez vous le ATI tray ou laissez vous le systeme gérer?