Commentaires : +80 % ? + 90 % ? Microsoft booste les performances Intel/NVIDIA via une mise à jour DirectX

Et si Microsoft se muait en faiseur de miracles ? Non, vous n’y croyez pas, nous non plus. Cela dit, son Shader Execution Reordering pourrait changer pas mal de choses.

https://clubic.com//actualite-602959-microsoft-booste-les-performances-intel-nvidia-via-une-mise-a-jour-directx.html

C’est déjà disponible pour Vulkan depuis novembre dernier.
Une présentation était faite même il y a un an déjà : https://www.youtube.com/watch?v=rrKk5wtzZ80.

Faut arrêter de faire de la pub aux GAFAM quand il n’y a pas lieu : https://www.khronos.org/blog/boosting-ray-tracing-performance-with-shader-execution-reordering-introducing-vk-ext-ray-tracing-invocation-reorder.

SER, NVIDIA en parle depuis bien plus longtemps encore :
https://developer.nvidia.com/blog/improve-shader-performance-and-in-game-frame-rates-with-shader-execution-reordering/
Il n’est pas question de faire de la pub, mais DirectX 12 concerne bien plus de jeux et, de fait, reste plus visible même si ça bouge.

l’implémentation du SER :

  1. Le coût de l’ordonnancement (Overhead)
    Réorganiser des milliers de fils d’exécution (threads) n’est pas gratuit. Le processeur graphique (GPU) doit analyser, trier et regrouper les rayons en temps réel.
    Le risque : Si le temps passé à trier les calculs est supérieur au temps gagné par le regroupement, le SER devient contre-productif. C’est un équilibre délicat entre le coût de la gestion des données et le gain de calcul pur.
  2. La pression sur la mémoire (Register Pressure)
    Pour réorganiser des threads, le GPU doit souvent stocker temporairement l’état de chaque rayon (ses coordonnées, sa direction, ses variables) dans la mémoire locale ou les registres.
    Le problème : Les registres sont une ressource extrêmement limitée et rapide. Si le SER en utilise trop pour le tri, il en reste moins pour l’exécution des shaders eux-mêmes, ce qui peut ralentir l’ensemble de la puce.
  3. La dépendance à l’API et aux développeurs
    Le SER n’est pas « magique » ou automatique au niveau matériel pur pour toutes les cartes.
    L’implémentation : Chez NVIDIA (Ada Lovelace), il y a une accélération matérielle dédiée, mais les développeurs doivent tout de même utiliser des extensions spécifiques (comme dans DirectX 12 ou Vulkan).
    La fragmentation : Si chaque constructeur (AMD, Intel, NVIDIA) gère le SER différemment, les développeurs de jeux pourraient hésiter à optimiser spécifiquement pour chaque architecture, rendant la technologie sous-utilisée.
  4. L’efficacité variable selon la scène
    Le gain de performance dépend énormément de la complexité de la scène 3D :
    Scènes simples : Si les rayons frappent tous la même surface (ex: un miroir plan), il n’y a pas de divergence. Le SER est alors inutile et pourrait même ralentir le rendu à cause de son surcoût.
    Scènes complexes : C’est là qu’il brille (ex: une forêt avec des milliers de feuilles et des matériaux différents), mais c’est aussi là qu’il est le plus difficile à gérer techniquement.
  5. Latence de traitement
    Le regroupement des fils d’exécution peut introduire une micro-latence. Bien que cela améliore le nombre d’images par seconde (FPS), cela peut parfois affecter la régularité du débit d’images (le frame pacing), ce qui se traduit par des micro-saccades si la gestion des files d’attente n’est pas parfaite.

En résumé
Le principal problème n’est pas l’idée de base, mais l’arbitrage entre le gain de cohérence et le coût du tri. C’est un peu comme ranger une bibliothèque : si vous passez 4 heures à classer vos livres pour gagner 2 secondes quand vous en cherchez un, l’opération n’est pas rentable.