Apelo técnico de um desenvolvedor do Anukari à Apple

• O Anukari, simulador de áudio em tempo real com GPU, explica o problema de não conseguir garantir desempenho previsível em dispositivos macOS com Apple Silicon e pede uma conexão direta com a equipe do Apple Metal
• O Anukari é um sintetizador de áudio baseado em física que precisa integrar centenas de objetos na GPU a cada bloco de buffer de áudio e depende totalmente do desempenho de ALU da GPU
• Como a lógica automática de ajuste de energia/desempenho do macOS não reconhece bem essa carga de trabalho especial de áudio, o clock da GPU permanece baixo, causando queda de desempenho e interrupções no áudio
• Para resolver isso, foi introduzida a estratégia de "waste makes haste", com um spin kernel que engana a GPU gerando carga falsa, mas a chance de falha aumenta em Macs mais potentes a partir do M1
• Como solução, propõe-se introduzir reconhecimento em tempo real na fila de comandos da GPU ou estender o conceito de Audio Workgroup ao Metal, entre outras medidas

---

O que é o Anukari?

• Anukari é um sintetizador de áudio em tempo real baseado em física 3D que gera áudio calculando grandes modelos de massa-mola na GPU
• É usado em estações de trabalho de áudio (DAW) no formato AudioUnit/VST3 e solicita cálculos à GPU por unidade de buffer de áudio
• O processamento é focado em computação, não em memória (= ALU), e usa threadgroup memory da GPU para obter processamento rápido em nível de cache L1

A essência do problema de desempenho

• O macOS ajusta automaticamente o clock da GPU com foco em eficiência energética e reduz o clock quando detecta baixa carga de GPU
• Como o Anukari repete tarefas curtas, densas e em tempo real, o macOS não reconhece corretamente a carga da GPU
• Isso impede que se obtenha o desempenho necessário para atender às restrições de tempo real

Evidências e testes

• A diferença de clock entre estados de desempenho foi confirmada diretamente com o Metal Profiler do Apple Xcode
• No estado de Maximum performance, tudo funciona de forma suave, mas no estado Minimum ocorrem falhas e cortes no áudio

Estratégia "waste makes haste"

• Para forçar clocks mais altos na GPU, o Anukari executa em paralelo trabalhos de GPU para gerar carga com spin loop
• Essa estratégia funciona no M1, mas em chips Pro/Max ela pode falhar porque a carga se distribui por outros núcleos da GPU

Soluções propostas

1. Estender o Audio Workgroup até a GPU para que a carga seja reconhecida como workload de tempo real
2. Adicionar à API Metal um sinalizador de sensibilidade a tempo real
3. (Idealmente) Receber orientação caso já exista um método para isso

Outras alternativas analisadas e limitações

• O Game Mode é baseado no processo inteiro, então não pode ser aplicado ao Anukari em formato de plugin
• No Windows não há esse problema, possivelmente devido a uma gestão de clock mais flexível ou a maior controle de configuração
• A execução multi-kernel com hedge é inadequada por aumentar a latência de áudio e criar problemas de sincronização de estado
• A otimização do código de GPU já foi levada ao limite (uso de FP16, alinhamento de grupos SIMD, otimização de ALU etc.)

Por que GPU e não CPU?

• O Anukari executa cálculos físicos para 768~1024 objetos 48.000 vezes por segundo, com suporte a até 16 vozes de polifonia
• A CPU não consegue lidar com isso nem em volume de computação nem em paralelismo
• As capacidades da GPU em ALU, controle de cache L1 e controle paralelo com threadgroup_barrier são absolutamente necessárias

Por que a Apple deveria se importar com esse problema?

• O Anukari é um produto de nicho de uma pequena startup, mas tem uma base de usuários apaixonada e atrai o interesse de artistas renomados
• O Apple Silicon já tem desempenho suficiente para essa carga de trabalho, e bastaria mudar a política de ajuste de clock para resolver o problema

Por que uma GPU Audio API não é viável?

• O Anukari não é DSP tradicional, mas sim um integrador numérico de equações diferenciais, mais próximo de um motor de física de jogos, então não se encaixa no nível de abstração de GPU Audio
• Ele usa a API Metal diretamente, e otimização extrema específica do domínio é indispensável

Resumo do pedido: aguarda uma resposta de engenheiros da Apple para adicionar ao Metal API ou à política de ajuste de desempenho do macOS um mecanismo de reconhecimento de processamento em tempo real

[GN⁺]

Opiniões do Hacker News

• Olá pessoal, tive uma conversa muito produtiva com a pessoa certa da equipe Metal. Obrigado por ajudarem a chamar a atenção da Apple. Eu realmente não esperava receber tanto apoio

  • Alguns de vocês talvez tenham visto o post Show HN sobre o Anukari
  • Naquela thread, surgiu o assunto do desempenho no macOS. Basicamente, o Anukari funciona bem na maior parte do tempo em Apple Silicon, especialmente no hardware M1 básico. Fiz todos os meus testes em um M1 básico e ele funciona muito bem. O hardware é impressionante
  • Porém, para fazer isso funcionar, tive que implementar uma solução anormal para fazer o macOS aumentar a frequência do GPU, para que o processamento de áudio fosse rápido o suficiente. As heurísticas normais do macOS para estados de desempenho do GPU não entendem a carga de trabalho incomum do Anukari
  • De qualquer forma, tive tempo para documentar toda a situação em detalhes, para poder pedir ajuda para entrar em contato com a pessoa certa da Apple, provavelmente alguém que trabalhe na API Metal
  • Estou pedindo ajuda :)

• Tenho curiosidade sobre a origem do nome Anukari

• Tive experiência com duas empresas conhecidas que tinham aplicativos muito famosos na Apple App Store

  • A equipe da Apple com quem conversamos não tinha absolutamente nenhum interesse nos nossos problemas. Porém, frequentemente nos convidavam ao escritório para discutir os recursos mais novos que apresentariam na WWDC. O relacionamento com eles sempre começava e terminava assim. Tivemos que gastar tickets de suporte técnico só para obter alguma visão sobre por que o software com bugs deles não funcionava
  • As relações com desenvolvedores da Apple não são compostas por pessoas sérias

• O profiler do Metal tem um recurso muito útil: é possível selecionar o "estado de desempenho" do Metal enquanto se faz o profiling do aplicativo. Isso não pode ser configurado fora do profiler

  • Provavelmente existe uma API privada para isso. Talvez seja até mais fácil seguir pelo caminho da engenharia reversa. Se não exigir privilégios especiais

• O problema de expor uma API para isso é que desenvolvedores demais acabariam forçando sempre o estado máximo de desempenho. Não sei se existe uma boa forma de evitar isso e, ao mesmo tempo, manter a API

• A melhor forma de resolver esse problema:

  • Encontrar o engenheiro que mais entende do problema por meio dos vídeos da WWDC
  • Enviar um e-mail direto neste formato: [e-mail] (Michael Thomson)

• Não deixem passar o link jogado no penúltimo parágrafo. É um link para um demo feito por Mick Gordon. @anukarimusic responde a isso

  • Já no segundo dia ele destruiu completamente todos os demos que eu tinha feito, e tenho usado isso todos os dias desde então

• Além disso, o Anukari deveria lançar um pacote de sons do Mick Gordon e dividir a receita com ele. Esse cara está criando coisas incríveis. O demo dele é excelente. Quando se tem uma ferramenta poderosa, colaborar com artistas é um bom negócio e faz bem para o mundo. Se você gosta do Mick Gordon. Eu gosto

• Eu não preciso deste app, mas ele é muito legal. Apps assim trazem de volta a "diversão" para a computação. Não que hoje não haja diversão, mas isso me lembra os velhos tempos, quando havia mais programas gráficos e experimentais circulando por aí. Até mesmo a demoscene