Le week-end où le moteur a grandi

Il y a un moment où une base de code cesse d'être quelque chose que vous construisez et devient quelque chose sur lequel d'autres peuvent construire. Pour RakuAI, ce moment a été un week-end à 276 commits entre Noël et le Nouvel An.

Il y a des week-ends où une base de code avance, et il y a des week-ends où une base de code change de catégorie. Le week-end entre Noël et le Nouvel An a été du second type.

Deux cent soixante-seize commits ont atterri à travers les dépôts. Le runtime a fait grandir le genre de surface qui transforme un projet de recherche en plateforme. Ancres spatiales. Composition OpenXR. Inférence de petit modèle de langage sur l’appareil. Synchro fédérée avec de la vraie crypto. Abstraction matérielle pour le canal de communications optiques. La majeure partie a atterri en PR parallèles écrites par des agents, revues et fusionnées à travers le flux de travail multi-fournisseurs qui tourne depuis deux mois.

Samedi matin, je me suis assis avec un café et une file pleine de TODO à haute priorité. Dimanche soir, j’ai fermé l’ordinateur portable sur un moteur différent de celui que j’avais ouvert samedi. Voici le billet sur ce qui a été livré, ce que cela signifie, et pourquoi je pense que 2026 est l’année où d’autres personnes commencent à prendre ce moteur au sérieux.

Les grands atterrissages

API C TensorFlow Lite pour l’inférence SLM. C’est celui pour lequel je suis le plus enthousiaste. Le runtime peut maintenant charger de petits modèles de langage au format TFLite et exécuter l’inférence contre eux comme une opération runtime de premier ordre. La motivation est simple : tous les modèles n’ont pas besoin d’un aller-retour cloud. Certains des comportements IA qui pilotent une expérience AR sont serrés, focalisés, et assez petits pour tourner sur l’appareil. Le chemin TFLite nous donne cela. Le chemin LLM cloud à travers le XRAssistantService nous donne l’autre bout. Le moteur couvre maintenant les deux.

Ancres spatiales complètes (Epic #555). Cycle de vie complet des ancres spatiales : créer, persister, partager entre appareils, restaurer dans une session différente, expirer. La couche de persistance est adossée au cloud à travers libcurl HTTP, avec la couche de chiffrement (AES-256-GCM, dérivation de clé PBKDF2) atterrissant le même week-end. Les ancres sont maintenant des objets runtime de premier ordre. Une expérience AR qui a besoin de poser un objet virtuel sur le même comptoir de cuisine aujourd’hui, demain, et dans un mois, à travers deux paires de lunettes différentes possédées par deux personnes différentes, fonctionne.

Stabilisation de pose d’ancre par filtre de Kalman. Une petite chose qui compte beaucoup. Les poses d’ancre sans filtrage tremblent juste assez pour paraître fausses. Les poses d’ancre avec filtrage par prédiction d’état de Kalman paraissent solides. Le runtime applique maintenant le filtre automatiquement ; les applications au-dessus n’ont pas besoin de le savoir.

Gestionnaire de couches de composition OpenXR et espaces d’action. Poursuite du travail sur l’ossature OpenXR de novembre. Le gestionnaire de couches de composition est ce qui permet à une seule frame de combiner le passthrough caméra, le contenu virtuel de l’utilisateur, et toute superposition système dans le bon ordre avec les bons modes de fondu. Fondamental et facile à sous-estimer.

Chiffrement AES-256-GCM de production et découverte de pairs UDP pour les ancres partagées. C’est ce qui rend « partager une ancre avec un ami qui est dans la même pièce » réellement sûr à livrer. Le protocole d’ancre partagée utilise un chiffrement authentifié de bout en bout. La découverte de pairs se fait via UDP localement sans passer par un aller-retour cloud. L’histoire de confidentialité et de latence pour l’AR partagée est réelle.

Couche d’abstraction matérielle pour le canal optique (33 TODO de capteurs résolus). La liaison optique, quand présente sur un appareil, est maintenant un pair de la liaison RF. Les deux sont abstraites derrière le même gestionnaire de liaison à double mode qui a atterri en novembre. Le runtime au-dessus ne se soucie pas de quelle radio est sur le fil.

Synchro fédérée câblée jusqu’à de la vraie crypto. Le sous-système de synchro fédérée était piloté par des stubs pendant la majeure partie de l’automne. Ce week-end, il a fait grandir de vraies implémentations : transport HTTP, enveloppe JSON, vérification de signature crypto. Les mises à jour de modèles IA/ML peuvent maintenant être distribuées aux appareils à travers le chemin fédéré en toute sécurité.

Intégration de SDK oculaire fournisseur et vérification de token. Une poignée de SDK de suivi oculaire spécifiques à des fournisseurs sont maintenant câblés derrière l’interface fournisseur OpenXR, avec une authentification par token appropriée pour la couche de licence du fournisseur.

Instrumentation de profilage GPU à travers le moteur de rendu (15 TODO résolus). Le timing GPU par passage, les budgets mémoire, et la détection de blocage de pipeline sont maintenant en direct. Si une frame traîne, nous pouvons voir exactement quel passage a coûté le budget.

Fonctionnalité de mise à jour du runtime (10 TODO résolus). Le runtime peut se mettre à jour lui-même sur le terrain maintenant. Versionné, signé, avec retour arrière. C’est le genre de plomberie que personne ne remarque jusqu’à en avoir besoin, moment auquel c’est la différence entre une plateforme et un projet artistique.

Ce que j’ai appris de ce rythme

Deux cent soixante-seize commits sur un long week-end férié est un rythme qui ne fonctionne pas dans un flux de travail de développement traditionnel. Il fonctionne dans celui-ci parce que le flux de travail est construit autour d’agents qui livrent en parallèle contre une file que je garde remplie. Quelques observations sur le fait de tourner à ce rythme pendant la période de Noël au Nouvel An :

La structure Epic a gagné sa place. Vers le milieu du mois, j’ai basculé le suivi d’issues vers un schéma d’Epic-de-sous-issues (Epic #506 pour le Runtime Core Phase 1, Epic #555 pour les Ancres Spatiales, Epic #508 pour les Extensions OpenXR). Chaque Epic obtient une PR qui ferme un corps de travail cohérent. Les agents implémentent les sous-issues en parallèle, mais la fusion se produit comme une seule PR atomique au niveau Epic. Cela a donné à la base de code un historique beaucoup plus propre et a rendu la revue traitable.

Le système de suivi des TODO a été le bon mouvement. Plus tôt dans le mois, j’ai ajouté un système automatisé qui scanne la base de code pour les commentaires TODO et crée des issues GitHub pour chacun, avec priorisation. Au moment où le sprint de Noël a commencé, il y avait 342 TODO runtime suivis. Les agents ont pris les plus prioritaires en premier. Nous en avons fermé environ 150 ce week-end. La base de code est significativement plus propre qu’elle ne l’était au début décembre.

Le timing de fusion inter-dépôts compte. Le runtime et le SDK ont dû faire atterrir leurs changements à quelques heures l’un de l’autre pour plusieurs Epic ce week-end. Quand le runtime publie une nouvelle API C, le SDK doit mettre à jour ses liaisons le même jour. J’ai retenu quelques PR SDK et fusionné quelques PR runtime dans la même heure pour garder l’intégration honnête.

Les agents s’améliorent dans leurs rôles. Les PR qui atterrissent ce week-end sont sensiblement plus propres que les PR qui atterrissaient en septembre. Une partie de cela est la base de code devenant plus mature. Une partie est le flux de travail devenant plus discipliné. Une partie est les modèles eux-mêmes devenant meilleurs dans le type de travail que produit cette base de code. Les trois sont réels.

Où en est le moteur, en entrant dans 2026

La version liste de contrôle :

• Pivot AR1+ vers AR2 Gen1 : fait
• Ossature OpenXR : faite
• Intégration d’intention LLM cloud à travers le XRAssistantService : faite
• Inférence SLM sur l’appareil à travers TFLite : faite
• Ancrage sous-millimétrique pour les superpositions haute précision : fait
• Ancres spatiales avec persistance, partage, et crypto appropriée : faites
• Pipeline de rendu déporté Wi-Fi 7 : fait
• Gestionnaire de liaison RF / optique à double mode : fait
• Suivi oculaire, suivi des mains, suivi du corps entier : faits
• Rendu fovéal avec optimisation multi-profils : fait
• Abstraction matérielle pour les capteurs et le canal optique : faite
• Synchro fédérée pour la distribution de modèles et de contenu : faite
• Mise à jour du runtime avec versionnage et retour arrière : faite
• Builds multiplateformes (Linux, macOS, Windows MSVC 2026) : faits
• Pipeline de télémétrie et OpenTelemetry : fait
• 342 TODO suivis, ~150 fermés ce mois-ci : en cours, mais ça s’assemble

Ce qui n’est pas fait : les sous-systèmes IA qui lient la couche modèle à l’étape de simulation. Arbres de comportement. Maillages de navigation. Simulation de foule. Systèmes sensoriels. Arbres de décision. C’est le travail que je m’attends à voir atterrir la première semaine de janvier. Le runtime est prêt à les recevoir. Aujourd’hui le moteur a les os. Le week-end prochain il obtient les nerfs.

Ce que je veux que les partenaires, bâtisseurs et laboratoires retiennent de ceci

Si vous êtes un partenaire matériel qui évalue si ce moteur peut se déployer sur votre appareil en 2026, la réponse est oui, et le travail pour rendre cela réel est surtout de la colle spécifique au fournisseur à ce stade. Le moteur lui-même est prêt.

Si vous êtes un laboratoire IA qui réfléchit à où le budget d’inférence de votre modèle pourrait être le mieux dépensé dans un runtime AR, le chemin TFLite sur l’appareil et le chemin XRAssistantService LLM cloud sont tous deux de qualité production maintenant. Si votre modèle rentre dans le budget sur l’appareil, il peut tourner sur l’étape de simulation. Sinon, le chemin cloud est ouvert. Dans les deux cas, l’intégration est agnostique au modèle, et je veux que votre modèle soit le meilleur modèle derrière elle.

Si vous êtes un développeur qui réfléchit à construire par-dessus ce moteur en 2026, la surface est réelle. L’API C est stable. Les liaisons SDK (Unity et Unreal) sont réelles. L’ossature OpenXR signifie que le moteur cible plusieurs appareils. Le blog à cette URL a été un journal public de comment le moteur en est arrivé là. Relisez-le si vous voulez savoir quelle sera la culture d’ingénierie quand vous apporterez une expérience à cette plateforme.

276 commits, une année qui se termine, un moteur qui a grandi. Week-end différent, même flux de travail. Retour à la construction samedi prochain.