La nouvelle base de DXVK change des points sensibles du pipeline graphique, avec des gains concrets sur la mémoire et le comportement des shaders. Elle introduit aussi une vraie ligne de fracture côté Windows : certaines Radeon RDNA1 et RDNA2 doivent rester sur la branche 2.x.
DXVK 3.0 revoit sa base Vulkan et la compilation des shaders
Cette version majeure du traducteur Direct3D vers Vulkan utilisé par Wine, Proton et d’autres couches de compatibilité bascule sur dxbc-spirv pour la compilation des shaders sur tous les shader models pris en charge. Le projet indique que ce changement corrige plusieurs défauts d’affichage liés à des comportements indéfinis dans certains jeux ou à des sorties FXC invalides.
Le nouveau compilateur peut aussi réduire l’usage de la mémoire système d’environ 1 Go dans des jeux comme Overwatch et God of War. La compilation des shaders passe désormais sur des threads de travail, avec à la clé des lancements potentiellement plus rapides et moins de saccades liées à la compilation à la volée.
DXVK 3.0 active également VK_EXT_descriptor_heap par défaut sur les pilotes compatibles. Le chemin descriptor buffer introduit avec DXVK 2.7 est désormais déprécié et sera retiré plus tard ; chez NVIDIA, cela impose un pilote 595.84 ou plus récent.
Comme d’habitude, l’usage le plus visible reste Linux, mais DXVK peut aussi être employé sous Windows en déposant des DLL Direct3D de remplacement dans le dossier d’un jeu. Ce point devient important avec 3.0, car toutes les configurations Windows ne profitent pas du même niveau de prise en charge.
D3D9 progresse, mais Windows impose plus de précautions
Le bloc D3D9 reçoit plusieurs ajustements, dont la gestion du fixed-function pipeline via des ubershaders. DXVK modifie aussi certains transferts de buffers pour mieux coller au comportement de Windows, ce qui peut corriger des plantages dans des jeux D3D9 32 bits et améliorer les performances sans Resizable BAR, notamment dans GTA IV.
Le projet retire la variable d’environnement DXVK_FRAME_RATE utilisée par le limiteur d’images intégré. La recommandation va désormais vers des limiteurs externes comme Gamescope ou MangoHud, jugés plus réguliers sur le frame pacing ; ceux qui veulent conserver la solution interne doivent passer par dxvk.maxFrameRate = n dans le fichier de configuration.
Autre changement ciblé : DXVK ne simulera plus l’identifiant constructeur des GPU Intel via DXGI dans les jeux compatibles XeSS 2. Le contournement servait avec d’anciennes versions de XeSS, mais il créait désormais des problèmes dans certains jeux D3D12.
Le point le plus délicat concerne les Radeon RDNA1 et RDNA2 sous Windows. DXVK 3.0 fonctionne globalement sur ces GPU, mais le pilote AMD pour Windows ne reçoit plus les mises à jour de fonctionnalités nécessaires ; ces cartes restent limitées à l’ancien modèle de binding, plus lent, avec des pertes de performances sévères absentes sur les autres pilotes. Le projet conseille donc de rester sur DXVK 2.x, d’autant que Vulkan 1.4 est requis pour DXVK 3.0 et n’est pas disponible sur ces GPU dans ce contexte.
Cette mouture confirme aussi que DXVK n’est plus seulement un outil de compatibilité, mais un composant qui dépend de plus en plus directement de l’état réel des pilotes Vulkan. Sur Linux, la progression reste logique ; sous Windows, elle met surtout en lumière les plateformes qui n’évoluent plus côté pilote.
Source : VideoCardz
