OpenXR É o Esqueleto, Rádios de Link Duplo São o Nervo

Construa tudo você mesmo e você lança um ano atrasado falando uma língua que mais nada entende. A RakuAI toma o outro caminho: apoia-se no OpenXR onde ele se encaixa, e engenharia as partes difíceis - como um tether de rádio duplo que troca sozinho - onde os padrões ainda não chegaram.

A tentação quando você está construindo um motor para óculos de RA é construir tudo você mesmo. Construir sua própria API de pose. Construir seu próprio binding de gráficos. Construir seu próprio modelo de entrada. Construir suas próprias abstrações de controle. Cada uma dessas decisões são quarenta horas de trabalho de agente e mais quarenta horas de revisão humana. Isso se acumula em um ano de esforço e um motor que mais nada no ecossistema fala a língua.

Estou tomando o outro caminho. Onde um padrão existe que se encaixa no caso de uso, o motor adota o padrão. OpenXR é o exemplo mais destacado. Neste fim de semana o runtime cresceu a espinha dorsal OpenXR de que precisava há dois meses.

O que entrou em OpenXR

A maior parte do trabalho pesado entrou ao longo do fim de semana:

• Binding de API gráfica OpenXR com gerenciamento de sessão e swapchain
• Integração de ciclo de vida de frame OpenXR com tratamento de perda de dispositivo
• Sincronização de ação OpenXR e operações de localização de visão
• Suporte a extensões OpenXR para XR_FB_passthrough, XR_FB_foveation, e XR_EXT_hand_tracking
• Gerenciador de camadas de composição OpenXR e espaços de ação

Se você ler os títulos desses PRs um atrás do outro, eles soam como uma checklist de conformidade de fornecedor, que é o que são. O ponto é que qualquer dispositivo em qualquer parceiro de hardware que lance um runtime conformante com OpenXR agora é um alvo viável para a Raku, porque as partes do motor que conversam com o dispositivo falam o mesmo protocolo que o runtime do dispositivo fala.

Os agentes cuidaram da maior parte desse trabalho. Os PRs que entraram neste fim de semana são incomumente limpos porque OpenXR é um padrão bem especificado com um cabeçalho publicado e um conjunto de testes funcionando. O agente lê o cabeçalho, lê a seção da especificação, escreve a implementação, roda os testes de conformidade, e o PR fica ou verde ou vermelho sem muita ambiguidade. Esse é exatamente o tipo de trabalho em que agentes de codificação autônomos são melhores.

O gerenciador de link RF/óptico de modo duplo

A outra grande peça deste fim de semana é o gerenciador de link de modo duplo. Isso é uma coisa específica da Raku em vez de uma coisa de padrões.

O quadro: óculos de RA com um tether de computação externa. O tether às vezes é um celular, às vezes um beltpack, às vezes um desktop. O link entre os óculos e o tether é Wi-Fi 7 hoje e pode ser óptico de espaço livre amanhã em certos alvos de dispositivo. O runtime não pode assumir uma única tecnologia de link. Precisa ser capaz de trocar.

O gerenciador de link que entrou neste fim de semana lida com isso. O runtime abre tanto um link de RF quanto (onde suportado) um link óptico. Ele monitora latência e vazão em cada um. Ele move o tráfego para qualquer link que esteja performando melhor e recorre ao outro quando um degrada. A troca não é disruptiva para a aplicação acima.

Este é o tipo de subsistema que você realmente não consegue retrofitar. Se você esperar até a segunda tecnologia de link chegar para construir a abstração, você gasta três meses desfazendo as suposições que a primeira tecnologia de link infiltrou em cada camada acima dela. Nós construímos a abstração primeiro. Agora, qualquer tecnologia de link que um parceiro de hardware escolha, o runtime está pronto.

As extensões OpenXR e onde elas ficam aquém

Uma nota específica para pessoas de OpenXR lendo isso. As extensões XR_FB_passthrough e XR_FB_foveation para as quais adicionamos suporte neste fim de semana são as certas para a régua de qualidade de foveação e passthrough que queremos atingir, e a extensão de rastreamento de mãos XR_EXT_hand_tracking é a certa para a interface de rastreamento de mãos entre fornecedores.

O que falta no conjunto de extensões, e para o que estamos construindo código proprietário, é ancoragem sub-milimétrica (o caso de uso de caligrafia deste outono), sincronização de pose multiplayer de baixa latência nas escalas de tempo que queremos, e os ganchos de runtime de IA que permitem que a camada de modelo participe do raciocínio de cena a cada frame. Essas são áreas onde OpenXR ainda não padronizou, e nosso motor está lançando suas próprias interfaces enquanto isso. A intenção é que, quando o OpenXR alcançar (e há trabalho ativo no grupo de trabalho em algumas dessas frentes), adotemos o padrão e depreciemos o nosso próprio.

Esse é o padrão que quero que o motor mantenha. Adotar onde padrões existem. Construir onde não existem. Estar pronto para adotar onde eles alcançarem.

Telemetria e completude de stubs

Uma coisa mais silenciosa entrou neste fim de semana: logging JSON/OTLP estruturado com integração OpenTelemetry. Esse é o tipo de encanamento que não ganha o seu próprio anúncio, mas é o que nos permite responder a pergunta “para onde está indo o orçamento de latência” sem instrumentar o código à mão toda vez. O pipeline de telemetria agora está conectado a cada subsistema, e os painéis que a Fase 1 está produzindo são reais.

Também neste fim de semana: um PR de documentação que deu uma olhada dura nas implementações de stub na base de código e classificou cada uma como ou “de fato um utilitário de teste útil” ou “de fato um buraco.” As úteis foram renomeadas e documentadas. Os buracos foram rastreados. Os agentes escreveram e entregaram esse trabalho de classificação eles mesmos. É uma coisa pequena. Também é o tipo de coisa pequena que, negligenciada por tempo demais, vira uma bagunça séria.

O que eu quero que construtores e parceiros tirem disso

Se você é uma pessoa do grupo de trabalho de OpenXR, este motor está sendo construído como um bom cidadão do padrão. Adotamos extensões onde se encaixam. Registramos bugs de conformidade quando nossa implementação os encontra. Vamos publicar o que construímos onde os padrões ainda não alcançaram, e preferimos padronizar a manter um fork.

Se você é um parceiro de hardware cujo dispositivo é conformante com OpenXR, o motor está mais perto de rodar no seu dispositivo neste fim de semana do que estava no passado. O trabalho restante é cola específica de fornecedor. Ficamos felizes em fazer esse trabalho juntos.

Se você está trabalhando na próxima geração de tecnologia de link entre óculos e tether (Wi-Fi 7+, óptico de espaço livre, mmWave, qualquer coisa), a abstração do gerenciador de link é a camada para se conectar. O runtime acima não precisa saber qual rádio você é. O runtime abaixo te abstrai.

Noventa e oito commits ao longo do fim de semana. O motor cresceu uma espinha dorsal e um nervo. Fechar o laptop no domingo à noite depois de dois dias longos parece bom.