Tweet
Salut ,
merci à Fredo / playrec qui régulièrement publie les dernières informations sur le forum de pilotevirtuel.fr , des dev de Xplane / Laminar
vous trouverez ici deux articles extrêmement intéressants
traduction google dont le titre laisse à désirer ... :
" glorieux avenir multicœur est ( rend ) désormais le présent ennuyeux.
Publié le 19 décembre 2025
Voici un article de blog dont je rêvais depuis des années, en fait depuis mon embauche il y a 8 ans : le glorieux avenir multicœur est arrivé. Mais comme toujours, il y a des conditions, alors laissez-moi vous expliquer le contenu de cette version et ce à quoi vous pouvez vous attendre. Tout d’abord, si vous souhaitez une introduction aux performances en général, vous pouvez tout lire ici : Un bref aperçu des performances. >>> mon second post
Conditions d'utilisation
1. Attentes
Avant toute chose, soyons clairs : inutile de demander quels gains de performance vous pouvez espérer. Ils peuvent être minimes, voire importants. Le multithreading n'affecte que le processeur ; si votre configuration est limitée par la carte graphique, vous ne constaterez aucune amélioration du nombre d'images par seconde, car le facteur limitant reste la carte graphique. Tout le reste dépend de la configuration de X-Plane, de votre matériel, des extensions utilisées, etc. La seule façon de savoir si vous constaterez des améliorations est d'installer la version 12.4 et de la tester vous-même. 2. Projets futurs
De plus, ce n'est pas la dernière mise à jour concernant le multithreading. Je suis très enthousiaste, mais ce n'est qu'une petite partie de ce que nous avons prévu. Il reste encore du travail de refactoring du moteur et du code à optimiser, mais nous nous sommes dit : « Pourquoi garder pour nous les améliorations que nous avons déjà alors que nous pourrions les proposer à nos clients pour qu'ils les testent en conditions réelles ? »
D'où nous venons
Une idée reçue veut que X-Plane n'ait pas du tout exploité le multithreading , ce qui, selon le point de vue, est soit totalement faux, soit partiellement vrai. X-Plane effectue de nombreuses tâches en arrière-plan, notamment le chargement des décors et la gestion des textures. Mais il s'agit de tâches de longue durée ; ce qui nous manquait jusqu'alors, c'était un véritable multithreading par image. Nous avions bien quelques petites tâches pouvant s'exécuter en parallèle, mais la majeure partie de l'image était générée sur le thread principal.
On suppose généralement que le modèle de vol est l'élément le plus gourmand en ressources pour X-Plane, mais en pratique, ce sont généralement le parcours du graphe de scène et le rendu qui représentent la majeure partie du temps d'affichage, parfois jusqu'à 75 %. Plus votre décor est complexe, plus cette tâche prendra de temps. Pour ceux qui ne travaillent pas dans le développement de jeux, le parcours du graphe de scène consiste à parcourir la scène et à déterminer ce qui doit être rendu. La seconde étape consiste à traiter les données à rendre, puis à exécuter toutes les commandes de rendu. Cela implique généralement de trier les données de rendu afin de réduire le nombre de modifications de matériaux et d'états. Tout cela prend du temps, et plus le décor est complexe, plus le temps nécessaire est important.
Il y a un autre élément important à prendre en compte : les ombres. Le rendu des ombres s'effectue en modélisant la scène du point de vue du soleil, ce qui permet de déterminer les parties de la scène éclairées et celles qui restent dans l'ombre. Par définition, tout ce que le soleil peut voir est éclairé, et tout ce qu'il ne peut pas voir est dans l'ombre. Cela signifie que la scène est parcourue deux fois : une fois pour le rendu des ombres et une fois pour la scène principale. Ainsi, même si le coût n'est pas doublé, le rendu des ombres n'est pas gratuit.
Vous êtes ici
^ Ceci est un schéma très simplifié expliquant le filetage dans X-Plane
Le traitement du décor occupant une part importante du temps d'affichage, il constitue une cible privilégiée pour les améliorations multicœurs. C'est précisément ce qu'intègre la version 12.4. Dès que la caméra est positionnée et que l'on connaît la position et la direction de l'œil virtuel, le traitement du décor pour les ombres et la scène principale est lancé. Ce traitement est effectué en plusieurs étapes sur plusieurs cœurs de processeur, afin de minimiser le temps d'exécution.
Pendant ce temps, les panneaux et les appareils avioniques fonctionnent également en arrière-plan. Cela nous permet de masquer les mises à jour avioniques plus lentes, car X-Plane peut alors traiter un grand nombre de scènes. Vous le remarquerez particulièrement avec les avions additionnels dont le temps d'affichage des panneaux est très long, mais même nos instruments Garmin et intégrés ne sont pas totalement exempts de ressources.
De plus, nous essayons d'optimiser le planning. Nous veillons donc à effectuer d'abord le parcours et la préparation du décor d'ombres, afin de pouvoir commencer l'encodage des commandes de rendu des ombres dès que les panneaux sont prêts. Pendant ce temps, le parcours du décor sur l'interface principale, bien plus gourmand en ressources, peut s'achever en arrière-plan. Idéalement, nous pourrons ensuite lancer immédiatement la génération des commandes de rendu une fois cette étape terminée.
Bien sûr, ceci est la théorie ; en pratique, certaines opérations peuvent ne pas se terminer à temps et le thread principal doit alors attendre les résultats. Cela devrait tout de même être plus rapide car le parcours de la scène est effectué en parallèle, donc plus rapide que si seul le thread principal travaillait dessus. Mais la théorie et la pratique ne coïncident pas toujours. Encore une fois, le seul moyen de connaître les performances réelles est de tester vous-même.
De plus, nous avons optimisé le chemin d'exécution du rendu et réduit le nombre de changements d'état que X-Plane doit effectuer pour passer d'un objet à l'autre. Nous avons également déplacé une grande partie des calculs à la volée des paramètres et des données des matériaux vers un thread d'arrière-plan, ce qui nous permet, une fois le rendu lancé, d'émettre des commandes le plus rapidement possible.
Cependant, l'affichage proprement dit de la scène reste monothread ! Une fois le parcours parallèle de la scène terminé, le thread principal de X-Plane crée toujours un tampon de commandes pour encoder tout le rendu nécessaire. De même, les configurations multi-écrans pourraient théoriquement bénéficier d'une amélioration bien plus importante, mais en pratique, il faut toujours parcourir la scène de chaque écran séquentiellement.
Où allons-nous ?
Les deux solutions évidentes sont le rendu parallèle de l'image et la gestion simultanée de plusieurs écrans. Une autre, moins évidente, serait de traiter les ombres et le rendu principal en parallèle, puis de soumettre les tâches au GPU dans le bon ordre. Toutes ces fonctionnalités sont prévues, mais elles nécessitent des modifications du moteur lui-même. Il reste encore beaucoup d'état global partagé lors du rendu d'une scène, qu'il nous faudra d'abord optimiser.
Ce qui me passionne particulièrement, c'est le nouveau système de tâches intégré à la version 12.3, qui sous-tend le fonctionnement multicœur. Au lieu d'écrire minutieusement du code C++ pour répartir et assembler les tâches dans le bon ordre, nous pouvons désormais décrire la trame comme un ensemble de tâches individuelles et leurs dépendances. L'ordinateur détermine alors la manière optimale de les répartir. Ce système est analogue à celui du graphe de rendu introduit dans la version 12.06, qui permet de décrire le rendu de la scène comme une série de nœuds aux dépendances précisément définies. L'ordinateur peut ensuite calculer comment exécuter les commandes et générer les ressources.
Cela nous offre une flexibilité considérable pour réorganiser l'image, puisqu'elle n'est plus un bloc monolithique massif. Outre l'amélioration majeure que représente le rendu parallèle, nous prévoyons également d'exploiter ce système pour optimiser les performances en planifiant plus efficacement le rendu de l'image. Mais maintenant que le travail initial n'est plus qu'une formalité, tout cela se profile comme un avenir prometteur. "
merci à Fredo / playrec qui régulièrement publie les dernières informations sur le forum de pilotevirtuel.fr , des dev de Xplane / Laminar
vous trouverez ici deux articles extrêmement intéressants
traduction google dont le titre laisse à désirer ... :
" glorieux avenir multicœur est ( rend ) désormais le présent ennuyeux.
Publié le 19 décembre 2025
Voici un article de blog dont je rêvais depuis des années, en fait depuis mon embauche il y a 8 ans : le glorieux avenir multicœur est arrivé. Mais comme toujours, il y a des conditions, alors laissez-moi vous expliquer le contenu de cette version et ce à quoi vous pouvez vous attendre. Tout d’abord, si vous souhaitez une introduction aux performances en général, vous pouvez tout lire ici : Un bref aperçu des performances. >>> mon second post
Conditions d'utilisation
1. Attentes
Avant toute chose, soyons clairs : inutile de demander quels gains de performance vous pouvez espérer. Ils peuvent être minimes, voire importants. Le multithreading n'affecte que le processeur ; si votre configuration est limitée par la carte graphique, vous ne constaterez aucune amélioration du nombre d'images par seconde, car le facteur limitant reste la carte graphique. Tout le reste dépend de la configuration de X-Plane, de votre matériel, des extensions utilisées, etc. La seule façon de savoir si vous constaterez des améliorations est d'installer la version 12.4 et de la tester vous-même. 2. Projets futurs
De plus, ce n'est pas la dernière mise à jour concernant le multithreading. Je suis très enthousiaste, mais ce n'est qu'une petite partie de ce que nous avons prévu. Il reste encore du travail de refactoring du moteur et du code à optimiser, mais nous nous sommes dit : « Pourquoi garder pour nous les améliorations que nous avons déjà alors que nous pourrions les proposer à nos clients pour qu'ils les testent en conditions réelles ? »
D'où nous venons
Une idée reçue veut que X-Plane n'ait pas du tout exploité le multithreading , ce qui, selon le point de vue, est soit totalement faux, soit partiellement vrai. X-Plane effectue de nombreuses tâches en arrière-plan, notamment le chargement des décors et la gestion des textures. Mais il s'agit de tâches de longue durée ; ce qui nous manquait jusqu'alors, c'était un véritable multithreading par image. Nous avions bien quelques petites tâches pouvant s'exécuter en parallèle, mais la majeure partie de l'image était générée sur le thread principal.
On suppose généralement que le modèle de vol est l'élément le plus gourmand en ressources pour X-Plane, mais en pratique, ce sont généralement le parcours du graphe de scène et le rendu qui représentent la majeure partie du temps d'affichage, parfois jusqu'à 75 %. Plus votre décor est complexe, plus cette tâche prendra de temps. Pour ceux qui ne travaillent pas dans le développement de jeux, le parcours du graphe de scène consiste à parcourir la scène et à déterminer ce qui doit être rendu. La seconde étape consiste à traiter les données à rendre, puis à exécuter toutes les commandes de rendu. Cela implique généralement de trier les données de rendu afin de réduire le nombre de modifications de matériaux et d'états. Tout cela prend du temps, et plus le décor est complexe, plus le temps nécessaire est important.
Il y a un autre élément important à prendre en compte : les ombres. Le rendu des ombres s'effectue en modélisant la scène du point de vue du soleil, ce qui permet de déterminer les parties de la scène éclairées et celles qui restent dans l'ombre. Par définition, tout ce que le soleil peut voir est éclairé, et tout ce qu'il ne peut pas voir est dans l'ombre. Cela signifie que la scène est parcourue deux fois : une fois pour le rendu des ombres et une fois pour la scène principale. Ainsi, même si le coût n'est pas doublé, le rendu des ombres n'est pas gratuit.
Vous êtes ici
^ Ceci est un schéma très simplifié expliquant le filetage dans X-Plane
Le traitement du décor occupant une part importante du temps d'affichage, il constitue une cible privilégiée pour les améliorations multicœurs. C'est précisément ce qu'intègre la version 12.4. Dès que la caméra est positionnée et que l'on connaît la position et la direction de l'œil virtuel, le traitement du décor pour les ombres et la scène principale est lancé. Ce traitement est effectué en plusieurs étapes sur plusieurs cœurs de processeur, afin de minimiser le temps d'exécution.
Pendant ce temps, les panneaux et les appareils avioniques fonctionnent également en arrière-plan. Cela nous permet de masquer les mises à jour avioniques plus lentes, car X-Plane peut alors traiter un grand nombre de scènes. Vous le remarquerez particulièrement avec les avions additionnels dont le temps d'affichage des panneaux est très long, mais même nos instruments Garmin et intégrés ne sont pas totalement exempts de ressources.
De plus, nous essayons d'optimiser le planning. Nous veillons donc à effectuer d'abord le parcours et la préparation du décor d'ombres, afin de pouvoir commencer l'encodage des commandes de rendu des ombres dès que les panneaux sont prêts. Pendant ce temps, le parcours du décor sur l'interface principale, bien plus gourmand en ressources, peut s'achever en arrière-plan. Idéalement, nous pourrons ensuite lancer immédiatement la génération des commandes de rendu une fois cette étape terminée.
Bien sûr, ceci est la théorie ; en pratique, certaines opérations peuvent ne pas se terminer à temps et le thread principal doit alors attendre les résultats. Cela devrait tout de même être plus rapide car le parcours de la scène est effectué en parallèle, donc plus rapide que si seul le thread principal travaillait dessus. Mais la théorie et la pratique ne coïncident pas toujours. Encore une fois, le seul moyen de connaître les performances réelles est de tester vous-même.
De plus, nous avons optimisé le chemin d'exécution du rendu et réduit le nombre de changements d'état que X-Plane doit effectuer pour passer d'un objet à l'autre. Nous avons également déplacé une grande partie des calculs à la volée des paramètres et des données des matériaux vers un thread d'arrière-plan, ce qui nous permet, une fois le rendu lancé, d'émettre des commandes le plus rapidement possible.
Cependant, l'affichage proprement dit de la scène reste monothread ! Une fois le parcours parallèle de la scène terminé, le thread principal de X-Plane crée toujours un tampon de commandes pour encoder tout le rendu nécessaire. De même, les configurations multi-écrans pourraient théoriquement bénéficier d'une amélioration bien plus importante, mais en pratique, il faut toujours parcourir la scène de chaque écran séquentiellement.
Où allons-nous ?
Les deux solutions évidentes sont le rendu parallèle de l'image et la gestion simultanée de plusieurs écrans. Une autre, moins évidente, serait de traiter les ombres et le rendu principal en parallèle, puis de soumettre les tâches au GPU dans le bon ordre. Toutes ces fonctionnalités sont prévues, mais elles nécessitent des modifications du moteur lui-même. Il reste encore beaucoup d'état global partagé lors du rendu d'une scène, qu'il nous faudra d'abord optimiser.
Ce qui me passionne particulièrement, c'est le nouveau système de tâches intégré à la version 12.3, qui sous-tend le fonctionnement multicœur. Au lieu d'écrire minutieusement du code C++ pour répartir et assembler les tâches dans le bon ordre, nous pouvons désormais décrire la trame comme un ensemble de tâches individuelles et leurs dépendances. L'ordinateur détermine alors la manière optimale de les répartir. Ce système est analogue à celui du graphe de rendu introduit dans la version 12.06, qui permet de décrire le rendu de la scène comme une série de nœuds aux dépendances précisément définies. L'ordinateur peut ensuite calculer comment exécuter les commandes et générer les ressources.
Cela nous offre une flexibilité considérable pour réorganiser l'image, puisqu'elle n'est plus un bloc monolithique massif. Outre l'amélioration majeure que représente le rendu parallèle, nous prévoyons également d'exploiter ce système pour optimiser les performances en planifiant plus efficacement le rendu de l'image. Mais maintenant que le travail initial n'est plus qu'une formalité, tout cela se profile comme un avenir prometteur. "
Commentaire