Intel XeSS : comment Intel a rejoint la bataille via le logiciel

Pourquoi XeSS existe : une réponse logicielle à un problème matériel

L’upscaling est la manière la moins glamour de « créer de la performance ». Vous n’accélérez pas le GPU ; vous réduisez le travail, puis vous reconstruez le détail. Le cas business est évident : les visuels modernes exigent des temps par image modernes. Le ray tracing, des nombres d’échantillons élevés, des post-traitements lourds et une géométrie dense se disputent tous la même allocation de millisecondes par image.

Intel est arrivé tard à la fête des GPU discrets. XeSS est en partie une fonctionnalité technique, en partie une tactique d’entrée sur le marché. Il permet à Intel de dire : « Nos GPU peuvent fonctionner à haute résolution », et il permet aussi à Intel de dire quelque chose d’encore plus important pour les studios : « Vous pouvez cibler un large public sans écrire trois piles de reconstruction distinctes. » Cette seconde partie — l’ambition inter-fournisseurs — compte opérationnellement. Elle réduit l’explosion combinatoire de « ce mode sur ce GPU avec ce pilote et ce contenu ».

Mais la vérité opérationnelle centrale reste : les upscalers temporels ne sont pas que des algorithmes. Ce sont des pipelines. Vous leur fournissez l’historique, des vecteurs de mouvement, la profondeur, l’exposition et parfois des masques réactifs. Si vos entrées sont mauvaises, la sortie sera fausse avec assurance. Et rien n’est plus démoralisant qu’un algorithme qui produit des pixels magnifiquement faux.

Faits intéressants et contexte historique (court, concret)

• L’upscaling temporel est devenu grand public parce que la 4K est devenue grand public. L’augmentation du nombre de pixels a dépassé la croissance confortable des performances raster pour les budgets consommateurs typiques.
• DLSS a changé les attentes en normalisant la reconstruction par ML pour les joueurs. Après cela, « uniquement mise à l’échelle spatiale » a commencé à ressembler à un compromis plutôt qu’à une fonctionnalité.
• Intel a annoncé XeSS en 2021 alors qu’Arc se transformait en un véritable effort de GPU discret, pas seulement une marque d’IGP.
• XeSS est conçu pour s’exécuter sur le matériel matriciel XMX d’Intel pour de meilleures performances et qualité, mais il dispose aussi d’une voie de secours pour d’autres GPU utilisant les instructions DP4a.
• Le support inter-fournisseurs n’était pas que du marketing. C’est une tentative pratique de devenir « la troisième option » dans les menus de paramètres des jeux sans exiger du matériel Intel exclusif.
• Les upscalers ont forcé les moteurs à prendre les vecteurs de mouvement au sérieux. Beaucoup de studios ont appris que leurs vecteurs étaient « suffisants pour le motion blur », ce qui n’est pas la même chose que « corrects pour la reconstruction ».
• L’échantillonnage jitter (style TAA) n’est pas optionnel pour une reconstruction temporelle de haute qualité. Si votre rendu est stable mais sous-échantillonné, l’upscaler a moins d’informations pour récupérer le détail.
• La maturité des pilotes compte plus pour les upscalers que pour beaucoup d’autres fonctionnalités. Un problème subtil de synchronisation ou d’état de ressource peut se manifester par des traînées, des scintillements ou des corruptions intermittentes qui ressemblent à des bugs de contenu.

Comment XeSS fonctionne (et pourquoi l’upscaling temporel est fragile)

XeSS est un upscaler temporel : il produit une sortie en plus haute résolution en combinant la trame actuelle rendue à plus basse résolution avec des informations des trames précédentes. Le mot « temporel » est l’étiquette d’avertissement. Cela signifie que vous construisez une image au fil du temps, ce qui implique que vous misez sur la possibilité de mapper correctement d’anciens pixels dans la nouvelle trame.

Pratiquement, une intégration XeSS est un contrat :

• Vous fournissez : couleur basse résolution, profondeur, vecteurs de mouvement, offsets de jitter, informations d’exposition/tonemapping (selon l’implémentation), et parfois des masques pour gérer les transparences ou les cas particuliers.
• XeSS fournit : une image reconstruite en plus haute résolution, idéalement avec plus de détails stables qu’une mise à l’échelle naïve, et idéalement avec moins de scintillement que le TAA classique.

Ce contrat se rompt de manières prévisibles :

• Vecteurs de mouvement erronés → traînées fantômes, étalement, « doubles images » ou détails fins instables.
• Mauvaise profondeur → gestion incorrecte des désocclusions, halos autour des bords et sautements temporels.
• Mauvais appariement d’exposition → pompage de luminosité et « l’historique ressemble à celui d’un autre univers ».
• Interface utilisateur au mauvais endroit → une UI nette devient un regret flou généré par l’IA.

Du point de vue SRE, traitez XeSS comme un système distribué : « garbage in, garbage out », et les défaillances sont émergentes. Vous ne verrez pas un plantage ; vous verrez une érosion lente de la confiance. Les joueurs diront « ça ne semble pas naturel ». C’est la classe de bug la plus difficile : subjective, variable et contagieuse dans les revues.

Voici l’autre vérité : l’upscaling temporel est une fonctionnalité de performance qui consomme du temps GPU. Si votre pipeline est déjà lourd en calcul, un upscaler de haute qualité peut être la goutte d’eau qui transforme « globalement correct » en « bordélique avec des pics ». Vous devez mesurer, pas improviser.

Une citation pour vous garder honnête : « L’espoir n’est pas une stratégie. » — idée paraphrasée souvent attribuée dans les cercles opérationnels (souvent liée à Gordon R. Sullivan). Utilisez des métriques.

Les deux voies : XMX vs DP4a (et pourquoi ça vous concerne)

XeSS est « logiciel » dans le sens où c’est un algorithme distribué sous forme de bibliothèque et intégré aux moteurs. Mais c’est aussi « conscient du matériel ». Sur les GPU Intel Arc, XeSS peut utiliser XMX (les moteurs matriciels d’Intel) pour exécuter l’inférence ML efficacement. Sur d’autres GPU qui supportent DP4a (instructions produit scalaire), XeSS peut utiliser un chemin de secours.

Cette division a des conséquences opérationnelles :

• La prévisibilité des performances diffère. XMX a tendance à offrir un meilleur compromis perf/qualité. DP4a est fonctionnel mais peut coûter plus selon l’architecture GPU et la charge.
• La cohérence de qualité peut diverger. Les implémentations visent la parité, mais vous devez supposer que les artefacts peuvent varier selon la voie et le pilote.
• La charge de support augmente. Quand un rapport de bug dit « XeSS a l’air mauvais », votre première question est : quel chemin ? Puis : quel pilote, quel GPU, quel mode, quel contenu.

Règle de base : si vous déployez XeSS, vous devez tester au moins une carte Intel Arc et au moins une carte non-Intel compatible DP4a. Sinon vous ne testez pas « XeSS » ; vous testez votre branche préférée de XeSS.

Blague courte n°1 : L’upscaling temporel, c’est comme un groupe de discussion — un mauvais message (vecteur) et tout le fil devient un malentendu pendant des heures.

Modes de qualité, résolution d’entrée et budget de temps par image

Les upscalers exposent généralement des modes comme Qualité, Équilibré, Performance, Ultra Performance. Sous le capot, ils changent surtout la résolution de rendu d’entrée relative à la sortie.

Voici le modèle de décision qui fonctionne réellement en production :

1. Partir d’un budget de temps par image (par exemple 16,67 ms pour 60 FPS, 8,33 ms pour 120 FPS).
2. Mesurer la base sans upscaling à la résolution de sortie native.
3. Mesurer la base avec une résolution interne plus basse mais sans upscaling ML (juste pour estimer les économies raster).
4. Puis ajouter XeSS et observer : temps GPU total, variance, et taux d’artefacts par catégorie de scène.

Si vous ne séparez pas les « économies de rendu » du « coût de reconstruction », vous finirez par blâmer la mauvaise partie de la pile. J’ai vu des équipes passer une semaine à « optimiser XeSS » alors que le vrai problème était une pile de post-traitement gourmande en fill-rate qui ne diminuait pas avec la résolution.

Par ailleurs : n’optimisez pas pour la moyenne de FPS. Optimisez pour la cohérence du temps par image. Les upscalers peuvent introduire des pics à cause de transitions de ressources, de misses de cache ou de synchronisations autour des buffers d’historique — surtout si le graphe de rendu de votre moteur est déjà limite.

Réalité de l’intégration : vecteurs de mouvement, jitter, exposition et « tout ce que vous avez oublié »

Vecteurs de mouvement : « presque suffisant » est un bug

Les vecteurs de mouvement pour l’upscaling doivent représenter comment le contenu d’un pixel a bougé entre les images. Ça paraît simple jusqu’à la livraison :

• Meshes skinnés avec la vélocité manquante sur certains LOD
• Particules qui n’écrivent pas de vecteurs de mouvement (ou écrivent des données incohérentes)
• Objets transparents qui devraient être exclus ou traités séparément
• Coups de caméra et objets téléportés qui polluent l’historique

Échec typique : traînées fantômes derrière des personnages en mouvement, bords d’armes étalés, ou éléments HUD qui « traînent ». La correction n’est pas « accentuer davantage ». La correction est de fournir des vecteurs corrects et de définir ce qui ne doit pas être accumulé temporellement.

Jitter : vous en avez besoin, mais vous devez le gérer

La reconstruction temporelle bénéficie d’un échantillonnage jitterisé : de petits offsets sous-pixel d’une image à l’autre qui permettent à l’algorithme d’inférer des détails de haute fréquence. Mais le jitter interagit aussi avec :

• Le rendu de l’UI (doit être fait en espace sortie, pas en espace d’entrée jitterisé)
• Les effets en espace écran (SSR, SSAO) qui peuvent devenir bruyants si non stabilisés
• L’ordre de la chaîne de post-traitement (où vous appliquez tonemapping et netteté)

Exposition et tonemapping : choisissez votre espace et tenez-vous-y

Les upscalers préfèrent généralement une entrée stable. Si votre exposition s’adapte rapidement et que vous fournissez une image pré-tonemap une frame et post-tonemap l’autre frame (ou changez les courbes entre les passes), vous verrez du pompage. Décidez de l’espace correct pour l’intégration de l’upscaler et n’« essayez pas juste quelque chose » la dernière semaine avant la sortie.

Masques réactifs et cas spéciaux : eau, particules et alpha sont des récidivistes

Les transparences et les particules sont célèbres pour les artefacts temporels car elles n’ont pas de profondeur/vecteur de mouvement stables. Beaucoup d’intégrations d’upscaling supportent des masques pour réduire la dépendance à l’historique dans ces régions. Si vous les ignorez, l’algorithme hallucine avec assurance une continuité inexistante.

Blague courte n°2 : L’accentuation est le ruban adhésif des graphismes — utile en urgence, suspect comme architecture à long terme.

Trois mini-récits du monde corporate depuis les tranchées

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Le studio avait une build multiplateforme et une jolie abstraction : « les vecteurs de mouvement sont des vecteurs de mouvement ». Ils étaient générés en une passe, consommés par le motion blur, le TAA, et maintenant XeSS. Tout le monde a hoché la tête. Le code partagé, c’est bien, non ?

Puis QA a commencé à ouvrir des bugs XeSS : ghosting autour des personnages, surtout lors de strafing. L’ingénieur rendu principal a blâmé l’upscaler. Le producteur a blâmé les pilotes Intel. L’ingénieur build a blâmé le « nouveau pack de contenu ». Le carrousel habituel de blâme est parti parce que personne ne voulait entendre « nos vecteurs sont incorrects ».

Quand ils ont finalement creusé, la cause racine était banale : leurs vecteurs de mouvement étaient calculés en espace vue pour le motion blur, mais l’upscaler attendait une convention et une échelle différentes. De plus, un sous-ensemble de meshes animés avait la vélocité désactivée à certains seuils de LOD pour économiser de la bande passante. Le motion blur ne le remarquait guère. XeSS l’a remarqué immédiatement.

La correction n’était pas glamour : unifier les conventions, valider les vecteurs avec des superpositions debug, et forcer l’écriture de la vélocité pour toute la géométrie pertinente. Le ghosting a disparu. Les accusations aussi — surtout parce que tout le monde a prétendu « l’avoir su depuis le début ».

Mini-récit 2 : L’optimisation qui a échoué

Une équipe performance a décidé de réduire la bande passante en compressant plus agressivement les buffers d’historique. Sur une slide, c’était brillant : moins d’octets déplacés, moins de misses de cache, frames plus rapides. Ils ont mesuré un petit gain dans une scène statique et l’ont expédié en build nightly.

En quelques jours, des joueurs du canal interne se sont plaints que la géométrie fine — clôtures, câbles, rambardes lointaines — semblait vibrer. Les rapports étaient vagues. « Scintillement. » « Ramper. » « Sensation d’instabilité. » Classique.

Il s’est avéré que le bruit de quantification ajouté dans l’historique, combiné au jitter et à un renforcement agressif, créait une boucle de rétroaction. L’upscaler essayait de reconstruire le détail à partir d’un signal historique dégradé ; l’accentuation amplifiait l’erreur ; la trame suivante utilisait cette sortie amplifiée comme historique. Résultat : instabilité temporelle qui empirait en mouvement.

Ils ont annulé la compression puis l’ont réintroduite plus tard avec des garde-fous : seuils basés sur le contenu, meilleur dithering et une limite stricte sur l’accentuation en modes performance. La leçon fut douloureuse mais claire : dans les systèmes temporels, des « données légèrement pires » peuvent devenir une « sortie dramatiquement pire » parce que les erreurs persistent d’une image à l’autre.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre équipe a fait quelque chose peu excitant : elle a construit un banc de régression. Chaque build nightly rendait un ensemble fixe de trajectoires de caméra à travers une bibliothèque de scènes. Il capturait les images de sortie, les visualisations des vecteurs de mouvement et les traces de temps par image. Rien de sophistiqué, juste de la constance.

Deux semaines avant la sortie, une mise à jour de pilote est arrivée dans leur matrice de test. Un artefact subtil est apparu : scintillement intermittent sur des bords à fort contraste lors de panoramiques rapides. Le jeu ne plantait pas. Les performances étaient correctes. Sans le banc, cela serait passé pour de la « bizarrerie hardware joueur ».

Parce que le banc comparait les sorties, le scintillement a été signalé immédiatement. Ils ont bisectionné : même build, pilote différent. Puis même pilote, mode XeSS différent. Puis même mode, fallback anti-aliasing différent. En une journée ils avaient un repro minimal et une signature fiable.

Ils ont livré avec un contournement ciblé et un avis pilote dans leurs notes de version. Pas héroïque. Juste discipliné. En termes opérationnels, ils ont réduit le temps moyen pour établir l’innocence puis le temps moyen pour résoudre. Ennuyeux, correct, efficace.

Tâches pratiques : commandes, signification des sorties et décisions

Ces tâches supposent une station Linux ou un banc de test. Si vous êtes sur Windows, les commandes exactes diffèrent, mais la logique opérationnelle est la même : vérifier le chemin matériel, la version du pilote, la saturation GPU, les limites thermiques, le pacing des frames et la corrélation des artefacts avec les entrées du pipeline.

Task 1: Identify the GPU and driver in use

cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d'
01:00.0 VGA compatible controller [0300]: Intel Corporation Arc A770 [8086:56a0]

Ce que cela signifie : Vous connaissez le GPU exact et l’ID vendeur/device. Cela influe sur si XeSS s’exécute probablement sur XMX (Intel Arc) ou DP4a (autres GPU).

Décision : Choisissez la couverture de test : assurez-vous qu’au moins un appareil Intel Arc soit dans le CI/labo perf ; ne vous fiez pas uniquement aux résultats DP4a si votre audience cible inclut Arc.

Task 2: Check Mesa/driver stack versions (common with Intel on Linux)

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Intel(R) Arc(tm) A770 Graphics (DG2) (0x56a0)
    Version: 24.0.5
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Arc(tm) A770 Graphics (DG2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.5

Ce que cela signifie : Vous avez une base pour le comportement du pilote. Les artefacts de rendu et les régressions perf sont souvent corrélés à la version du pilote.

Décision : Épinglez les versions de pilote dans votre labo perf ; ne changez qu’une variable à la fois lors d’investigations sur la qualité/perf de XeSS.

Task 3: Confirm Vulkan device and driver details (most XeSS titles use Vulkan or D3D)

cr0x@server:~$ vulkaninfo --summary | sed -n '1,60p'
Vulkan Instance Version: 1.3.275

Devices:
========
GPU0:
    apiVersion         = 1.3.275
    driverVersion      = 24.0.5
    vendorID           = 0x8086
    deviceID           = 0x56a0
    deviceName         = Intel(R) Arc(tm) A770 Graphics (DG2)

Ce que cela signifie : Confirme la pile Vulkan et la sélection de périphérique. Une sélection de périphérique incorrecte peut rendre vos benchmarks XeSS dénués de sens (par ex. exécution sur l’iGPU par accident).

Décision : Assurez-vous que votre jeu sélectionne le GPU prévu ; dans les systèmes multi-GPU, forcez le choix explicite de périphérique dans les bancs de test.

Task 4: Watch GPU utilization and frequency in real time

cr0x@server:~$ sudo intel_gpu_top -l
freq    rc6     irqs     busy   sema   wait
 2200MHz  3.21%   1250    96.3%  0.0%   1.2%

Ce que cela signifie : Un « busy » élevé indique que le GPU est saturé. Une faible fréquence ou un RC6 élevé peut indiquer un comportement de gestion d’énergie affectant le pacing des images.

Décision : Si le GPU est saturé, XeSS peut aider en réduisant la résolution interne ; si le GPU n’est pas saturé mais les images sont lentes, cherchez des goulots CPU ou des blocages de synchronisation.

Task 5: Check temperatures and throttling signals

cr0x@server:~$ sensors | sed -n '1,80p'
edge:         +78.0°C
junction:     +92.0°C
mem:          +84.0°C

Ce que cela signifie : Des températures de jonction élevées peuvent provoquer des baisses de fréquence. L’upscaling ne corrige pas le throttling ; il le masque parfois jusqu’à l’arrivée d’une scène lourde.

Décision : Si les températures sont proches des seuils de throttling, normalisez les conditions de test (banc ouvert, courbe de ventilateur fixe, ambiant constant) avant de tirer des conclusions sur les performances de XeSS.

Task 6: Verify CPU governor and frequency behavior (frame-time spikes love CPUs too)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Ce que cela signifie : « powersave » peut introduire de la latence et des temps par image incohérents dans les scènes CPU-limitées.

Décision : Passez au governor performance pour des benchmarks contrôlés ; si cela corrige les pics, vous avez trouvé un artefact d’environnement de test, pas un problème XeSS.

Task 7: Switch governor for repeatable perf tests

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que cela signifie : Le CPU reste à des fréquences plus élevées, réduisant les pics induits par l’ordonnancement.

Décision : Utilisez cela pour les baselines de labo. Pour le comportement réel des joueurs, testez aussi des profils d’alimentation « équilibré » et des ordinateurs portables, car c’est là que l’upscaling est souvent le plus pertinent.

Task 8: Detect whether you’re memory constrained (VRAM pressure causes stutter and texture fallback)

cr0x@server:~$ cat /proc/meminfo | egrep 'MemAvailable|SwapFree'
MemAvailable:   11873432 kB
SwapFree:        8388604 kB

Ce que cela signifie : La pression sur la RAM système peut forcer du paging et créer des saccades « aléatoires » que les joueurs attribuent aux réglages graphiques.

Décision : Si MemAvailable est bas lors des saccades, corrigez les fuites de mémoire ou les budgets de streaming d’actifs avant d’ajuster les modes XeSS.

Task 9: Capture frame-time traces with MangoHud (quick and dirty, but useful)

cr0x@server:~$ mangohud --dlsym ./MyGame.x86_64
MangoHud: Uploading is disabled (HUD only)

Ce que cela signifie : Vous obtenez des métriques à l’écran : FPS, temps par image, charge GPU/CPU. Pas parfait, mais peut montrer immédiatement si XeSS a amélioré la moyenne de FPS mais a empiré la variance du temps par image.

Décision : Si la moyenne s’améliore mais que les 1% lows plongent, investiguez synchronisation, streaming ou churn d’allocation des buffers d’historique.

Task 10: Check whether the process is CPU-bound under load

cr0x@server:~$ pidof MyGame.x86_64
24193

cr0x@server:~$ top -H -p 24193 -b -n 1 | sed -n '1,25p'
top - 18:52:10 up  2:13,  1 user,  load average: 7.92, 6.30, 4.50
Threads:  87 total,   4 running,  83 sleeping,   0 stopped,   0 zombie
%Cpu(s): 24.0 us,  3.0 sy,  0.0 ni, 72.5 id,  0.3 wa,  0.0 hi,  0.2 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24193 cr0x      20   0 13.2g 4.1g  312m S  180.0  6.6   4:12.91 MyGame.x86_64

Ce que cela signifie : Si un ou deux threads sont saturés et que le GPU n’est pas occupé, vous êtes limité par le CPU. XeSS ne vous sauvera pas du thread principal.

Décision : Priorisez les optimisations côté CPU (culling, soumission, simulation) avant de passer du temps à régler les modes XeSS.

Task 11: Spot stutter from IO (asset streaming and shader cache issues)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          16.55    0.00    2.40    8.10    0.00   72.95

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         82.00  12480.0     0.00   0.00   12.40   152.2    41.00   6144.0    9.10   1.42  78.00

Ce que cela signifie : Un %iowait élevé et un %util disque élevé avec r_await élevé peuvent être corrélés à des saccades. Les upscalers sont souvent accusés car la saccade est visible lors d’un mouvement de caméra.

Décision : Corrigez le préchauffage du cache de shaders, réduisez les chargements synchrones d’actifs et assurez-vous que le streaming est asynchrone avant d’attribuer la saccade à XeSS.

Task 12: Verify shader cache and pipeline compilation behavior (a classic “first run is awful” problem)

cr0x@server:~$ ls -lah ~/.cache | sed -n '1,20p'
total 72K
drwx------ 18 cr0x cr0x 4.0K Jan 13 18:10 .
drwx------ 57 cr0x cr0x 4.0K Jan 13 17:02 ..
drwx------  6 cr0x cr0x 4.0K Jan 13 18:08 mesa_shader_cache

Ce que cela signifie : Des caches de shaders existent et sont écrits. Si un répertoire de cache est manquant ou non inscriptible, vous pouvez recompiler constamment.

Décision : Assurez-vous que le chemin de cache est stable et inscriptible dans votre environnement de déploiement (y compris les launchers sandboxés). Sinon, attendez-vous à des saccades qu’aucun upscaler ne pourra masquer.

Task 13: Inspect dmesg for GPU hangs or resets (rare, but catastrophic for perceived quality)

cr0x@server:~$ sudo dmesg -T | grep -Ei 'i915|xe|gpu hang|reset' | tail -n 8
[Mon Jan 13 18:44:21 2026] xe 0000:01:00.0: GuC: submission enabled
[Mon Jan 13 18:44:59 2026] xe 0000:01:00.0: [drm] GPU HANG: ecode 12:1:0x86dffffb, in MyGame.x86_64 [24193]
[Mon Jan 13 18:45:03 2026] xe 0000:01:00.0: [drm] Resetting GPU

Ce que cela signifie : Un hang/reset se traduira par un énorme hitch ou un crash. Les joueurs diront « XeSS a cassé mon jeu » parce que c’est le dernier réglage qu’ils ont changé.

Décision : Reproduisez sans XeSS, puis avec. Si ça corrèle, collectez un repro minimal, versions pilotes et déclencheurs de contenu ; traitez comme un blocant.

Task 14: Measure per-frame variance quickly (basic statistics over a log)

cr0x@server:~$ awk '{sum+=$1; sumsq+=$1*$1; n++} END {mean=sum/n; var=(sumsq/n)-(mean*mean); printf("n=%d mean=%.3fms std=%.3fms\n", n, mean, sqrt(var))}' frametimes_ms.log
n=12000 mean=15.820ms std=3.940ms

Ce que cela signifie : Le temps moyen par image est correct, mais l’écart-type est élevé : probablement de la saccade. XeSS « marche » mais votre pacing est mauvais.

Décision : Investiguer les pics : streaming, compilation, synchronisation ou surconsommation VRAM. Ne « corrigez » pas avec un mode XeSS plus agressif à moins d’avoir prouvé que le goulot est le temps raster GPU.

Méthode de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Si vous êtes d’astreinte pour une build, vous n’avez pas le temps pour de la philosophie. Vous avez besoin d’un ordre de triage qui converge.

Premier : classifier le problème (qualité vs performance vs stabilité)

• Artefact de qualité : ghosting, scintillement, flicker, halos, UI étalée.
• Régression de performance : FPS plus bas, temps GPU plus élevé, 1% lows dégradés.
• Stabilité : périphérique perdu, hang GPU, reset pilote, corruption intermittente.

Ne mélangez pas les catégories. Un flicker n’est pas un « problème de performance », même s’il est apparu après un réglage de performance.

Deuxième : décider si vous êtes GPU-bound ou CPU/IO-bound

• GPU occupé ~90–100% et temps par image élevé → probablement GPU-bound. Les changements de mode XeSS devraient avoir un impact.
• GPU occupé faible/modéré mais temps par image élevé → CPU-bound ou bloqué par synchronisation/IO.
• Pics avec iowait ou compilation de shaders → problème de saccade ; XeSS est un dommage collatéral.

Troisième : isoler le chemin XeSS et ses entrées

1. Confirmer que XeSS est réellement activé (ne pas faire confiance au simple toggle UI ; vérifier dans les logs/télémétrie).
2. Identifier la voie matérielle : XMX vs DP4a selon GPU et sélection runtime.
3. Changer les modes (Qualité/Équilibré/Performance) et observer à la fois temps par image et taux d’artefacts.
4. Désactiver temporairement l’accentuation pour voir si vous amplifiez une instabilité temporelle sous-jacente.
5. Valider les vecteurs de mouvement avec une vue debug dans la scène problématique.
6. Tester les coupures de caméra : s’assurer que l’historique est correctement réinitialisé sur cut/téléport.

Quatrième : verrouiller l’environnement avant de blâmer l’algorithme

• Épingler la version du pilote
• Désactiver téléchargements en arrière-plan et overlays
• Normaliser les thermiques (ventilateurs, ambiant)
• Assurer un état de cache shader comparable

Rien ne fait perdre plus de temps aux ingénieurs que de comparer un run avec cache froid à un run avec cache chaud et l’appeler « régression XeSS ».

Erreurs courantes : symptômes → cause racine → correction

1) Traînées fantômes derrière les personnages lors du strafing

Symptômes : Les bords des personnages s’étalent, surtout sur des fonds à fort contraste. Pire en mode Performance.

Cause racine : Vecteurs de mouvement incorrects ou manquants pour les meshes skinnés ou certains LOD ; mismatch de convention des vecteurs.

Correction : Valider les vecteurs dans le moteur ; forcer la vélocité pour tous les LOD ; unifier l’espace de coordonnées et l’échelle ; réinitialiser l’historique sur téléport.

2) L’UI devient floue ou « tremblotante » quand XeSS est activé

Symptômes : Le texte HUD semble reconstruit ; les bords vacillent lors des mouvements de caméra.

Cause racine : L’UI est rendue dans l’entrée basse résolution qui est ensuite traitée temporellement.

Correction : Rendre l’UI à la résolution de sortie après l’upscale (ou utiliser un chemin de composition approprié). Garder l’UI hors du pipeline temporel.

3) Lignes fines scintillantes (clôtures, fils) qui empirent avec l’accentuation

Symptômes : La géométrie distante scintille ou rampe. Les joueurs parlent de « bruit ».

Cause racine : Instabilité temporelle due au sous-échantillonnage + accentuation agressive ; historique bruité ; mauvaise gestion des désocclusions.

Correction : Réduire l’accentuation en modes basse qualité ; améliorer la stabilité du pattern de jitter ; assurer des masques réactifs pour les matériaux problématiques ; envisager de limiter la contribution de l’historique.

4) Pics de temps par image toutes les quelques secondes

Symptômes : Le FPS moyen est correct, mais des micro-saccades dégradent la sensation comparée au natif.

Cause racine : Compilation de shaders, IO de streaming ou thrash d’allocations transitoires pour les buffers d’historique.

Correction : Précompiler les pipelines, chauffer les caches, rendre le streaming entièrement asynchrone et réutiliser les allocations pour les targets d’historique à travers changements de résolution/mode.

5) « XeSS le rend plus lent que le natif » dans une scène particulière

Symptômes : Activer XeSS réduit le FPS ou augmente le temps GPU.

Cause racine : Vous étiez CPU-bound ; ou le coût de reconstruction dépasse les économies raster ; ou la pile de post ne se réduit pas avec la résolution interne.

Correction : Vérifier la saturation GPU ; mesurer les économies raster sans upscaler ; puis ajouter le coût de l’upscaler. Déplacer les post-effets lourds pour qu’ils opèrent à la résolution interne quand approprié.

6) Pompage de luminosité ou flicker d’exposition

Symptômes : Lors des transitions, la luminosité oscille ; semble être un tonemapping instable.

Cause racine : Fournir des métadonnées d’espace colorimétrique/exposition incohérentes d’image en image ; auto-exposition trop agressive pour l’accumulation temporelle.

Correction : Stabiliser l’exposition ; assurer un espace d’entrée cohérent ; réinitialiser ou amortir la contribution d’historique lors de grands changements d’exposition.

7) Les artefacts explosent autour de l’eau, du brouillard, des particules

Symptômes : Traînées, halos et « ébullition » dans les effets transparents.

Cause racine : Masque réactif / gestion des transparences manquante ; profondeur/vecteurs de mouvement pauvres pour le contenu alpha-blended.

Correction : Implémenter des masques pour réduire la dépendance temporelle ; séparer les passes ou composer après l’upscale quand possible ; améliorer la gestion des vecteurs pour les particules.

8) Comportement étrange uniquement sur le GPU d’un seul fournisseur

Symptômes : Ça a l’air correct sur Arc, mauvais sur un autre GPU (ou vice-versa).

Cause racine : Différent chemin XeSS (XMX vs DP4a), différences de pilote, différences de précision et d’ordonnancement.

Correction : Élargir les tests matriciels ; logger quel chemin est actif ; créer des baselines spécifiques fournisseur ; éviter la culture du « un GPU = la vérité ».

Checklists / plan étape par étape

Checklist A: Shipping XeSS without embarrassing yourself

1. Définir les budgets de temps par image cibles (paliers 60/120 FPS) et les faire respecter dans le gating perf.
2. Instrumenter le mode et la voie : logger l’état XeSS activé, le mode, la résolution d’entrée, la résolution de sortie et la sélection XMX/DP4a.
3. Validation des vecteurs de mouvement : construire une vue debug et l’exiger en revue de code pour les nouvelles fonctionnalités de rendu.
4. Gestion de l’historique : réinitialiser sur coups de caméra, téléport, grands changements de FOV et sauts d’exposition importants.
5. Composition UI : s’assurer que l’UI est rendue après l’upscale à la résolution de sortie.
6. Plan pour les transparences : masque réactif ou composition séparée pour eau/brouillard/particules.
7. Politique d’accentuation : plafonner l’accentuation par mode ; assurer qu’elle peut être désactivée pour le diagnostic.
8. Tests thermiques et d’alimentation : inclure au moins un appareil type portable dans la matrice.
9. Matrice pilote : épingler un pilote « connu bon » et tester un pilote plus récent par cycle.
10. Banc de régression : trajectoires de caméra fixes avec captures d’images et traces de temps par image.

Checklist B: When XeSS quality complaints appear in the wild

1. Collecter : modèle GPU, version du pilote, mode XeSS, résolution, et si le problème apparaît en natif.
2. Demander : un court clip montrant l’artefact et l’emplacement exact ou la mission.
3. Reproduire : sur un appareil Intel Arc et un appareil non-Intel si applicable.
4. Bascule : désactiver l’accentuation, puis comparer. Si l’artefact disparaît, vous amplifiez une instabilité.
5. Inspecter : vecteurs de mouvement et profondeur autour de la zone d’artefact.
6. Décider : correction de contenu (vecteurs/masques) vs atténuation par réglages (valeurs par défaut/mise en limite de l’accentuation) vs escalade pilote.

Checklist C: When perf regresses after enabling XeSS

1. Vérifier : êtes-vous GPU-bound ? Contrôler GPU busy et saturation des threads CPU.
2. Mesurer : économies raster sans upscaler ; puis ajouter le coût de l’upscaler.
3. Contrôler : usage VRAM et saccades de streaming ; XeSS ne corrige pas la famine mémoire.
4. Auditer : effets post — tournent-ils toujours à la résolution de sortie ?
5. Stabiliser : caches (shader/pipeline) et environnement (thermiques/governor) avant de comparer les chiffres.

FAQ

Intel XeSS est-il « juste comme DLSS » ?

Mêmes problématiques, stratégie d’écosystème différente. DLSS est étroitement lié au matériel et aux outils NVIDIA. XeSS vise à être plus large, avec les meilleurs résultats sur XMX d’Intel mais une voie de secours pour d’autres GPU.

XeSS est-il meilleur que FSR ?

Ça dépend du jeu, de la qualité d’intégration et du mode. Le facteur le plus différenciant en pratique est souvent la correction de l’intégration (vecteurs, masques, réinitialisations d’historique), pas la marque.

XeSS fonctionne-t-il sur des GPU non-Intel ?

Oui, via la voie DP4a, sur le matériel qui la supporte. Attendez-vous à des profils de performances et d’artefacts différents. Testez ; n’assumez pas la parité.

Pourquoi je vois du ghosting avec XeSS ?

Presque toujours des vecteurs de mouvement ou un mauvais usage de l’historique : vélocités manquantes, conventions erronées ou échec de réinitialisation sur discontinuités. Baisser l’accentuation peut réduire la visibilité mais ne corrige pas la cause racine.

Pourquoi XeSS réduit-il parfois le FPS ?

Si vous êtes CPU-bound, réduire la résolution de rendu ne vous aidera pas. Ou bien le coût de reconstruction peut dépasser les économies raster si la scène est déjà légère en shading mais lourde en reconstruction.

Quel est le premier réglage à changer quand les joueurs se plaignent de « scintillement » ?

Réduire l’accentuation et passer d’un cran vers un mode de qualité supérieur (résolution d’entrée plus élevée). Si le scintillement persiste, inspecter la géométrie fine et le comportement des désocclusions.

Ai-je besoin de jitter pour XeSS ?

Pour une reconstruction temporelle de haute qualité, oui. Pas de jitter signifie généralement moins de détail récupérable et plus de dépendance à des heuristiques. Mais le jitter doit être géré soigneusement pour garder l’UI et les effets en espace écran stables.

Comment garder l’UI nette avec XeSS activé ?

Rendre l’UI après l’upscale à la résolution de sortie, ou l’exclure de l’accumulation temporelle. L’UI et les pipelines temporels ne sont pas amis à moins que vous ne les forciez à se comporter.

Quel est le piège d’intégration le plus courant ?

Supposer que des vecteurs de mouvement « assez bons » pour le TAA ou le motion blur le sont pour la reconstruction. Les upscalers sont moins tolérants car les erreurs se composent au fil du temps.

Dois-je définir XeSS par défaut sur Quality ou Balanced ?

Définissez par défaut en fonction de votre contenu et du palier matériel visé. Si vous tenez aux critiques, préférez le mode offrant le moins d’artefacts visibles pour vos scènes courantes, même s’il est légèrement plus lent. Les joueurs pardonnent un FPS inférieur plus facilement qu’une image « étrange ».

Prochaines étapes à exécuter cette semaine

• Ajouter des logs maintenant : enregistrer l’état XeSS activé, le mode, la résolution interne, la résolution de sortie et quel chemin (XMX/DP4a) est actif.
• Construire une vue debug des vecteurs de mouvement et l’inclure dans l’acceptation des nouvelles fonctionnalités de rendu et des changements de LOD.
• Créer une suite de régression de 10 scènes (géométrie fine, particules, eau, panoramiques rapides, coupures de caméra) et capturer images + temps par image nightly.
• Séparer les questions de performance : mesurer « économies raster » vs « coût de l’upscaler » pour ne pas chasser le mauvais goulot.
• Plafonner l’accentuation et la rendre configurable par mode ; livrer des valeurs conservatrices par défaut.
• Épingler une base de pilotes dans votre labo et traiter les changements de pilotes comme des mises à jour de dépendances : testées, graduées, réversibles.

Intel a rejoint la bataille via le logiciel parce que le logiciel s’étend sur le matériel, les écosystèmes et les priorités des studios. XeSS est un véritable outil — utilisez-le comme tel. Validez les entrées, mesurez les sorties et ne laissez pas une case cochée décider de vos choix architecturaux.