OpenXR es el esqueleto, las radios de enlace dual son el nervio

Constrúyelo todo tú mismo y lanzas con un año de retraso hablando un idioma que nada más entiende. RakuAI toma el otro camino: apóyate en OpenXR donde encaja, e ingenia las partes difíciles (como un enlace dual de radio que se autoconmuta) donde los estándares aún no han llegado.

La tentación cuando estás construyendo un motor para gafas de RA es construirlo todo tú mismo. Construir tu propia API de pose. Construir tu propio binding gráfico. Construir tu propio modelo de entrada. Construir tus propias abstracciones de controlador. Cada una de esas decisiones son cuarenta horas de trabajo de agente y otras cuarenta horas de revisión humana. Se acumula en un año de esfuerzo y un motor cuyo idioma no habla nada más en el ecosistema.

Yo estoy tomando el otro camino. Donde existe un estándar que encaja con el caso de uso, el motor adopta el estándar. OpenXR es el ejemplo principal. Este fin de semana el runtime desarrolló la columna vertebral de OpenXR que necesitaba desde hace dos meses.

Qué se completó en OpenXR

La mayor parte del trabajo pesado se completó a lo largo del fin de semana:

• Binding de API gráfica de OpenXR con gestión de sesión y swapchain
• Integración del ciclo de vida de fotogramas de OpenXR con manejo de pérdida de dispositivo
• Sincronización de acciones de OpenXR y operaciones de ubicación de vista
• Soporte de extensiones de OpenXR para XR_FB_passthrough, XR_FB_foveation y XR_EXT_hand_tracking
• Gestor de capas de composición de OpenXR y espacios de acción

Si lees esos títulos de PR uno tras otro suenan como una lista de verificación de conformidad de proveedor, que es lo que son. El punto es que cualquier dispositivo de cualquier socio de hardware que lance un runtime conforme con OpenXR ahora es un objetivo viable para Raku, porque las partes del motor que hablan con el dispositivo hablan el mismo protocolo que habla el runtime del dispositivo.

Los agentes manejaron la mayor parte de este trabajo. Los PRs que se completaron este fin de semana son inusualmente limpios porque OpenXR es un estándar bien especificado con un header publicado y un conjunto de pruebas de conformidad funcional. El agente lee el header, lee la sección de la especificación, escribe la implementación, corre las pruebas de conformidad, y el PR está en verde o en rojo sin mucha ambigüedad. Ese es exactamente el tipo de trabajo en el que los agentes de codificación autónomos son mejores.

El gestor de enlace dual RF/óptico

La otra gran pieza de este fin de semana es el gestor de enlace de doble modo. Esto es algo específico de Raku, no algo de estándares.

El panorama: gafas de RA con un enlace de cómputo externo. El enlace es a veces un teléfono, a veces un beltpack, a veces un escritorio. El enlace entre las gafas y el cómputo externo es Wi-Fi 7 hoy y podría ser óptico de espacio libre mañana en ciertos dispositivos objetivo. El runtime no puede asumir una sola tecnología de enlace. Tiene que poder cambiar.

El gestor de enlace que se completó este fin de semana se encarga de eso. El runtime abre tanto un enlace RF como (donde se soporte) un enlace óptico. Monitorea la latencia y el rendimiento de cada uno. Mueve el tráfico a cualquiera de los enlaces que esté funcionando mejor y recurre al otro cuando uno se degrada. El cambio no es disruptivo para la aplicación de arriba.

Este es el tipo de subsistema que realmente no puedes adaptar después. Si esperas hasta que llegue la segunda tecnología de enlace para construir la abstracción, pasas tres meses deshaciendo las suposiciones que la primera tecnología de enlace coló en cada capa superior. Construimos la abstracción primero. Ahora, elija el socio de hardware la tecnología de enlace que elija, el runtime está listo.

Las extensiones de OpenXR y dónde se quedan cortas

Una nota específica para la gente de OpenXR que lea esto. Las extensiones XR_FB_passthrough y XR_FB_foveation para las que añadimos soporte este fin de semana son las correctas para el nivel de calidad de foveación y passthrough que queremos alcanzar, y la extensión de seguimiento de manos XR_EXT_hand_tracking es la correcta para la interfaz de seguimiento de manos multi-proveedor.

Lo que falta en el conjunto de extensiones, y para lo que estamos construyendo código propietario, es el anclaje submilimétrico (el caso de uso de caligrafía de principios de este otoño), la sincronización de pose de baja latencia en RA multijugador a las escalas de tiempo que queremos, y los enganches de runtime de IA que permiten que la capa del modelo participe en el razonamiento de escena en cada fotograma. Estas son áreas donde OpenXR todavía no se ha estandarizado, y nuestro motor está lanzando sus propias interfaces mientras tanto. La intención es que, cuando OpenXR se ponga al día (y hay trabajo activo en el grupo de trabajo en algunas de estas), adoptemos el estándar y depreciemos el nuestro.

Ese es el patrón que quiero que mantenga el motor. Adoptar donde existen estándares. Construir donde no existen. Estar listos para adoptar donde se pongan al día.

Telemetría y completitud de stubs

Algo más discreto se completó este fin de semana: registro estructurado en JSON/OTLP con integración de OpenTelemetry. Este es el tipo de plomería que no obtiene su propio anuncio, pero es lo que nos permite responder a la pregunta “a dónde se va el presupuesto de latencia” sin instrumentar el código a mano cada vez. El pipeline de telemetría ahora está conectado a través de cada subsistema, y los paneles que está produciendo la Fase 1 son reales.

También este fin de semana: un PR de documentación que hizo un análisis serio de las implementaciones de stub en el código y clasificó cada una como “en realidad una utilidad de prueba útil” o “en realidad un agujero.” Las útiles se renombraron y documentaron. Los agujeros se rastrearon. Los agentes escribieron y completaron ese trabajo de clasificación por sí mismos. Es una cosa pequeña. También es el tipo de cosa pequeña que, descuidada durante demasiado tiempo, se convierte en un lío serio.

Lo que quiero que los constructores y socios se lleven de esto

Si eres una persona del grupo de trabajo de OpenXR, este motor se está construyendo como un buen ciudadano del estándar. Adoptamos extensiones donde encajan. Reportamos errores de conformidad cuando nuestra implementación los encuentra. Publicaremos lo que hemos construido donde los estándares aún no se han puesto al día, y preferiríamos estandarizar antes que mantener una bifurcación.

Si eres un socio de hardware cuyo dispositivo es conforme con OpenXR, el motor está más cerca de correr en tu dispositivo este fin de semana de lo que estaba el fin de semana pasado. El trabajo restante es pegamento específico de proveedor. Estamos encantados de hacer ese trabajo juntos.

Si estás trabajando en la próxima generación de tecnología de enlace entre gafas y cómputo externo (Wi-Fi 7+, óptico de espacio libre, mmWave, lo que sea), la abstracción del gestor de enlace es la capa en la que conectarse. El runtime de arriba no necesita saber qué radio eres tú. El runtime de abajo te abstrae.

Noventa y ocho commits a lo largo del fin de semana. El motor desarrolló una columna vertebral y un nervio. Cerrar el portátil el domingo por la noche después de dos días largos se siente bien.