Skywork accélère le rendu neuronal de Matrix-Game 4.0 jusqu’à 67 FPS sur RTX 5080

Vous avez un prototype de jeu : le personnage court, la voiture tourne, les collisions fonctionnent. Mais les graphismes se limitent encore à des modèles simples. Matrix-Game 4.0 propose de faire passer ces images par un réseau neuronal vidéo qui ajoute les détails, pendant que le moteur de jeu continue de calculer ce qui se passe. Pour un développeur, c’est l’occasion de tester dans quelle mesure les graphismes génératifs conviennent à un prototype interactif.

Skywork a publié le code, les poids et les ressources du jeu. Selon l’équipe, le rendu neuronal atteint 67 FPS sur RTX 5080 à une résolution de 864×480. Une précision essentielle : il s’agit du débit du modèle en régime établi, avec des prompts fixes et SageAttention, hors entrées et sorties vidéo. La sortie est également antérieure à la publication d’aujourd’hui : dans le dépôt, elle est datée du 15 octobre, et les optimisations pour la 5080 du 16 octobre. Source : dépôt du projet.

Qui gère le mur, et qui gère sa texture ?

Imaginez une course en ville. Le moteur conserve la position de la voiture, calcule les virages et détermine le moment où elle heurte une barrière. Il dessine ensuite une scène simplifiée. Le modèle vidéo reçoit ces images et les transforme en un rendu plus détaillé.

Cette répartition des tâches permet de conserver les règles du jeu dans du code exécutable. Sur la page du projet, les auteurs décrivent aussi un agent qui traduit les souhaits du joueur en nouvelles règles et en descriptions textuelles de la scène. Le générateur utilise les graphismes simples, la description et des images de référence pour produire les images par lots de quatre. Source : description de l’architecture.

Pour comprendre cette approche, une question simple suffit : qui décide si l’on peut traverser un mur ? Ici, c’est le moteur. Cela ne signifie toutefois pas que le mur dessiné coïncidera toujours exactement avec l’obstacle. La logique peut rester correcte malgré une erreur visuelle. C’est précisément ce type de décalage qu’il faut rechercher lors du premier test du prototype.

Ce que recouvrent les 67 FPS

Dans son rapport technique, l’équipe distingue le débit de génération de la latence des commandes. Pour la RTX 5090, elle indique un jeu à 60 FPS en 480p et un délai de 112 ms entre l’appui sur une touche et l’affichage de la réaction. Elle mentionne séparément une vitesse de génération en une étape de 83 FPS. Ce sont des mesures différentes ; on ne peut pas appliquer à la 5080 la latence mesurée sur la 5090. Source : rapport technique.

La portée pratique de cette différence est facile à saisir. Une voiture peut se déplacer avec fluidité à l’écran, mais tourner avec un retard perceptible après une commande. Le nombre d’images par seconde ne suffit donc pas à déterminer si le jeu est agréable à jouer. Pour votre propre cas d’usage, il faudra mesurer séparément la réactivité aux commandes et la tester lors de manœuvres brusques.

Il existe aussi un compromis entre qualité et vitesse. La fiche du modèle décrit un mode rapide avec une seule étape de génération et le codec TAEHV, ainsi qu’un mode qualité avec deux étapes et Wan VAE. Les modèles sont spécialisés pour les scènes et les caméras fournies. Une géométrie inconnue, des objets qui se masquent mutuellement, des mouvements rapides de caméra et de longues sessions peuvent provoquer des distorsions visuelles. Le code et les données d’entraînement n’ont pas été publiés. Source : fiche du modèle.

Par où commencer pour un développeur ?

Mon conseil pratique : commencer par une scène fournie et un scénario court dont on peut vérifier le résultat. Par exemple, faire un tour, effectuer un demi-tour brusque et revenir au même carrefour. Comparer la géométrie visible à la scène simplifiée du moteur, relever la latence des commandes et vérifier si les objets conservent leur apparence.

L’expérience suivante consiste à modifier un objet ou une portion du parcours. Elle montrera dans quelle mesure le modèle gère des changements au-delà de la scène qui lui est familière. Pour une équipe produit, c’est plus utile qu’une belle vidéo : elle pourra comprendre quelle liberté accorder à l’utilisateur et quelles erreurs il faudra masquer ou corriger.

La valeur potentielle réside ici dans une association vérifiable entre le code du jeu et les images générées. Mais les économies sur la création des graphismes restent, pour chaque projet, une hypothèse : il faut les mettre en regard des coûts de mise en œuvre, d’adaptation des scènes et de contrôle des erreurs visuelles.