Verticale GPU¶

Status: TARGET

Cette page décrit le contrat cible d’une verticale GPU. Elle ne prouve pas qu’un module GPU autonome est actuellement actif dans le Runtime.

Rôle¶

La verticale GPU doit encapsuler les règles propres aux cartes graphiques lorsque celles-ci nécessitent des preuves métier qui ne sont pas suffisamment génériques pour le Domain Core.

Elle peut contribuer à :

reconnaître une famille GPU ;
distinguer chipset et modèle commercial de carte ;
normaliser la mémoire vidéo ;
détecter des variantes ou éditions incompatibles ;
produire des signaux de conflit ;
enrichir les candidats destinés au Resolver.

Elle ne doit pas décider seule de l’identité persistée.

Attention sur le modèle public actuel¶

Le registre de navigation publique peut exposer des cartes graphiques sous une verticale générique telle que pc_component avec un accessory_type dédié.

Cela ne prouve pas qu’une verticale métier gpu autonome existe dans le Runtime.

Avant d’implémenter ou d’activer ce module, vérifier si les règles GPU doivent :

rester dans une verticale pc_component ;
devenir un sous-module spécialisé ;
ou justifier réellement une verticale autonome.

Cette décision appartient à l’architecture, pas à la navigation.

Attributs structurants cibles¶

Les preuves pertinentes peuvent inclure :

fabricant du GPU ;
famille ou génération ;
modèle de chipset ;
constructeur de la carte ;
quantité de VRAM ;
type de mémoire ;
édition ou variante commerciale ;
facteur de forme lorsque pertinent ;
caractéristiques explicitement distinctives.

Il faut distinguer soigneusement le chipset de la carte commerciale. Deux cartes utilisant le même GPU ne sont pas nécessairement la même identité produit.

Conflits à préserver¶

Exemples de conflits potentiellement bloquants :

chipset différent ;
génération différente ;
VRAM explicitement incompatible ;
édition commerciale incompatible ;
confusion entre carte graphique et autre composant PC ;
marque ou référence fabricant contradictoire lorsque celle-ci fait partie de l’identité.

Les sorties restent celles du contrat commun :

resolved ;
unknown ;
ambiguous ;
conflict.

Une information manquante ne doit pas être comblée par une valeur « probable » uniquement pour augmenter le taux de résolution.

Reason codes¶

Exemples de codes cibles :

gpu.chipset.exact
gpu.vram.compatible
gpu.vram.conflict
gpu.board_model.ambiguous
gpu.generation.conflict

Ces codes sont illustratifs tant qu’ils ne sont pas confirmés dans le code.

Frontière avec le Core¶

Des concepts comme « deux valeurs explicitement incompatibles provoquent un conflit » peuvent être génériques.

En revanche, la sémantique de :

VRAM ;
nom de chipset ;
nomenclature NVIDIA / AMD / Intel ;
éditions OC ou variantes constructeur ;

doit rester locale tant qu’un besoin commun à plusieurs verticales n’est pas démontré.

Industrialisation¶

Cycle recommandé :

échantillon réel
    ↓
inventaire des références GPU
    ↓
normalisation locale
    ↓
audits read-only
    ↓
simulation
    ↓
revue des conflits / ambiguïtés
    ↓
validation
    ↓
activation ciblée éventuelle

Les KPI doivent distinguer les améliorations réelles des résolutions obtenues en affaiblissant abusivement les garde-fous.

Garde-fous¶

Ne jamais :

considérer le chipset seul comme identité complète d’une carte ;
fusionner deux variantes avec VRAM explicitement différente sans contrat métier ;
écrire directement depuis le module ;
déduire l’activation Runtime depuis la présence d’une feuille « cartes graphiques » dans la navigation ;
déplacer les nomenclatures GPU dans le Domain Core sans preuve de généricité.

État de transmission¶

Cette page est un guide TARGET. La première tâche d’un mainteneur souhaitant industrialiser GPU est de vérifier l’état réel du registre vertical et les règles déjà présentes dans pc_component, puis de choisir le bon niveau de spécialisation.