Les outils Vix de Panchovix chargent une image de VBIOS modifiée sans écrire sur la puce flash du GPU : l’éditeur crée une copie, puis un chargeur la transmet au pilote Windows ou à GSP sous Linux. Pour évaluer leur compatibilité, il faut examiner séparément les exigences et les configurations testées sur chaque système.
Ce que signifie le chargement sans flash
NVIDIA VBIOS Vix Editor sert à inspecter et modifier une image de VBIOS, puis à enregistrer une nouvelle copie plutôt qu’à réécrire la ROM d’origine. « Sans flash » décrit donc le fait que la puce flash de la carte n’est pas écrite par ces chargeurs : une image modifiée est néanmoins chargée comme surcharge logicielle. La documentation de l’éditeur décrit cette copie modifiée et les champs éditables.
Windows et Linux utilisent deux mécanismes différents
Sous Windows, le chargeur place l’image et les valeurs associées dans la clé de registre du pilote GPU, puis redémarre le GPU. La commande Verify contrôle si le pilote utilise la surcharge enregistrée; unload la supprime. Sous Linux, le chargeur modifie les modules ouverts du noyau NVIDIA afin que le processeur système du GPU, ou GSP, démarre avec l’image en mémoire. Il crée une entrée de démarrage distincte et conserve l’entrée normale comme solution de retour. La documentation Windows et la documentation Linux détaillent ces voies.
Dans la capture publiée par Panchovix sur Reddit, la fenêtre du chargeur présente une liste de périphériques, une ligne sélectionnée, des commandes et une zone de journal.
| Système | Chargement de l’image | Retour au démarrage normal |
| Windows | Surcharge dans le registre du pilote, suivie d’un redémarrage du GPU. | La commande unload supprime la surcharge. |
| Linux | Modules ouverts NVIDIA modifiés; GSP démarre avec l’image en mémoire. | Une entrée de démarrage normale reste disponible. |
Les prérequis et configurations testées
Le chargeur Windows demande Windows 10 ou 11 en 64 bits, des droits administrateur et un pilote NVIDIA de la branche 616.x ou 617.x, en version 616.56 ou ultérieure. Le fichier chargé doit correspondre à l’identifiant PCI exact du GPU. Le projet cite des essais sur GeForce RTX 5070, GeForce RTX 4090 et RTX A2000; il classe d’autres cartes Ampere et Ada comme non testées. La documentation du chargeur Windows décrit aussi Verify et unload. Une installation propre ou une mise à jour du pilote peut supprimer la surcharge.
Pour Linux, la configuration indiquée comme prise en charge sur matériel réel associe Fedora 43, GRUB/BLS, dracut, DNF5 et les modules de noyau ouverts NVIDIA 615.x installés avec le programme .run. Les prérequis comprennent aussi Python 3.11 ou ultérieur et les en-têtes du noyau; Secure Boot doit être désactivé ou configuré avec une clé de signature utilisateur. La liste des GPU testés sur matériel réel comprend les GeForce RTX 5090, 5080, 5070 Ti, 5070 et 5060 Ti, ainsi que des variantes RTX PRO 6000 Blackwell et la RTX 2000 Ada. Les autres combinaisons de distribution, de pilote et de méthode d’installation ont des statuts différents, notamment expérimentaux ou non pris en charge. La documentation Linux détaille ces configurations.
Les réglages varient selon l’architecture
Les champs disponibles ne sont pas identiques d’une architecture à l’autre. Pour Blackwell GB20x, l’éditeur décrit notamment des réglages de puissance, de tension, de VMIN, de décalage d’horloge, de courant et de ventilation. Ada et Ampere ont leurs propres champs; la modification et le chargement sur Turing sont présentés comme expérimentaux. Pour Ada et Ampere, le GSP lit au maximum 512 Kio depuis l’image historique, ce qui impose de déplacer la charge utile; les voies de déplacement concernées sont elles aussi signalées comme expérimentales. La documentation de l’éditeur précise ces limites.
Le projet indique que les modifications des timings de mémoire vidéo ne s’appliquent pas, car la carte lit ces timings dans son firmware physique. Sur un portable, Dynamic Boost peut limiter la puissance effective; les ventilateurs du portable ne sont pas commandés par l’image VBIOS.
Une surcharge logicielle ne supprime pas le risque matériel
La documentation du projet avertit que des réglages de puissance, de courant ou de tension au-delà des limites prévues pour la carte peuvent endommager le matériel. Elle indique aussi que la signature cryptographique d’une image modifiée ne correspond plus et déconseille de flasher cette image avec nvflash. Le fait de laisser intacte la puce flash ne protège donc pas les composants contre des réglages dangereux.
