Ajouter et tester des noyaux dans une bibliothèque de noyaux GPU compilés en JIT

## Préparer une installation modifiable où modifier un noyau le recompile tout seul Utilisez une installation modifiable qui conserve les versions existantes du cadre logiciel et de l’accélérateur dans l’environnement. Désactivez la résolution isolée des dépendances lorsqu’elle risque d’importer des paquets d’exécution incompatibles. Initialisez tous les sous-modules source requis avant la compilation ou les tests. Traitez la compilation juste-à-temps comme la boucle de développement par défaut. Modifiez les sources du noyau, exécutez un test ciblé et laissez le hachage des sources déclencher la recompilation. Ne réinstallez pas le paquet après chaque modification du noyau, sauf si le code de mise en paquet lui-même a changé. Ne videz le cache JIT que lorsque des artefacts périmés font partie du diagnostic. N’utilisez les paquets de noyaux précompilés que lorsqu’une première utilisation plus rapide ou la distribution l’exige. Gardez les artefacts précompilés facultatifs pour le développement normal. Définissez explicitement les architectures cibles lors d’une compilation destinée à d’autres appareils que le GPU local détecté. Limitez les threads du compilateur et les tâches de compilation parallèles en fonction de la mémoire disponible. Estimez la mémoire totale de compilation en multipliant les tâches par les threads du compilateur et les besoins de chaque thread. Ne laissez pas la taille des paramètres de test provoquer un épuisement évitable de la mémoire de l’appareil. N’installez la prise en charge du profilage que lorsque des mesures matérielles précises sont nécessaires. Exécutez le formatage et les hooks du dépôt avant la révision. ## Écrire les fichiers générés seulement dans des espaces de travail inscriptibles, jamais dans l’installation Représentez chaque chaîne d’outils de compilation par une interface de spécification commune. Attribuez à chaque spécification un nom unique, une liste de sources, des options de compilation, des options d’édition de liens et les architectures prises en charge. Utilisez un modèle partagé de compilation et de chargement pour coordonner la recherche dans le cache, le verrouillage, la compilation et le chargement. Gardez le cycle de vie explicite : tentez de charger depuis le cache, compilez si nécessaire, puis chargez le module compilé. Refusez la compilation JIT lorsqu’une option de désactivation est définie et qu’aucun module valide mis en cache ou précompilé n’existe. N’écrivez jamais de fichiers générés dans les répertoires de paquets installés, car ils peuvent être en lecture seule. Gardez les modèles de sources et les données des paquets précompilés en lecture seule. Écrivez les sources rendues et les unités de compilation copiées uniquement dans un espace de travail réservé aux sources générées. Écrivez les fichiers objets, les bibliothèques partagées, les métadonnées et les fichiers de compilation uniquement dans l’espace de travail des artefacts JIT. Générez le manifeste de compilation à partir de la liste exacte des sources et des options de compilation. Permettez de remplacer l’emplacement des espaces de travail dans les environnements partagés, temporaires ou restreints. Utilisez le contexte d’architecture pour combiner les appareils détectés avec les cibles explicitement demandées. Limitez un module aux familles d’architectures prises en charge avant le début de la compilation. Échouez clairement lorsqu’aucune architecture demandée n’est prise en charge. Ne compilez pas silencieusement pour une autre famille d’appareils. ## Ajouter un nouveau noyau, du code de périphérique jusqu’à l’API publique Implémentez du code d’appareil indépendant du cadre logiciel sur des pointeurs bruts et des types de noyaux portables. Écartez les en-têtes du cadre logiciel de la couche d’inclusion réutilisable des noyaux. Ajoutez un lanceur dans la couche de liaison pour valider les tenseurs et préparer les paramètres d’appel. Exportez le lanceur par l’intermédiaire de la FFI typée et multilingue du projet. Calculez un URI d’opération déterministe à partir des paramètres de spécialisation. Créez un répertoire de génération par opération dans l’espace de travail inscriptible des sources. N’utilisez un modèle que lorsqu’une spécialisation concrète de type ou de paramètre est nécessaire. N’écrivez la configuration rendue que lorsque son contenu diffère. Copiez les unités de compilation requises dans le répertoire de génération. Renvoyez une spécification de compilation contenant l’URI, les sources, les options et les limites d’architecture. Exposez une API de haut niveau mise en cache qui réutilise les modules chargés. Enregistrez l’opération pour la génération anticipée de paquets lorsque la distribution l’exige. Exportez l’API publique depuis le point d’entrée du paquet. Associez un modèle de traçage qui définit les axes, les entrées, les sorties et une référence facultative. Pour les API de planification et d’exécution, associez le traçage à la méthode qui réalise l’exécution. Ajoutez un exemple de traçage réaliste, régénérez les artefacts de définition des bancs d’essai et validez les sorties attendues. Exécutez des tests de cohérence du traçage et de bout en bout après la régénération. ## Ignorer les GPU non pris en charge dans les tests et appuyer la vitesse sur des vérifications de résultats Exécutez la suite complète de tests pour une validation étendue et des tests ciblés pendant les itérations. Ignorez délibérément le matériel non pris en charge au moyen des fonctions auxiliaires centrales de détection des capacités. Vérifiez à la fois la capacité de calcul de l’appareil et la prise en charge du moteur lorsqu’une API expose ces prédicats. Gardez explicites les exigences d’architecture de chaque fonctionnalité. Ne transformez pas une architecture non prise en charge en échec de test. N’ignorez pas une architecture prise en charge parce que l’appareil local est différent. Choisissez des formes de test qui exercent le contrat sans provoquer d’omissions évitables dues à un manque de mémoire. Couvrez les chemins d’attention, de multiplication matricielle, de mélange d’experts, de communication et d’utilitaires affectés par une modification. Utilisez des outils de lancement multiappareil pour les tests collectifs ou distribués. Effectuez les mesures avec un banc unifié qui prend en charge des moteurs comparables et des configurations groupées. Préférez la mesure d’un profileur matériel et revenez aux événements de l’accélérateur lorsqu’elle n’est pas disponible. Consignez le mécanisme de mesure ayant produit chaque résultat du banc d’essai. Indiquez la médiane, la variation, le nombre d’itérations, la forme de la charge de travail, le type de données, l’architecture et le moteur. Activez la vérification par rapport à une référence lorsque vous comparez des noyaux. Ne présentez aucune affirmation de vitesse sans contrôle de l’exactitude et paramètres reproductibles. Exigez des preuves issues des bancs d’essai et des tests avant d’approuver un noyau sensible aux performances. ## Recompiler les noyaux en cache quand leurs sources ou le GPU cible changent Utilisez un cache interne au processus pour les modules chargés et un cache sur disque pour les artefacts compilés. Invalidez les modules mis en cache lorsque les sources, les options, l’architecture, les paramètres ou la version de la bibliothèque changent. Dérivez l’identité du cache du type d’opération, des paramètres, des hachages des sources, des options et de l’architecture cible. Gardez les clés de cache uniques entre les variantes de spécialisation et de chaînes d’outils. Stockez les métadonnées de compatibilité à côté des artefacts et validez-les avant le chargement. Protégez la compilation avec un verrouillage afin que les processus simultanés ne corrompent pas les artefacts partagés. Pour les sorties DSL d’une seule architecture, stockez un répertoire de module avec ses métadonnées et un objet par spécialisation. Dérivez l’architecture de la cible de compilation DSL ou de l’appareil actif. Invalidez un module DSL lorsque la version du paquet de son compilateur ou le hachage des sources du noyau change. Autorisez la désactivation du cache à des fins de diagnostic, tout en gardant la réutilisation activée par défaut. Utilisez des macros de répartition ou du code généré pour gérer les espaces combinatoires de types de données et de tailles de blocs. Gardez explicites les choix de répartition et testez les combinaisons non prises en charge. N’ajoutez pas de modèles lorsque le code source direct suffit. Ne laissez pas des paquets précompilés périmés contourner les contrôles de compatibilité des versions. Ne contournez les contrôles de version que pour une expérience volontaire et diagnostiquée mêlant plusieurs versions. ## Journaliser les entrées de l’API avant l’exécution des noyaux pour reproduire les plantages Consignez les entrées de l’API avant l’exécution du noyau afin que les paramètres responsables d’un plantage subsistent après une défaillance de l’appareil. Gardez la journalisation sans surcoût lorsqu’elle est désactivée. Proposez des niveaux progressifs pour les noms d’appels, les entrées et sorties, ainsi que les statistiques coûteuses. Réservez les statistiques et l’analyse des valeurs non valides aux diagnostics détaillés explicitement demandés. Ignorez la collecte de statistiques incompatible pendant la capture du graphe. Limitez les vidages de diagnostic par nombre d’événements et taille totale. Prenez en charge les filtres d’inclusion et d’exclusion afin que la capture coûteuse ne cible que les API pertinentes. Choisissez un format de tenseur portable lorsque les vidages doivent être transférés entre environnements. Utilisez un répertoire de vidage dédié et inscriptible. N’activez la sortie détaillée de compilation et les symboles de débogage que pendant le diagnostic des défaillances. Examinez ensemble les sources générées, les manifestes de compilation, les modules compilés et les métadonnées du cache. Consignez les formes, les types de données, l’architecture, les options et le moteur sélectionné lorsque vous reproduisez un plantage. Utilisez les informations de ligne lorsqu’un profileur ou un débogueur nécessite une correspondance avec le code source. Séparez les paramètres d’optimisation normaux des compilations de débogage. Traitez les choix forcés d’algorithme ou de moteur comme des contrôles de diagnostic, et non comme des valeurs de production par défaut. Documentez chaque contrôle non défini par défaut utilisé pour reproduire un résultat. ## Vérifier les artefacts téléchargés et publier pour une liste explicite de GPU Échouez de manière définitive lorsque des artefacts locaux manquent dans un environnement hors ligne ou verrouillé. Permettez à un miroir de confiance de remplacer le dépôt d’artefacts par défaut. Vérifiez par défaut les sommes de contrôle des artefacts téléchargés. Ne désactivez la validation des sommes de contrôle que comme aide temporaire au débogage. Limitez les téléchargements parallèles d’artefacts. Préférez une source locale configurée avant de tenter un téléchargement. Gardez les options de compilation et les substitutions du lanceur explicites et observables. Distinguez les contrôles de journalisation du chargeur d’artefacts de ceux des appels d’API. Utilisez une mesure stable pour le réglage automatique, notamment un minuteur matériel global lorsque la mesure par événements n’est pas fiable. Permettez de remplacer la détection du calcul confidentiel pour un diagnostic contrôlé d’intégration continue. Ne conservez les résultats du réglage automatique qu’avec un emplacement de cache explicite et un environnement compatible. Chargez une liste de blocage des tactiques pour éviter les noyaux connus pour se bloquer ou planter avec la pile actuelle. Laissez les substitutions expérimentales de routage et de sélection des noyaux à leurs valeurs documentées par défaut. Compilez des paquets par anticipation pour une liste explicite d’architectures. Générez les métadonnées de version du paquet à partir d’une source de versions unique faisant autorité. Utilisez des incréments de version rétrocompatibles pour les noyaux, la prise en charge des appareils et les corrections de bogues. Réservez les modifications d’API incompatibles à une frontière de version architecturale. ## Garder l’API publique et la documentation alignées sur le code des noyaux Utilisez une ABI typée et multilingue afin que les mêmes noyaux puissent servir plusieurs cadres logiciels hôtes. Conservez la gestion des tenseurs propre au cadre logiciel dans les liaisons plutôt que dans les en-têtes d’appareil. N’enregistrez des opérations personnalisées dans le cadre logiciel hôte que lorsque la compilation et la capture du graphe l’exigent. Gardez synchronisés l’API Python, le générateur JIT, l’exportation des liaisons, le registre de compilation anticipée et les exportations du paquet. Commencez par le modèle de noyau fonctionnel le plus simple avant d’adopter des conceptions avancées d’espace de travail ou de planification et d’exécution. Mettez à jour ensemble les signatures de fonctions, les modèles, les lanceurs et les tests lorsque les paramètres changent. Apprenez le style, la complexité, la programmation défensive et l’efficacité établis à partir d’exemples fonctionnels proches. Documentez les écarts volontaires et les choix d’algorithmes critiques pour les performances, ainsi que les alternatives envisagées. Consultez la documentation faisant autorité sur le jeu d’instructions et la chaîne d’outils pour les comportements propres à une architecture. Préférez le code source des dépendances fourni avec le projet lorsque la documentation externe est périmée. Gardez les modèles de traçage et les définitions générées des bancs d’essai synchronisés avec les API publiques. Mettez à jour les exemples et tutoriels d’infrastructure lorsque les modèles de journalisation, d’exigences, de FFI ou de génération de code changent. Marquez clairement les approches obsolètes ou retirez-les des consignes actuelles. Déclarez toute aide significative de l’IA conformément à la politique de contribution. N’approuvez que lorsque les sources, les artefacts générés, les caches, les tests, les bancs d’essai, les exportations et la documentation concordent.