Architecture du portage OptiX 4 vers 9
La frontière d'API traversée
OptiX 7 (2019) a refondu l'API de fond en comble. Le code Radience d'origine, écrit pour OptiX 4.0.2 (2017), utilise le wrapper C++ optix::Context — un modèle objet où les variables, les buffers et les programmes sont déclarés dynamiquement par nom. OptiX 7+ remplace tout cela par une API C explicite à six concepts :
| Concept OptiX 7+ | Rôle | Équivalent OptiX 4 |
|---|---|---|
OptixDeviceContext | wrapper léger sur un contexte CUDA | optix::Context (partiel) |
OptixModule | unité de compilation (PTX / OptiX-IR) | optix::Program (partiel) |
OptixProgramGroup | regroupe raygen / miss / hitgroup | déclaration par nom |
OptixPipeline | lie les program groups + tunables | Context->compile() |
OptixShaderBindingTable | buffer device liant (instance, ray) au program | implicite |
| Acceleration Structure | BLAS / TLAS explicites | optix::Geometry + Acceleration |
Le saut 4 vers 9 traverse cette frontière sans pouvoir être incrémental. C'est un portage architectural, pas une modernisation de version.
Architecture hexagonale retenue
Le code porté n'est pas un monolithe CUDA. Il suit une architecture hexagonale : un cœur de logique métier (l'orchestration Monte Carlo) indépendant de toute technologie GPU, et des adapters concrets qui implémentent un port unique.
radience-mc-core — orchestration, accumulateurs, bilan d'énergie (zéro dépendance GPU)
radience-mc-ports — le contrat MonteCarloRunnerPort (prepare / launch / backend_descriptor)
radience-mc-adapters — les implémentations concrètes du port :
├─ noop/ — backend synthétique CPU (dev + CI sans GPU)
├─ optix9/ — backend NVIDIA CUDA + OptiX 9
└─ mlx/ — backend Apple Silicon MLX (cross-validateur — cf. § 03)
radience-mc-validation — instruments de tests L0–L4
radience-mc-cli — orchestration, dispatch backend, écriture des sorties
Le bénéfice direct pour Radience : le cœur scientifique ne dépend d'aucun fournisseur GPU. Changer de backend (OptiX 9, MLX, un futur Vulkan) est un changement d'adapter, pas une réécriture. Le contrat MonteCarloRunnerPort garantit que les mêmes entrées produisent les mêmes sorties quel que soit le backend — c'est cette propriété qui rend la cross-validation possible (§ 03).
Le shim C++ minimal
OptiX 9 reste une bibliothèque C/C++. Plutôt que de réécrire les liaisons FFI à la main pour toute la surface OptiX, le portage retient un shim C++ mince (shim/) — un wrapper statique qui expose les opérations OptiX nécessaires (contexte, module, pipeline, SBT, launch) derrière une interface extern "C" stable. Les liaisons Rust (optix-sys) sont générées par bindgen à partir des en-têtes OptiX 9.1, avec une allowlist de symboles auditée (cf. ADR-02).
Décision documentée : le binaire TeXmacs et les wrappers OptiX tiers immatures ont été écartés ; le shim hand-rollé garde la surface FFI minimale et auditable.
État du portage OptiX 9 au 2026-05-14
Honnêteté carnot — voici ce qui est fait et ce qui reste :
| Étape | État |
|---|---|
| Workspace Cargo + 5 crates + shim CMake | ✅ construit |
Bindings optix-sys (bindgen + stubs optix_stubs.h) | ✅ compile + link |
| Port host C++ 438 LOC vers Rust + RAII wrappers | ✅ merged |
| Port des 3 kernels CUDA pre-OptiX-7 réécrits en post-7 (SBT layout) | ✅ vers 3 .optixir produits |
| 4 anomalies du code original préservées verbatim | ✅ gate G_anomalies_preserved |
| Program groups + LaunchParams + BLAS wirés | ✅ task d'intégration |
optixInit + optixDeviceContextCreate + optixModuleCreate | ✅ validés sur GPU L4 réel |
Smoke test L0 backend optix9 complet (PNG produit) | ⏳ bloqué — voir § 05 |
Le blocage du smoke test final n'est pas un blocage de code : c'est une pénurie de capacité GPU L4 chez le fournisseur cloud (détaillée § 05). Le chemin de code est complet jusqu'à optixLaunch.