L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.
Un correctif pour le gel que les joueurs Linux ont enregistré lorsqu’un Nvidia Xid 109 a atterri dans DXVK, la couche de traduction utilisée par Proton pour exécuter des jeux Direct3D sur Vulkan. La demande d’extraction 5958, « Fusionner les charges de tampon superposées », a été ouverte le 8 octobre et fusionnée dans la branche principale de DXVK à 11 h 39 min 55 s UTC le 10 octobre, lue à 21 h 46 UTC le même jour.
La réclamation qui y est attachée est couverte par la personne qui l’a écrit, le mainteneur de DXVK, Philip Rebohle. Le changement ajoute une passe qui résout les chargements de tampon qui se chevauchent, puis la description indique : « Pour une raison quelconque, cela semble résoudre certains blocages avec NV_raw_access_chains, mais cela pourrait être une bonne idée en général. » Il demande également « un certain nombre de tests (D3D11 uniquement) ».
Une extension Vulkan, isolée par répétition
Le rapport sur lequel il pointe est le numéro 1409 sur le tracker de module de noyau ouvert de Nvidia, ouvert le 30 septembre et toujours ouvert. Il décrit Impassele jeu de tir de héros inédit de Valve, se fige de façon permanente sur un RTX 2070 exécutant le pilote ouvert 615.71.09, l’audio continuant après l’arrêt de l’image et le reste du bureau n’étant pas affecté.
Ce qui le place au-dessus du rapport de crash habituel, c’est que la personne qui l’a déposé a isolé le déclencheur avant de le déposer et a publié le tableau le montrant. Même pilote, même noyau, même version de Proton, mêmes quatre étapes dans la plage de tests du jeu, trois fois : avec VK_NV_raw_access_chains utilisé, Xid 109 à chaque fois ; avec dxvk.enableNvRawAccessChains=False, « Pas de blocage, pas de Xid, pas de DEVICE_LOST » ; avec le tas de descripteurs de DXVK désactivé mais l’extension laissée activée, Xid 109 à nouveau. La faute suit l’extension et ignore le modèle de liaison.
Deux autres machines se trouvent en dessous, toutes deux sur le même module à noyau ouvert 615.71.09. On signale le même blocage et la même solution de contournement sur un RTX 5070, une pièce Blackwell GB205 plutôt que la carte Turing d’origine. Un autre utilise un GPU pour ordinateur portable RTX 3050, où le Xid est arrivé GenshinImpact 7.1.0 après environ une heure et demie plutôt que sur demande. Il s’agit de rapports d’utilisateurs, et non d’un rapport de Nvidia sur un défaut.
Nvidia n’a pas posté dans ce fil
La chaîne d’erreur appartient au module du noyau de Nvidia, contrairement au correctif, la formulation doit donc être soignée. Chaque commentaire sur le numéro 1409 porte une association d’auteur de NONE, donc personne parlant au nom de Nvidia n’y a écrit du tout. Xid 109 avec la chaîne CTX SWITCH TIMEOUT est ce que le module du noyau imprime lorsqu’un changement de contexte manque de temps, ce qui est un symptôme plutôt qu’un diagnostic.
La seule suggestion selon laquelle le gel est résolu vient d’un contributeur de DXVK, qui a posté sur le problème à 15h28 UTC le 10 octobre : « Le blocage de l’impasse devrait disparaître sur dxvk master. »
Fusionné avec le master n’est pas le même que celui expédié
Master est l’endroit où le développement de DXVK se produit, et Proton fournit sa propre version groupée plutôt que de suivre cette branche, donc aucun Proton publié ne le propose encore. Le propre champ d’application de l’auteur, D3D11 uniquement, laisse également de côté le côté vkd3d-proton où des rapports similaires ont été déposés, et sa demande de test ne constitue pas une déclaration finale.
Sa forme est encore inhabituelle. Un blocage qui apparaît dans le journal du noyau alors que le délai d’expiration du pilote graphique s’avère suivre une extension Nvidia Vulkan, et le changement qui semble le régler est un commit touchant deux fichiers dans un projet communautaire, écrit par quelqu’un dont le propre récit de la raison pour laquelle cela fonctionne commence « Pour une raison quelconque ». Les jeux Linux fonctionnent souvent avec ce type de réparation, de Proton Experimental prenant en charge le premier support OpenXR 32 bits au responsable Proton de Valve refusant un correctif de crash sur la provenance du code. La question de savoir si cela efface le Xid pour les personnes qui ont déposé les rapports est désormais pour eux.