OpenXR est le squelette, les radios à double liaison sont le nerf

Construisez tout vous-même et vous livrerez un an en retard en parlant un langage que rien d'autre ne comprend. RakuAI prend l'autre chemin : s'appuyer sur OpenXR là où ça convient, et concevoir les parties difficiles - comme un tether à double radio qui bascule tout seul - là où les standards ne sont pas encore arrivés.

La tentation quand vous construisez un moteur pour des lunettes AR est de tout construire vous-même. Construire votre propre API de pose. Construire votre propre liaison graphique. Construire votre propre modèle d’entrée. Construire vos propres abstractions de manette. Chacune de ces décisions représente quarante heures de travail d’agent et encore quarante heures de revue humaine. Cela s’additionne en une année d’effort et un moteur dont rien d’autre dans l’écosystème ne parle le langage.

Je prends l’autre chemin. Là où un standard existe qui convient au cas d’usage, le moteur adopte le standard. OpenXR est l’exemple phare. Ce week-end, le runtime a fait grandir l’ossature OpenXR dont il avait besoin depuis deux mois.

Ce qui a atterri sur OpenXR

L’essentiel du gros œuvre a atterri sur le week-end :

• Liaison API graphique OpenXR avec gestion de session et de swapchain
• Intégration du cycle de vie de frame OpenXR avec gestion de perte d’appareil
• Synchronisation d’action OpenXR et opérations de localisation de vue
• Support d’extension OpenXR pour XR_FB_passthrough, XR_FB_foveation, et XR_EXT_hand_tracking
• Gestionnaire de couches de composition OpenXR et espaces d’action

Si vous lisez ces titres de PR à la suite, ils sonnent comme une liste de contrôle de conformité fournisseur, ce qu’ils sont. Le point est que n’importe quel appareil chez n’importe quel partenaire matériel qui livre un runtime conforme OpenXR est maintenant une cible viable pour Raku, parce que les parties du moteur qui parlent à l’appareil parlent le même protocole que parle le runtime de l’appareil.

Les agents ont géré la majeure partie de ce travail. Les PR qui ont atterri ce week-end sont inhabituellement propres parce qu’OpenXR est un standard bien spécifié avec un en-tête publié et une suite de tests de conformité fonctionnelle. L’agent lit l’en-tête, lit la section de la spec, écrit l’implémentation, fait tourner les tests de conformité, et la PR est soit verte soit rouge sans grande ambiguïté. C’est exactement le genre de travail dans lequel les agents de codage autonomes excellent le plus.

Le gestionnaire de liaison RF / Optique à double mode

L’autre grosse pièce de ce week-end est le gestionnaire de liaison à double mode. C’est une chose spécifique à Raku plutôt qu’une chose de standards.

L’image : des lunettes AR avec un tether de calcul externe. Le tether est parfois un téléphone, parfois un beltpack, parfois un ordinateur de bureau. La liaison entre les lunettes et le tether est du Wi-Fi 7 aujourd’hui et pourrait être de l’optique en espace libre demain sur certaines cibles d’appareils. Le runtime ne peut pas supposer une seule technologie de liaison. Il doit pouvoir basculer.

Le gestionnaire de liaison qui a atterri ce week-end gère cela. Le runtime ouvre à la fois une liaison RF et (là où supportée) une liaison optique. Il surveille la latence et le débit sur chacune. Il déplace le trafic vers quelle que soit la liaison qui performe le mieux et se replie sur l’autre quand l’une se dégrade. Le basculement est non perturbateur pour l’application au-dessus.

C’est le genre de sous-système que vous ne pouvez pas vraiment rétro-adapter. Si vous attendez que la deuxième technologie de liaison arrive pour construire l’abstraction, vous passez trois mois à défaire les hypothèses que la première technologie de liaison a glissées dans chaque couche au-dessus d’elle. Nous avons construit l’abstraction en premier. Maintenant, quelle que soit la technologie de liaison qu’un partenaire matériel choisit, le runtime est prêt.

Les extensions OpenXR et là où elles font défaut

Une note spécifique pour les gens d’OpenXR qui lisent ceci. Les extensions XR_FB_passthrough et XR_FB_foveation pour lesquelles nous avons ajouté le support ce week-end sont les bonnes pour la barre de qualité de fovéation et de passthrough que nous voulons atteindre, et l’extension de suivi des mains XR_EXT_hand_tracking est la bonne pour l’interface de suivi des mains inter-fournisseurs.

Ce qui manque de l’ensemble d’extensions, et pour quoi nous construisons du code propriétaire, c’est l’ancrage sous-millimétrique (le cas d’usage de calligraphie de plus tôt cet automne), la synchro de pose multijoueur à faible latence aux échelles de temps que nous voulons, et les points d’ancrage de runtime IA qui permettent à la couche modèle de participer au raisonnement de scène à chaque frame. Ce sont des domaines où OpenXR n’a pas encore standardisé, et notre moteur livre ses propres interfaces en attendant. L’intention est que quand OpenXR rattrapera son retard (et il y a un travail actif dans le groupe de travail sur certains de ces sujets), nous adoptions le standard et abandonnions le nôtre.

C’est le schéma que je veux que le moteur maintienne. Adopter là où les standards existent. Construire là où ils n’existent pas. Être prêt à adopter là où ils rattrapent leur retard.

Télémétrie et complétude des stubs

Une chose plus discrète a atterri ce week-end : un logging JSON structuré / OTLP avec intégration OpenTelemetry. C’est le genre de plomberie qui n’obtient pas sa propre annonce, mais c’est ce qui nous permet de répondre à la question « où va le budget de latence » sans instrumenter le code à la main à chaque fois. Le pipeline de télémétrie est maintenant câblé à travers chaque sous-système, et les tableaux de bord que la Phase 1 produit sont réels.

Aussi ce week-end : une PR de documentation qui a jeté un regard dur sur les implémentations de stub dans la base de code et a classifié chacune comme soit « en fait un utilitaire de test utile » soit « en fait un trou ». Les utiles ont été renommées et documentées. Les trous ont été suivis. Les agents ont écrit et fait atterrir ce travail de classification eux-mêmes. C’est une petite chose. C’est aussi le genre de petite chose qui, négligée trop longtemps, se transforme en un vrai bazar.

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

Si vous êtes une personne du groupe de travail OpenXR, ce moteur est construit comme un bon citoyen du standard. Nous adoptons les extensions là où elles conviennent. Nous déposons des bugs de conformité quand notre implémentation en trouve. Nous publierons ce que nous avons construit là où les standards n’ont pas encore rattrapé leur retard, et nous préférerions standardiser que maintenir un fork.

Si vous êtes un partenaire matériel dont l’appareil est conforme OpenXR, le moteur est plus proche de tourner sur votre appareil ce week-end qu’il ne l’était le week-end dernier. Le travail restant est de la colle spécifique au fournisseur. Nous sommes heureux de faire ce travail ensemble.

Si vous travaillez sur la technologie de liaison de nouvelle génération entre les lunettes et le tether (Wi-Fi 7+, optique en espace libre, mmWave, n’importe quoi), l’abstraction de gestionnaire de liaison est la couche sur laquelle se brancher. Le runtime au-dessus n’a pas besoin de savoir quelle radio vous êtes. Le runtime en dessous vous abstrait.

Quatre-vingt-dix-huit commits sur le week-end. Le moteur a fait grandir une ossature et un nerf. Fermer l’ordinateur portable dimanche soir après deux longues journées fait du bien.