El llamamiento técnico del desarrollador de Anukari a Apple

• Anukari, el simulador de audio en tiempo real sobre GPU, explica el problema de no poder garantizar un rendimiento predecible en dispositivos macOS con Apple Silicon y solicita una conexión directa con el equipo de Apple Metal
• Anukari es un sintetizador de audio basado en física que, en cada bloque de búfer de audio, debe integrar cientos de objetos en la GPU, por lo que depende por completo del rendimiento ALU de la GPU
• La lógica automática de ajuste de energía/rendimiento de macOS no reconoce bien esta carga de trabajo de audio tan particular, por lo que la frecuencia de la GPU se mantiene baja y provoca degradación del rendimiento y cortes de audio
• Para resolverlo, introdujo una spin kernel que engaña a la GPU provocando una carga falsa con la estrategia “waste makes haste”, pero es más probable que falle en Macs de alto rendimiento posteriores al M1
• Como solución, propone incorporar reconocimiento en tiempo real para la cola de comandos de la GPU o extender el concepto de Audio Workgroup hasta Metal, entre otras opciones

---

¿Qué es Anukari?

• Anukari es un sintetizador de audio 3D en tiempo real basado en física que genera audio calculando en la GPU modelos de resorte-masa a gran escala
• Se usa en estaciones de trabajo de audio (DAW) en formato AudioUnit/VST3, y solicita cálculos a la GPU por unidad de búfer de audio
• El cálculo está centrado más en cómputo que en memoria (=ALU) y aprovecha la threadgroup memory de la GPU para lograr procesamiento de alta velocidad a nivel de caché L1

La esencia del problema de rendimiento

• macOS ajusta automáticamente la frecuencia de la GPU con foco en eficiencia energética, y si detecta poca carga de GPU, reduce la frecuencia
• Como Anukari repite trabajos en tiempo real breves pero de alta densidad, macOS no reconoce correctamente la carga de la GPU
• Esto impide asegurar el rendimiento necesario para cumplir las restricciones de tiempo real

Evidencia y pruebas

• Mediante el Metal Profiler de Apple Xcode, se confirmó directamente la diferencia de frecuencia según el estado de rendimiento
• En el estado de Maximum performance funciona de forma fluida, pero en el estado Minimum se producen cortes de audio

Estrategia “waste makes haste”

• Para forzar una mayor frecuencia de la GPU, Anukari ejecuta al mismo tiempo una tarea de GPU para generar carga con un spin loop
• Esta estrategia funciona en el M1, pero en chips de clase Pro/Max es posible que falle porque la carga se distribuye a otros núcleos de la GPU

Soluciones propuestas

1. Extender Audio Workgroup hasta la GPU para que se reconozca como una carga de trabajo en tiempo real
2. Añadir a la API de Metal un flag de sensibilidad en tiempo real
3. (Idealmente) recibir orientación si ya existe un método para hacerlo

Revisión de otras alternativas y limitaciones

• Game Mode funciona a nivel de proceso completo, por lo que no puede aplicarse a Anukari en formato de plugin
• En Windows no hay problema, posiblemente por una gestión de frecuencia más flexible o por la posibilidad de controlarla mediante configuración
• La ejecución multi-kernel con hedging no es adecuada por el aumento de latencia de audio y los problemas de sincronización de estado
• La optimización del código GPU ya se llevó al límite (uso de FP16, alineación de grupos SIMD, optimización de ALU, etc.)

¿Por qué GPU y no CPU?

• Anukari realiza cálculos físicos sobre 768~1024 objetos 48,000 veces por segundo y admite hasta 16 voces de polifonía
• La CPU no puede soportarlo ni por volumen de cómputo ni por paralelismo
• Son absolutamente necesarias las capacidades de la GPU en ALU, control de caché L1 y control paralelo con threadgroup_barrier

¿Por qué debería importarle esto a Apple?

• Anukari es un producto de nicho de una startup pequeña, pero cuenta con una base de usuarios apasionada y el interés de artistas reconocidos
• Apple Silicon tiene potencia suficiente para procesar esta carga de trabajo, pero podría resolverse simplemente cambiando la política de ajuste de frecuencia

¿Por qué no sirve una GPU Audio API?

• Anukari no es DSP tradicional, sino un integrador numérico de ecuaciones diferenciales, es decir, algo más cercano a un motor de física para juegos, por lo que no encaja con el nivel de abstracción de GPU Audio
• Usa directamente la API de Metal y requiere optimizaciones extremas especializadas en el dominio

Resumen de la solicitud: se espera la respuesta de un ingeniero de Apple para añadir a la API de Metal o a la política de ajuste de rendimiento de macOS una función de reconocimiento para procesamiento en tiempo real

[GN⁺]

Opinión de Hacker News

• Hola a todos, tuve una conversación muy productiva con la persona adecuada del equipo de Metal. Gracias por ayudarme a llamar la atención de Apple. Para nada esperaba recibir tanto apoyo

  • Algunos quizá vieron la publicación de Show HN sobre Anukari
  • En ese hilo salió el tema del rendimiento en macOS. Básicamente, Anukari funciona bien en Apple Silicon, especialmente en el hardware base M1. Hice todas las pruebas en un M1 base y funcionó de maravilla. El hardware es impresionante
  • Sin embargo, para hacerlo funcionar tuve que implementar una solución poco normal para lograr que macOS subiera la velocidad de reloj de la GPU y así el procesamiento de audio fuera lo suficientemente rápido. Las heurísticas normales de macOS para los estados de rendimiento de la GPU no entienden la carga de trabajo tan particular de Anukari
  • En fin, tuve tiempo de documentar toda la situación en detalle para poder pedir ayuda para contactar a la persona adecuada de Apple, probablemente alguien que trabaje en la API de Metal
  • Pido ayuda :)

• Tengo curiosidad por el origen del nombre Anukari

• Tengo experiencia con dos empresas reconocidas que tienen apps muy famosas en la Apple App Store

  • Al equipo de Apple con el que hablábamos no le importaban en absoluto nuestros problemas. Pero a menudo nos invitaban a sus oficinas para hablar de las funciones más nuevas que presentarían en la WWDC. Nuestra relación con ellos siempre empezaba y terminaba así. Teníamos que gastar tickets de soporte técnico solo para obtener alguna pista de por qué su software con errores no funcionaba
  • Las relaciones con desarrolladores de Apple no son gente seria

• El profiler de Metal tiene una función muy útil: puedes seleccionar el "estado de rendimiento" de Metal mientras perfilas la aplicación. Esto no se puede configurar fuera del profiler

  • Probablemente haya una API privada para esto. Tal vez sea más fácil ir por la ruta de la ingeniería inversa. Si no requiere permisos especiales

• El problema de exponer una API para esto es que demasiados desarrolladores probablemente forzarían siempre el estado de máximo rendimiento. No sé si haya una buena forma de evitar eso y al mismo tiempo mantener la API

• La mejor forma de resolver este problema:

  • Encontrar al ingeniero que más conozca del tema a través de los videos de la WWDC
  • Enviarle un correo directamente con este formato: [e-mail] (Michael Thomson)

• No se pierdan el enlace que dejan en el penúltimo párrafo. Es un enlace a un demo hecho por Mick Gordon. @anukarimusic responde a eso

  • Para el segundo día ya había destruido por completo todos los demos que había hecho, y lo he estado usando todos los días

• Como extra, Anukari debería lanzar un sound pack de Mick Gordon y compartir ingresos con él. Ese tipo está creando cosas increíbles. Su demo es excelente. Cuando tienes una herramienta poderosa, colaborar con artistas es buen negocio y también es bueno para el mundo. Si te gusta Mick Gordon. A mí sí

• No necesito esta app, pero está realmente genial. Apps así le devuelven la "diversión" a la computación. No es que ahora no la tenga, pero me recuerda a épocas pasadas cuando había más programas gráficos y experimentales dando vueltas. Incluso la demoscene