Voilà plusieurs mois que les 3 vidéo-projecteurs Full HD (1920 x 1080) sont en place, animés par 2 PCs, l’un, le serveur P3D, qui affiche la vue de face, et l’autre, client P3D synchronisé avec le serveur via Wideview, qui affiche les vues de doite et de gauche (voir “3 vdp – v2“).
Avec un peu de recul, quelques défauts sporadiques plutôt mineurs restent cependant présents, dont principalement des désynchronisations partielles au niveau de l’affichage des couches nuageuses, ainsi que de très légers “lags” entre vue de face et vues latérales lors de changements d’attitude un peu vifs.
La répartition des vues entre les 2 PC est vraisemblablement à l’origine de ces phénomènes, mais la nécessité de maintenir un niveau de fps d’au moins 25 à 30 impose le recours à au moins 2 PCs pour y parvenir, puissance maximale oblige …
Mais en ce début d’année 2022 les performances de ces engins continuent de progresser sensiblement, et l’envie d’en profiter m’a saisi : est-il possible de regrouper la production des 3 vues, face, gauche et droite, sur un seul PC tout en maintenant le niveau de fps ?
1 - Préambule :
Actuellement, le serveur P3D, qui produit la vue de face, abrite également le serveur A320 FMGS ainsi que les applications de gestion des divers équipements matériel (SIOC et Profiler) ; il est animé par un 7700K et une carte graphique GTX 1070, configuration haut de gamme il n’y a pas si longtemps !
Le client P3D est exclusivement réservé à la production des 2 vues latérales, il est équipé d’un 4790K et d’une seconde GTX 1070.
Les performances des 2 machines sont bien équilibrées, le serveur produit un fps de l’ordre 30 (ou plus) sauf aéroport très chargé, et le client, légèrement plus performant, “suit” sans difficulté.
Une des caractéristiques très favorable de cette configuration est de réunir le serveur P3D, le serveur A320 FMGS et les applis SIOC et Profiler, dont les interactions sont fortes et gagnent à avoir lieu au sein d’une seule machine.
Pour ce qui est du client, la question est de savoir s’il est possible, avec les composants les plus récents, de produire non pas les 2 vues latérales, mais plutôt les 3 vues : une approche grossière est de considérer qu’il est nécessaire de disposer d’un surplus de performance d’au moins 50%, mais des considérations de répartition des charges entre coeurs/type de coeur CPU et carte graphique sont également très impactantes et difficiles à avoir !
2- Le choix de l'architecture :
Au regard de ce qui précède, je vais conserver le serveur tel quel, mais P3D n’aura plus, comme seul rôle, que de faire voler l’avion, et sera déchargé de la production de la vue de face destinée à être projetée : il produira une vue de face “dummy”, mais avec des paramètres graphiques réduits à leur minimum, de façon à réduire drastiquement la charge correspondante.
Les données de synchronisation que Wideview partagera avec le client seront donc bien produites.
Le client P3D sera en charge de produire les 3 vues, sur la base des données de synchronisation émises par le serveur : mon pari (raisonnable de mon point de vue), est que le fait qu’une seule instance de P3D soit à la maneuvre assurera d’une part un parfait synchronisme des couches nuageuses (la même image vue sous différents angles), et d’autre part la disparition du lag entre les vues.
Pratiquement, ce choix apporte quelques avantages latéraux non négligeables :
– Le vdp en charge de la vue de face, initialement connecté sur le serveur, est désormais redirigé vers le client ; il faut dont rajouter un écran sur le serveur, ce qui rendra bien plus confortable le travail sur cette machine (travailler sur un écran courbe dont la surface est en partie cachée par le shell n’est pas pratique).
– De plus, beaucoup des taches d’installation/mise au point/maintenance pourront être réalisées sans que les vdp et le client P3D ne soient actifs et sans être installé dans le simulateur, ce qui est également bien plus pratique.
– Le “warping” des vues, indispensable pour corriger les déformations de la projection sur écran courbe, sera désormais réalisé par une seule instance de Fly Elise immersive display (au lieu de 2), ce qui d’une part permet de réaliser l’économie d’une licence, et d’autre part permet des ajustements entre les 3 vues qui n’étaient pas possibles.
Au final, il faut toujours 3 PCs pour animer le simulateur, mais dans un bien meilleur confort, avec une architecture conceptuellement plus simple et donc facile à maitriser, et bien sur une qualité attendue à la hausse !
3 - Le choix des composants :
Là est le noeud de l’affaire ! mais en même temps j’ai une idée fortement préconcue, c’est elle qui m’a déterminé à entreprendre cette évolution … idée fondée sur les récentes propositions de Intel et de Nvidia.
Un rapide examen comparatif des benchmarks CPU et carte graphique entre mes composants actuels et les composants cibles montre que le gain de performance recherché (au moins 50%) est possible, mais non garanti compte tenu des multiples inconnues concernant l’utilisation par P3D des diverses ressources et nouveautés apportées par ces nouveaux composants.
La CPU : mon choix se porte sur un i9-12900K : 8 coeurs haute performance, 8 coeurs haute efficacité énergétique, fréquence pouvant monter à 5,3 GHz ; cette puce a des caractéristiques décoiffantes, mais présente l’inconvénient de constituer un véritable radiateur d’appoint : boitier très bien ventilé et ventirad ultra-performant obligés.
La carte graphique : je n’ai pas hésité longtemps entre GTX 3080 et GTX 3090, j’ai opté pour une GTX 3080 Ti ; la différence de performance entre les 2 cartes est faible, la différence de prix exorbitante ; pas loin de 30 milliards de transistors, c’est ahurissant, la contre-partie est la même que pour la CPU, centrale électrique exigée à proximité !!
Pour accompagner le tout et ne pas rester de mise, Noctua NH-D15, 2×16 Go de ram, SSD NVMe 1 To, alimentation 1000w, … et Windows 10 pro.
4 - Nouvelle architecture :
Remplacement de l’ancien client MC0 par MC5 :
L’architecture logiciel reste riche.
Devant la relative lourdeur du séquencement des opérations lors du démarrage ou de l’arrêt du simu, j’ai finalement décidé de réaliser une application “AutoSim”, qui permet de démarrer et arrêter automatiquement l’ensemble des taches à partir d’un PC quelconque (un serveur TCP et un automate sur le PC, un client TCP et des exécutables spécialisés sur chacun des PCs du simu, le tout écrit en AutoLT et C++, avec l’aide du sdk FSUIPC pour accéder aux données internes de P3D).
5 - Le paramétrage des 3 vues dans P3Dv4.5 :
Aucun changement au niveau des principes (voir “3 vdp – v2”), voici à toutes fins utiles les 2 fichiers Display.xml et ViewGroups.xml :
Attention, dans le fichier Display.xml, la logique d’association Name/DisplayID & AdapterIndex ne m’est pas apparue, il faut procéder par essais successifs.
6 - Premiers essais :
Après quelques sueurs froides lors du montage du client (le ventirad est tellement important qu’une fois la carte graphique montée, il est particulièrement difficile d’accéder à son déverrouillage), je découvre l’installation d’un pc sans lecteur de DVD, clé USB pour les utilitaires de la carte mère, clé USB pour l’installation de l’OS, rapide et facile ; idem pour l’installation des logiciels, le client P3D est le plus simple des 3 PCs du simu.
Pour ces essais, je limite le fps à 30 sur le serveur, et opte, sur le client P3D, pour des réglages graphiques High/Dense.
Scène photo France VFR, je positionne l’avion à Nice, porte A14 : sur la configuration initiale, 2 vues + 1, j’avais un fps sur le client entre 25 et 30 ; là, sur la configuration 3 vues, j’observe un fps qui oscille entre 55 et 60 ! renversant …
Roulage, j’arrive à l’entrée de la 04R (face à la montagne, toute la ville sur la gauche, il y a du boulot pour la CG), le fps atteint 80.
Poursuite des essais, je dois limiter un peu le fps sur le client, qui sinon décroche de temps en temps tellement il y a décallage entre le serveur et le client.
Les 3 vues sont stables, fluides, plus aucun lag entre elles, et plus aucune désynchronisation au niveau des couches de nuages – c’est le succès.