Compatibilidad con Vulkan 1.3 en el M1 en solo un mes

• Honeykrisp todavía no ha sido lanzado para usuarios finales; por ahora solo se ha publicado el source code para desarrolladores
• Honeykrisp para M1 es la primera implementación de conformant Vulkan en hardware de Apple, e implementa toda la especificación de Vulkan 1.3 sin waiver de portability
• Honeykrisp no parte del trabajo previo de Vulkan para M1, sino que se basa en el driver NVK de código abierto para GPU de NVIDIA, comenzando por añadir código para M1 y eliminar las partes relacionadas con NVIDIA
• El resultado final de la conformance test suite de Vulkan 1.3 quedó registrado como Pass 686930, Fail 0
• Todo el estado se maneja como estado dinámico, y se añadió código para construir, compilar y cachear prolog y epilog, avanzando hacia full dynamic state y EXT_shader_object
• Se implementó EXT_image_drm_format_modifier para permitir zero-copy rendering
• Para compatibilidad con Direct3D, se soporta EXT_custom_border_color, requerido por DXVK y vkd3d-proton; la corrección del border colour se emula inyectando código en el shader
• La emulación de custom border colour se describe como “simple, correct, and slow”, y más adelante se planea mejorar su velocidad con trucos del driver
• El siguiente trabajo será implementar lo que DXVK y vkd3d-proton requieren para la capa de Direct3D; un ejemplo mencionado es transform feedback

[GN⁺]

Opiniones en Hacker News

• Es un trabajo realmente impresionante y muestra muy bien el valor de los componentes abiertos que se comparten y mejoran iterativamente.
  Me pregunto cuánto tardará en portarse Proton, pero aunque la implementación de Vulkan sea óptima, creo que muchos juegos tendrán mal rendimiento por las diferencias en la arquitectura de GPU, la sobrecarga de la traducción a ARM y el costo propio de Proton.
  Aun así, soy optimista: si SoC como Snapdragon se vuelven más comunes en equipos de escritorio, en adelante más juegos apuntarán a memoria unificada y ARM.

  • Sería bastante irónico que la experiencia de juego en Asahi terminara siendo más fácil y simple que en macOS.
    Muestra lo grande que fue el error de Apple al ignorar Vulkan durante la última década, aunque probablemente nunca lo admitan hasta que sea demasiado tarde.
  • Una buena cantidad de juegos que no necesitan dxvk corren a más de 60 FPS. Ver https://vt.social/@lina/112524118075585601
    Alyssa también está trabajando recientemente en mejoras de rendimiento para FEX.

• Me pregunto si este trabajo de agregar Vulkan a Linux y traducir DirectX en Asahi Linux afectará el sueño de Apple de atraer juegos AAA a Apple Silicon.
  Apple querrá que los estudios AAA porten sus juegos a Metal para que corran con una sola base de código en iPhone, iPad, Mac y Vision Pro.
  Tal vez los gamers de Mac terminen instalando Asahi Linux para jugar títulos AAA de PC.

  • El sueño de Apple no es que los juegos AAA lleguen a Apple Silicon, sino que lleguen a la Apple App Store. Una capa como Proton la pueden hacer igual que GPTK.
    Lo que realmente quieren no es que estén en Steam o Epic Games Store, sino que los juegos AAA entren a la App Store; por eso creo que GPTK está a medio hacer y su licencia también impide que Valve lo integre directamente en Steam.
  • Asahi Linux podría convertirse en el nuevo Boot Camp para usuarios de Mac que hacían arranque dual para jugar.
    Probé Diablo II Resurrected con Whiskey en un M1, y fue bastante impresionante que un juego nativo de Windows funcionara así de inmediato. Ahora lo único que impide ejecutar el juego es una estúpida actualización del launcher de Blizzard que provoca un crash.
    Aunque es un juego viejo de DX9, EverQuest II también corría muy bien a 1440p en una Mac mini M1, y Asahi Linux podría ayudar con títulos de 32 bits antiguos como Guild Wars.
  • Si Apple realmente quisiera eso, bastaría con implementar Vulkan.
  • Apple ya publicó el Game Porting Toolkit.

• Si no conoces bien Vulkan 1.3 pero te interesa trabajar con APIs gráficas de bajo nivel, definitivamente vale la pena echarle un vistazo. Está a un nivel completamente distinto de Vulkan 1.0 y cambia las reglas del juego.
  Una vez superada la barrera inicial, trabajar con él es agradable; gracias a todo el estado dinámico y a la eliminación de la configuración previa de render passes, es mucho más manejable. Incluso se volvió más fácil que OpenGL, que usé durante 20 años, y la programación gráfica vuelve a ser divertida.
  Con drivers modernos, se puede usar la mayoría de las funciones en prácticamente cualquier plataforma de escritorio con una GPU de los últimos 10 años.
  Lamentablemente no hay un framework de “valores predeterminados razonables” que permita empezar de inmediato, pero sí hay muchas bibliotecas auxiliares útiles para varios lenguajes.

  • He tocado OpenGL de a poco durante 20 años y, aunque no soy programador profesional de juegos, hago contenido 3D en mi tiempo libre.
    No había tenido tiempo de pasarme a Vulkan, pero parece que al final solo hace falta superar la barrera de inicialización y configuración. Después de eso, probablemente no vuelva a OpenGL.
    Este artículo me dio un pequeño empujón para animarme a probarlo de verdad.
  • ¿Hay algún tutorial o documentación para empezar específicamente con Vulkan 1.3? La última vez que busqué, solo encontré materiales que mezclaban de todo: formas viejas y nuevas en varias combinaciones.
    OpenGL también era así originalmente, así que quizá no sea tan distinto, pero da la sensación de que Khronos sí que se lució.

• Acabo de actualizar por el soporte de ES 3.2 y ya estoy sorprendido. Mi M1 se siente como si hubiera sido hecho para Asahi.
  Sinceramente, lo más probable es que macOS solo se haya iniciado durante la instalación o una vez por accidente. Me gusta que haya actualizaciones tan detalladas como esta.
  Me pregunto si algún navegador soporta renderizado sin copia, o si todavía hay varias capas de compositores de por medio. También recuerdo que el transform feedback de WebGL2 quedaba bloqueado porque provocaba lecturas de vuelta.

  • ¿Se puede eliminar macOS por completo? Al ver esto, empiezo a considerar una Mac mini para viajar.

• Cuando algo crasheaba, pensaba que de ninguna manera podía ser un bug del compilador, pero el 16 de abril efectivamente era un bug del compilador.
  Puedo decir con confianza que nunca me pasó algo así en mi carrera, aunque quizá sea menos raro cuanto más bajo sea el nivel de abstracción.

  • No puede ser un bug del compilador, y definitivamente tampoco puede ser un bug de la CPU.
    Salvo que seas desarrollador de kernel de bajo nivel; entonces ambas cosas pueden ser ciertas.
    Bromas aparte, en la práctica la gran mayoría de las veces no lo son, pero sin duda ocurren.
  • Al menos la parte del asignador de registros la escribieron ustedes mismos, ¿no?
    Si se trata de un compilador en desarrollo, que es tu propio trabajo y está en pruebas, el refrán de “no puede ser un bug del compilador” no aplica muy bien.

• El shader contiene una estructura peculiar: if (condition) { while (true) { } }
condition siempre es falsa, pero el compilador no lo sabe.
  Me pregunto cuál es el propósito de esta estructura, aparte de ser veneno para quienes escriben compiladores de shaders que cumplen el estándar.

  • ¿No es justamente el núcleo de la prueba lanzarle al autor del compilador una entrada venenosa para que no se rompa sin importar qué shader llegue?
    Más que que ese código en sí sea útil en la práctica, si una parte de un shader puede simplificarse funcionalmente a esta forma en ciertas situaciones, el compilador debe manejarla correctamente.
  • El propósito de esta estructura podría ser informarle al compilador que la condición siempre es falsa para que el optimizador pueda hacer más optimizaciones.
    Si el concepto no te resulta familiar, puedes ver estas funciones de C++, LLVM y Rust:
    https://en.cppreference.com/w/cpp/utility/unreachable
    https://en.cppreference.com/w/cpp/language/attributes/assume
    https://en.cppreference.com/w/cpp/memory/assume_aligned
    https://llvm.org/docs/LangRef.html#unreachable-instruction
    https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
    https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
    https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
    Un bucle infinito es, en la práctica, una instrucción inalcanzable, y una instrucción inalcanzable después de una rama se convierte, en la práctica, en una instrucción assume.
  • ¿Así es como un shader hace “panic”?
  • También podría ser un caso límite de algún tipo de generación de código.

• Me pregunto si esto se puede usar dentro de una VM. Desarrollo en macOS y en general estoy satisfecho, pero para pruebas ejecuto una imagen de Ubuntu en VMware.
  Estoy haciendo una app de gráficos 3D, así que no sé bien hasta dónde llega el passthrough de VMware. Me pregunto si la GPU de Apple Silicon se virtualiza en la VM y si, al correr esta distribución, podría mejorar el rendimiento gráfico.

  • Hay que instalarlo de forma nativa. Si quieres buen rendimiento 3D en una VM de Windows/Linux/macOS sobre macOS, Parallels es mucho mejor que VMware.

• ¿Alguien puede explicar qué relación tiene esto con MoltenVK? Como es un driver nativo, ¿significa que ya no se necesita MoltenVK?

  • MoltenVK es una implementación de Vulkan basada en Metal que permite ejecutar aplicaciones Vulkan en macOS.
    Asahi Linux es una distribución en desarrollo que busca hacer compatible Linux con los procesadores Apple serie M, y este artículo trata de hacer funcionar Vulkan con aceleración por GPU en Asahi.
  • Esto trata de usar Vulkan en Asahi Linux sobre hardware Mac M1. MoltenVK ofrece Vulkan sobre Metal en macOS.
  • Esto trata sobre Vulkan en Linux, no sobre macOS.
  • MoltenVK traduce Metal a Vulkan. Metal es la API gráfica principal de OS X e iOS, y esto es una implementación nativa de Vulkan para Linux.
    El artículo también lo dice así. Esto no puede ejecutarse directamente en OS X, así que no elimina la necesidad de MoltenVK.