L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Quatre demandes ouvertes déposées le 19 octobre permettraient à XeSS d’utiliser les unités matricielles XMX sur une carte Intel Arc lorsqu’un jeu s’exécute sous Proton, au lieu du chemin de repli plus lent qu’il emprunte actuellement. Tous les quatre ont été ouverts par Damian Tomczak, dont le profil GitHub indique Intel comme son organisation, aucun d’entre eux n’a été fusionné et Valve n’a rien dit à leur sujet.
Celui dans l’arborescence de Valve est la demande d’extraction Proton 10289, « xess xmx : utilisez un libxess.so natif pour XeSS lorsqu’il est disponible », ouverte à 06h48 UTC sur la branche de pointe avec cinq commits. Sa description indique qu’il « oblige Proton à utiliser le libxess.dll intégré de wine avec un libxess.so natif, afin que XeSS puisse utiliser XMX », Proton recherchant cette bibliothèque dans une variable définie par l’utilisateur, puis dans son propre répertoire contrib, puis dans le chemin de la bibliothèque système.
Wine, vkd3d-proton et DXVK réalisent le vrai travail
La moitié Wine, pull request 369, ajoute un libxess.dll intégré qui « transfère les appels XeSS D3D12 à la bibliothèque Linux XeSS (libxess.so), afin que XeSS puisse utiliser XMX (l’upscaler rapide) sous Proton au lieu du chemin de secours plus lent », convertissant les objets D3D12 en Vulkan via l’interface d’interopérabilité de vkd3d-proton. vkd3d-proton 3379 active ensuite les extensions et fonctionnalités Vulkan demandées par XeSS, en lisant la liste depuis XeSS lui-même et en ne changeant rien si la DLL ne peut pas être chargée.
La requête DXVK est la plus révélatrice. La demande d’extraction 5992 indique que DXVK propose une solution de contournement du fournisseur qui masque un GPU Intel de tout jeu dont libxess.dll est antérieur à 2.0.2.68, et que la copie de Proton de cette DLL « est un transfert intégré de Wine vers la bibliothèque Linux XeSS, elle n’a pas de ressource de version, donc la vérification a toujours échoué et le GPU Intel a été masqué ». L’option dxgi.hideIntelGpu remplace toujours le nouveau comportement.
Seuls deux des quatre référentiels appartiennent à Valve. vkd3d-proton et DXVK sont des projets distincts que Proton épingle en tant que sous-modules, c’est pourquoi l’auteur écrit que la requête Proton « supplante les trois autres sous-modules, elle devrait donc être placée en dernier ». Cette route peut être rapide lorsque les pièces atterrissent : un correctif DXVK pour un crash anti-triche d’EA est apparu dans une version de pointe de Proton six heures après sa fusion.
Rien n’a fusionné et le code est antérieur aux requêtes
La demande Proton ne contient aucune critique et un commentaire, de la part de son auteur, répertoriant la série. Le code qu’il contient est plus ancien que la demande : le commit Proton, c89e3cc, est rédigé par Caleb Callaway à partir d’une adresse intel.com et daté du 10 septembre, cinq semaines et demie avant que quoi que ce soit ne soit déposé, et il ajoute 114 lignes à un seul fichier.
Aucun des quatre ne contient de référence, de fréquence d’images, de liste de jeux ou de mot sur les gains des générations Arc. La seule affirmation figurant dans le dossier est celle des demandes, à savoir que le changement permet à XeSS d’atteindre XMX, et qu’aucune d’entre elles ne renvoie à quoi que ce soit publié par Intel.
L’upscaler d’Intel n’a pas non plus été prévisible sur Windows, où son remplacement de la génération d’images ne s’active que lorsque les paramètres du jeu sont activés. Sous Linux, la situation est plus simple : les quatre requêtes sont ouvertes, Valve n’a pas répondu à celle de Proton, et aucune version de Proton ne contient encore rien de tout cela.