Pilote GPU Nvidia 4090 hacké, P2P activé
(github.com/tinygrad)Ajout de la prise en charge P2P au pilote NVIDIA Linux Open GPU
Ce projet est un fork du pilote NVIDIA pour ajouter la prise en charge P2P au GPU 4090.
- Installation simple en exécutant
./install.sh - Il peut être nécessaire de supprimer d’abord le pilote existant dans DKMS
- Le système doit prendre en charge Large BAR et IOMMU doit être désactivé
- Il n’est pas certain que tous les flushs de cache soient corrects, donc merci de signaler tout problème découvert
- Il ne s’agit pas d’un hack, mais d’une implémentation conforme à la spécification PCIe, qui pourrait être intégrée en amont avec un peu de mise au propre
Principe de fonctionnement
Problèmes du P2P NVIDIA existant
- Jusqu’ici, les transferts mémoire entre GPU utilisaient une interface matérielle appelée MAILBOXP2P
- Sur la 4090, ce matériel est absent ou désactivé, donc le P2P ne fonctionne pas
- Les premiers pilotes indiquaient que cela fonctionnait mal, mais en réalité les transferts passaient bien par le bus PCIe
- Cependant, faute de matériel mailbox, les données copiées n’arrivaient pas au bon endroit et pouvaient provoquer un crash système
Ajout de la prise en charge Large BAR
- NVIDIA a ajouté la prise en charge Large BAR sur certaines 3090 et sur toutes les 4090
- Sur la H100, un mode PCIe appelé BAR1P2P, qui utilise directement BAR au lieu de la mailbox, a été ajouté
- Pour l’activer sur la 4090, il faut contourner la HAL et appeler directement les méthodes GH100
- Mapper toute la VRAM sur BAR1 avec des méthodes comme
kbusEnableStaticBar1Mapping_GH100 - Il a fallu désactiver l’utilisation de cette zone dans la fonction
MapAperture
- Mapper toute la VRAM sur BAR1 avec des méthodes comme
Difficultés d’activation du P2P
- Même après le mapping de la VRAM, l’exécution de
./simpleP2Pdanscuda-samplesprovoquait une erreur MMU- Le type de mapping
GMMU_APERTURE_PEERest utilisé, mais il n’est pas pris en charge sur la 4090 - Les types pris en charge sur la 4090 sont uniquement
GMMU_APERTURE_VIDEO,GMMU_APERTURE_SYS_NONCOH,GMMU_APERTURE_SYS_COH
- Le type de mapping
GMMU_APERTURE_PEERa été remplacé parGMMU_APERTURE_SYS_NONCOH- Parce qu’il n’y a pas besoin de cohérence avec le cache L2 du CPU, mais que les données doivent sortir via le bus PCIe
- Le champ d’adresse pair
fldAddrPeera été remplacé parfldAddrSysmem - Une adresse de base basée sur
BAR1a été définie dans le champfabricBaseAddress
Vérification du fonctionnement
- Vérification du bon fonctionnement de
./simpleP2P- P2P fonctionnel entre GPU0 et GPU1 à 24 Go/s
- Vérification de la bande passante bidirectionnelle avec
p2pBandwidthLatencyTest- Mesure de 920 Go/s en bande passante locale et de 51 Go/s en bande passante P2P
- Vérification de la compatibilité avec des tests NCCL
- Avec 6 GPU 4090, une bande passante bus moyenne de 24,5 Go/s a été atteinte
L’avis de GN⁺
- Le fait qu’une grande partie du pilote NVIDIA soit publiée en open source semble avoir permis ce type d’initiative dans la communauté des développeurs. On peut espérer que davantage de composants seront ouverts à l’avenir.
- Si la puissance de la 4090 peut être exploitée en reliant plusieurs cartes, même des développeurs indépendants ou de petits laboratoires pourront entraîner des modèles d’IA de très grande taille.
- Mais le fait que les développeurs soient encore obligés de manipuler eux-mêmes des aspects aussi dépendants du matériel et complexes montre aussi que NVIDIA n’a pas encore totalement finalisé la prise en charge de la 4090.
- Cela reste en outre limité au pilote Linux, et un usage commercial sous Windows semble encore très lointain. On espère que NVIDIA apportera rapidement un support officiel.
- La 4090 étant un matériel très récent, il semble difficile d’attendre une compatibilité parfaite avec des bibliothèques et frameworks ML comme CUDA, PyTorch ou Tensorflow. Il faudra probablement attendre une meilleure stabilisation.
Aucun commentaire pour le moment.