OpenXRが骨格、デュアルリンク無線が神経

すべてを自分で構築すれば、他の誰も理解しない言語を話す製品を1年遅れで出荷することになる。RakuAIは別の道を取る。OpenXRが合う場所ではその上に立ち、標準規格がまだ届いていない部分 — 自ら切り替わるデュアル無線テザーのような — では難しい部分を自分でエンジニアリングする。

ARグラス向けのエンジンを構築しているとき、すべてを自分で作りたくなる誘惑がある。自分のポーズAPIを作る。自分のグラフィックスバインディングを作る。自分の入力モデルを作る。自分のコントローラー抽象化を作る。それぞれの決定は40時間分のエージェント作業と、さらに40時間分の人間によるレビューだ。それが積み重なって1年分の労力になり、エコシステムの他の何もその言語を話さないエンジンが出来上がる。

私は別の道を取っている。ユースケースに合う標準規格が存在するところでは、このエンジンはその標準規格を採用する。OpenXRがその代表例だ。この週末、ランタイムは2か月間ずっと必要としていたOpenXRの背骨を育てた。

OpenXRで何が着地したか

重い作業のほとんどが週末を通して着地した。

• セッションとスワップチェーン管理を備えたOpenXRグラフィックスAPIバインディング
• デバイスロストのハンドリングを備えたOpenXRフレームライフサイクル統合
• OpenXRのアクション同期とビューロケーション操作
• XR_FB_passthrough、XR_FB_foveation、XR_EXT_hand_trackingに対するOpenXR拡張機能サポート
• OpenXRコンポジションレイヤーマネージャーとアクションスペース

これらのPRタイトルを続けて読むと、ベンダー準拠のチェックリストのように聞こえる。実際そうだからだ。要点は、OpenXR準拠のランタイムを出荷しているハードウェアパートナーのデバイスなら何であれ、今やRakuにとって実現可能なターゲットになるということだ。なぜなら、デバイスと話すエンジンの部分が、デバイスのランタイムが話すのと同じプロトコルを話すからだ。

この作業のほとんどはエージェントが処理した。この週末に着地したPRは異例なほどきれいだ。なぜならOpenXRは、公開されたヘッダーと動作するテストスイートを備えた、よく仕様化された標準規格だからだ。エージェントはヘッダーを読み、仕様のセクションを読み、実装を書き、準拠テストを実行する。そしてPRはあまりあいまいさなくグリーンかレッドかのどちらかになる。それはまさに自律コーディングエージェントが最も得意とする種類の作業だ。

デュアルモードRF／光リンクマネージャー

この週末のもう一つの大きな部分は、デュアルモードのリンクマネージャーだ。これは標準規格の話というより、Raku固有の話だ。

その様子はこうだ。外部コンピュートテザーを備えたARグラス。テザーは時にスマートフォンであり、時にベルトパックであり、時にデスクトップだ。グラスとテザーの間のリンクは、今日はWi-Fi 7だが、特定のデバイスターゲットでは明日、自由空間光通信になるかもしれない。ランタイムは1つのリンク技術を前提にできない。切り替えられなければならない。

この週末に着地したリンクマネージャーがそれを処理する。ランタイムはRFリンクと(対応していれば)光リンクの両方を開く。それぞれのレイテンシとスループットを監視する。より良い性能を出しているほうのリンクにトラフィックを移し、片方が劣化したときはもう片方にフォールバックする。その切り替えは上位のアプリケーションにとって非破壊的だ。

これは本当には後付けできない種類のサブシステムだ。もし2番目のリンク技術が到着するまで抽象化の構築を待てば、最初のリンク技術がその上のあらゆるレイヤーに忍び込ませた前提を解きほぐすのに3か月を費やすことになる。私たちは抽象化を先に構築した。今や、ハードウェアパートナーがどちらのリンク技術を選ぼうと、ランタイムの準備はできている。

OpenXRの拡張機能とその限界

これを読んでいるOpenXR関係者向けの具体的なメモだ。この週末にサポートを追加したXR_FB_passthroughとXR_FB_foveationの拡張機能は、私たちが達成したいフォービエイテッドレンダリングとパススルーの品質基準にとって正しいものであり、ハンドトラッキングの拡張機能XR_EXT_hand_trackingは、ベンダー横断のハンドトラッキングインターフェースにとって正しいものだ。

拡張機能セットに欠けているもの、そして私たちが独自のコードを構築しているものは、サブミリメートルのアンカリング(この秋初めの書道のユースケース)、私たちが望む時間スケールでの低レイテンシのマルチプレイヤーポーズ同期、そしてモデルレイヤーが毎フレームのシーン推論に参加できるようにするAIランタイムのフックだ。これらはOpenXRがまだ標準化していない領域であり、私たちのエンジンはその間、独自のインターフェースを出荷している。意図としては、OpenXRが追いついてきたとき(そしてワーキンググループではこれらの一部について活発な作業が行われている)、標準規格を採用し、独自のものを非推奨にすることだ。

それが、このエンジンに維持し続けてほしいパターンだ。標準規格が存在するところでは採用する。存在しないところでは構築する。追いついてきたところでは採用する準備をしておく。

テレメトリとスタブの完全性

この週末にはもう一つ、より静かなことが着地した。OpenTelemetry統合を伴う構造化されたJSON / OTLPロギングだ。これは、それ自体の発表を得ることのない種類の配管作業だが、毎回手作業でコードに計測を入れることなく「レイテンシ予算がどこに消えているか」という問いに答えられるようにするものだ。テレメトリパイプラインは今やすべてのサブシステムに配線されており、フェーズ1が生み出しているダッシュボードは本物だ。

同じくこの週末、コードベース内のスタブ実装を厳しく見直し、それぞれを「実際に有用なテストユーティリティ」か「実際には穴」のどちらかに分類するドキュメントPRがあった。有用なものはリネームされ、文書化された。穴は追跡された。エージェントはその分類作業を自分で書き、着地させた。小さなことだ。だが、あまりに長く放置すれば深刻な混乱に変わる種類の小さなことでもある。

ビルダーとパートナーにこれから読み取ってほしいこと

もしあなたがOpenXRのワーキンググループの人なら、このエンジンはその標準規格の良き一員として構築されている。私たちは合う拡張機能を採用する。実装で準拠バグを見つけたときは報告する。標準規格がまだ追いついていないところで私たちが構築したものは公開するつもりであり、フォークを保守するよりも標準化するほうを望んでいる。

もしあなたが、自社のデバイスがOpenXR準拠であるハードウェアパートナーなら、このエンジンは先週末よりもこの週末のほうが、あなたのデバイス上で動くことに近づいている。残る作業はベンダー固有のグルーコードだ。私たちはその作業を一緒にやることを喜んで引き受ける。

もしあなたが、グラスとテザーの間の次世代リンク技術(Wi-Fi 7以降、自由空間光通信、mmWave、何であれ)に取り組んでいるなら、リンクマネージャーの抽象化が接続すべきレイヤーだ。上位のランタイムは、あなたがどの無線であるかを知る必要がない。下位のランタイムがあなたを抽象化する。

週末を通して98コミット。エンジンは背骨と神経を育てた。長い2日間の後、日曜の夜にラップトップを閉じるのは気分が良い。