OpenXR ist das Skelett, Dual-Link-Funk ist der Nerv

Bauen Sie alles selbst, und Sie liefern ein Jahr zu spät aus, in einer Sprache, die sonst nichts versteht. RakuAI geht den anderen Weg: auf OpenXR stehen, wo es passt, und die harten Teile selbst konstruieren — wie eine sich selbst umschaltende Dual-Radio-Anbindung — wo die Standards noch nicht angekommen sind.

Die Versuchung beim Bau einer Engine für AR-Brillen ist, alles selbst zu bauen. Eine eigene Pose-API bauen. Ein eigenes Grafik-Binding bauen. Ein eigenes Eingabemodell bauen. Eigene Controller-Abstraktionen bauen. Jede dieser Entscheidungen sind vierzig Stunden Agentenarbeit und weitere vierzig Stunden menschliches Review. Es summiert sich zu einem Jahr Aufwand und einer Engine, deren Sprache sonst niemand im Ökosystem spricht.

Ich gehe den anderen Weg. Wo ein Standard existiert, der zum Anwendungsfall passt, übernimmt die Engine den Standard. OpenXR ist das Paradebeispiel. Dieses Wochenende wuchs der Runtime das OpenXR-Rückgrat, das sie seit zwei Monaten gebraucht hat.

Was bei OpenXR gelandet ist

Der Großteil der Schwerarbeit landete über das Wochenende verteilt:

• OpenXR-Grafik-API-Binding mit Session- und Swapchain-Verwaltung
• OpenXR-Frame-Lebenszyklus-Integration mit Device-Lost-Handling
• OpenXR-Action-Synchronisation und View-Location-Operationen
• OpenXR-Erweiterungsunterstützung für XR_FB_passthrough, XR_FB_foveation und XR_EXT_hand_tracking
• OpenXR-Composition-Layer-Manager und Action-Spaces

Wenn Sie diese PR-Titel hintereinander lesen, klingen sie wie eine Anbieter-Konformitäts-Checkliste, was sie auch sind. Der Punkt ist, dass jedes Gerät jedes Hardware-Partners, das eine OpenXR-konforme Runtime ausliefert, jetzt ein tragfähiges Ziel für Raku ist, weil die Teile der Engine, die mit dem Gerät sprechen, dasselbe Protokoll sprechen, das die Runtime des Geräts spricht.

Die Agenten haben den Großteil dieser Arbeit erledigt. Die PRs, die dieses Wochenende landeten, sind ungewöhnlich sauber, weil OpenXR ein gut spezifizierter Standard mit einem veröffentlichten Header und einer funktionierenden Testsuite ist. Der Agent liest den Header, liest den Spec-Abschnitt, schreibt die Implementierung, führt die Konformitätstests aus, und der PR ist entweder grün oder rot, ohne viel Mehrdeutigkeit. Das ist genau die Art von Arbeit, in der autonome Coding-Agenten am besten sind.

Der Dual-Mode-RF-/Optik-Link-Manager

Das andere große Stück dieses Wochenendes ist der Dual-Mode-Link-Manager. Das ist eher eine Raku-spezifische Sache als eine Standardsache.

Das Bild: AR-Brillen mit einer externen Recheneinheit als Anbindung. Die Anbindung ist manchmal ein Telefon, manchmal ein Beltpack, manchmal ein Desktop. Der Link zwischen Brille und Anbindung ist heute Wi-Fi 7 und könnte morgen auf bestimmten Gerätezielen freiraum-optisch sein. Die Runtime kann nicht eine Link-Technologie voraussetzen. Sie muss umschalten können.

Der Link-Manager, der dieses Wochenende landete, erledigt das. Die Runtime öffnet sowohl einen RF-Link als auch (wo unterstützt) einen optischen Link. Sie überwacht Latenz und Durchsatz auf beiden. Sie verlagert den Traffic auf den jeweils besser performenden Link und fällt auf den anderen zurück, wenn einer degradiert. Der Wechsel ist für die Anwendung darüber nicht störend.

Das ist die Art von Subsystem, die man nicht wirklich nachrüsten kann. Wenn man wartet, bis die zweite Link-Technologie eintrifft, um die Abstraktion zu bauen, verbringt man drei Monate damit, die Annahmen zu entwirren, die die erste Link-Technologie in jede Schicht darüber eingeschmuggelt hat. Wir haben die Abstraktion zuerst gebaut. Jetzt ist die Runtime bereit, egal welche Link-Technologie ein Hardware-Partner wählt.

OpenXR-Erweiterungen und wo sie nicht ausreichen

Eine spezifische Anmerkung für OpenXR-Leute, die das lesen. Die Erweiterungen XR_FB_passthrough und XR_FB_foveation, für die wir dieses Wochenende Unterstützung hinzugefügt haben, sind die richtigen für die Foveation- und Passthrough-Qualitätsmesslatte, die wir erreichen wollen, und die Hand-Tracking-Erweiterung XR_EXT_hand_tracking ist die richtige für die anbieterübergreifende Hand-Tracking-Schnittstelle.

Was im Erweiterungssatz fehlt, und wofür wir proprietären Code bauen, ist Submillimeter-Anchoring (der Kalligrafie-Anwendungsfall von früher in diesem Herbst), Low-Latency-Multiplayer-Pose-Sync in den Zeitskalen, die wir wollen, und die KI-Runtime-Hooks, die es der Modellschicht erlauben, an der Szenenschlussfolgerung in jedem Frame teilzunehmen. Das sind Bereiche, in denen OpenXR noch nicht standardisiert hat, und unsere Engine liefert in der Zwischenzeit eigene Schnittstellen aus. Die Absicht ist, dass wir, sobald OpenXR aufholt (und es gibt aktive Arbeit in der Working Group an einigen davon), den Standard übernehmen und unseren eigenen Weg auslaufen lassen.

Das ist das Muster, das ich die Engine beibehalten lassen möchte. Übernehmen, wo Standards existieren. Bauen, wo sie es nicht tun. Bereit sein zu übernehmen, wo sie aufholen.

Telemetrie und Stub-Vollständigkeit

Etwas Leiseres landete dieses Wochenende: strukturiertes JSON-/OTLP-Logging mit OpenTelemetry-Integration. Das ist die Art von Verrohrung, die keine eigene Ankündigung bekommt, aber es ist das, was uns erlaubt, die Frage „wo geht das Latenzbudget hin” zu beantworten, ohne den Code jedes Mal von Hand zu instrumentieren. Die Telemetrie-Pipeline ist jetzt durch jedes Subsystem verdrahtet, und die Dashboards, die Phase 1 produziert, sind real.

Ebenfalls dieses Wochenende: ein Dokumentations-PR, der einen genauen Blick auf die Stub-Implementierungen in der Codebasis warf und jede entweder als „tatsächlich ein nützliches Test-Utility” oder als „tatsächlich ein Loch” klassifizierte. Die nützlichen wurden umbenannt und dokumentiert. Die Löcher wurden erfasst. Die Agenten haben diese Klassifizierungsarbeit selbst geschrieben und gelandet. Es ist eine kleine Sache. Es ist auch die Art von kleiner Sache, die, zu lange vernachlässigt, zu einem ernsthaften Chaos wird.

Was ich Buildern und Partnern mitgeben möchte

Wenn Sie eine Person aus der OpenXR-Working-Group sind: Diese Engine wird als guter Bürger des Standards gebaut. Wir übernehmen Erweiterungen, wo sie passen. Wir melden Konformitätsfehler, wenn unsere Implementierung sie findet. Wir werden veröffentlichen, was wir gebaut haben, wo Standards noch nicht aufgeholt haben, und wir würden lieber standardisieren, als einen Fork zu pflegen.

Wenn Sie ein Hardware-Partner sind, dessen Gerät OpenXR-konform ist: Die Engine ist diesem Wochenende näher daran, auf Ihrem Gerät zu laufen, als letztes Wochenende. Die verbleibende Arbeit ist anbieterspezifische Klebeschicht. Wir arbeiten diese Arbeit gerne gemeinsam mit Ihnen ab.

Wenn Sie an der nächsten Generation von Link-Technologie zwischen Brille und Anbindung arbeiten (Wi-Fi 7+, freiraum-optisch, mmWave, was auch immer), ist die Link-Manager-Abstraktion die Schicht, an der Sie andocken sollten. Die Runtime darüber muss nicht wissen, welcher Funk Sie sind. Die Runtime darunter abstrahiert Sie.

Achtundneunzig Commits über das Wochenende. Die Engine ist um ein Rückgrat und einen Nerv gewachsen. Den Laptop Sonntagabend nach zwei langen Tagen zuzuklappen fühlt sich gut an.