ZLUDA, el proyecto open source que permite ejecutar apps CUDA en GPU AMD

 (cgchannel.com)
3 puntos por GN⁺ 2024-03-06 | 1 comentarios | Compartir por WhatsApp
  • ZLUDA 3 es una tecnología open source que busca ejecutar sin modificaciones en GPU AMD aplicaciones para GPU NVIDIA que estaban atadas a CUDA
  • Comenzó como una implementación alternativa compatible con CUDA para GPU Intel, pero tras la suspensión de las evaluaciones de Intel y AMD, ahora se publicó código orientado a GPU AMD
  • En Blender hay casos de rendimiento similar al backend nativo HIP, pero 3DF Zephyr y RealityCapture aparecen como “much slower” en ZLUDA, por lo que la variación según la app es grande
  • Se confirmó la posibilidad de ejecutar apps de CG exclusivas de NVIDIA como RealityCapture y Arnold, pero el soporte de OptiX se mantiene en un nivel mínimo en Linux, lo que impone restricciones a los flujos de trabajo de renderizado
  • Sin apoyo de Intel ni AMD, el proyecto está cerca de “realistically now abandoned”, y la licencia del SDK de NVIDIA también limita el desarrollo de capas de traducción para plataformas que no sean NVIDIA

El problema de dependencia de CUDA que ZLUDA 3 busca resolver

  • ZLUDA 3 es un proyecto open source para ejecutar aplicaciones basadas en GPU creadas para GPU NVIDIA en hardware de otros fabricantes
  • Está diseñado para ejecutar aplicaciones existentes en hardware nuevo sin modificaciones, sin exigir trabajo adicional de porting a los desarrolladores de apps
  • ZLUDA se presentó por primera vez en 2020 como una implementación drop-in alternativa de CUDA para GPU Intel, y después de la versión 2 de 2021 se volvió difícil continuar su desarrollo
  • En 2021, cuando Andrzej Janik trabajaba en Intel, la empresa evaluó ZLUDA como candidata a tecnología oficial, pero concluyó que “no había un caso de negocio para ejecutar aplicaciones CUDA en GPU Intel”
  • Janik dejó Intel en 2022 y se acercó a AMD; AMD también evaluó ZLUDA durante dos años, pero decidió no seguir adelante
  • Luego se publicó como open source el código actualizado, y se puede ver más contexto en el artículo de Phoronix

Alcance de funcionamiento comprobado en apps de CG

  • ZLUDA 3 tiene como objetivo ejecutar en GPU AMD apps de GPU desarrolladas con la API CUDA de NVIDIA
  • En áreas como VFX, motion graphics y visualización, algunas apps y renderizadores clave de CG están basados en CUDA, por lo que en la práctica siguen siendo exclusivos de NVIDIA
  • HIP de AMD es una tecnología para portar apps CUDA a hardware AMD, pero requiere trabajo por parte de los desarrolladores de software
    • HIP se usa en versiones compatibles con AMD de Redshift y Blender Cycles
    • ZLUDA 3 también está construido sobre HIP, pero su objetivo es ejecutar apps CUDA existentes sin modificaciones
  • Entre el software exclusivo de NVIDIA que Janik probó con ZLUDA se incluyen 3DF Zephyr, RealityCapture y Autodesk Arnold
  • El soporte para Arnold está a nivel de prueba de concepto, y las escenas renderizadas con éxito mediante la implementación de OptiX de ZLUDA son limitadas

Límites prácticos de rendimiento y compatibilidad

  • Janik evalúa que las apps CUDA se ejecutan en GPU AMD con “near-native performance”
  • Según los benchmarks de Phoronix y un hilo del foro Blender Artists, hay casos en Blender donde el rendimiento de ZLUDA es similar al del backend nativo HIP
  • En cambio, el repositorio de ZLUDA en GitHub marca a 3DF Zephyr y RealityCapture como much slower en ZLUDA
  • Muchos renderizadores GPU usan, además de CUDA, OptiX de NVIDIA para acelerar el ray tracing
    • El soporte de OptiX en ZLUDA está en un nivel “minimum”
    • El soporte de OptiX solo existe en Linux y no está disponible en Windows
    • El estado de la implementación es “buggy, unoptimized and incomplete”
    • ZLUDA-OptiX no está incluido en las versiones redistribuibles, por lo que hay que compilarlo directamente
  • Es difícil determinar si otras apps de CG basadas en CUDA pueden ejecutarse sin pruebas de usuarios

Continuidad del proyecto y restricciones de licencia

  • Janik considera que, sin el apoyo de Intel o AMD, ZLUDA está en un estado “realistically now abandoned”
    • Está abierto a propuestas que hagan avanzar el proyecto
    • De lo contrario, es probable que solo agregue soporte para tecnologías de NVIDIA que le interesen personalmente, como DLSS
    • El código actual también puede ser útil para desarrolladores de software que estén haciendo un porting gradual de CUDA a HIP
  • Según una actualización del 14 de marzo de 2024, Tom’s Hardware señaló que los términos de licencia del SDK de NVIDIA prohíben usar los resultados de SDK, incluido el CUDA Toolkit, para desarrollar tecnologías de traducción orientadas a plataformas que no sean NVIDIA
  • Las versiones compiladas de ZLUDA 3 están disponibles para Windows y Linux, y el código fuente se ofrece bajo Apache 2.0 o MIT license
  • Descarga de ZLUDA 3 disponible en el repositorio de GitHub del proyecto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-06
Opiniones en Hacker News

  • Hace 22 días también hubo una discusión relacionada: una publicación [0] que decía que AMD había financiado una implementación drop-in de CUDA basada en ROCm y que luego se publicó como open source recibió 400 comentarios.
    El comentario principal destacado de ese hilo señalaba que la publicación en sí fue resultado de que AMD dejara de financiar el proyecto: “Después de 2 años de desarrollo y revisión, AMD determinó que no había un caso de negocio para ejecutar aplicaciones CUDA en GPU AMD. Una de las condiciones del contrato con AMD era que, si AMD decidía que no era apto para desarrollo adicional, yo podía publicarlo. Y así llegamos a hoy”. Fuente: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • Que AMD haya cortado la financiación de este proyecto es realmente absurdo. Apenas se publicó como open source, empezó a generar valor para los usuarios de AMD.
    Este tipo de cosas parece que debería ser la máxima prioridad de AMD, pero en la práctica durante años anduvo dando vueltas con dos —¿ahora tres?— API alternativas con poco soporte.

    • En cuanto esto se convierta en una opción confiable, Nvidia enviará de inmediato una orden de cese y desistimiento y demandará. Como solución seria es un callejón sin salida, así que en ese contexto se entiende.
    • Tal vez sea porque quieren que la gente use HIP.
      “HIP es muy ligero, por lo que tiene poco o ningún impacto en el rendimiento frente a programar directamente en modo CUDA”.
      “La herramienta HIPIFY convierte automáticamente el código fuente CUDA a HIP”.
      1. https://github.com/ROCm/HIP
    • Pensándolo estratégicamente, es difícil ver esto como lo mejor para AMD. Si no es de calidad de producto y no está validado legalmente, solo será una herramienta que permita a los desarrolladores crear aplicaciones en AMD y desplegarlas en Nvidia.
      En el mercado de tarjetas gráficas de consumo podría traer beneficios a corto plazo, pero a largo plazo es casi pegarse un tiro en el pie, porque sigue consolidando la posición de Nvidia en centros de datos.
    • Es muy probable que hayan recibido información previa sobre el anuncio de NVIDIA y liberaran a este contratista. Según los términos del contrato, el proyecto se habría vuelto open source.
    • Aquí se parte del supuesto de que AMD eligió rendirse. ¿Y si quizá están trabajando en algo mejor?

  • En esta discusión también parece relevante la publicación que dice que “Nvidia prohibió usar capas de traducción para ejecutar software CUDA en otros chips” [1].

    [1] https://news.ycombinator.com/item?id=39592689

    • Si no usas hardware de Nvidia, no usas drivers de Nvidia y nunca aceptaste el EULA de Nvidia, no veo por qué debería importarte.
      La emulación está protegida legalmente, tanto de forma explícita como por jurisprudencia. La reproducción de API con fines de compatibilidad llegó hasta la Corte Suprema de EE. UU. y se determinó que no estaba sujeta a copyright, al menos dentro de un margen bastante amplio.
      No soy abogado, pero no veo bien qué fundamento legal espera tener Nvidia. Si se trata de una persona o empresa que no tiene ningún hardware de Nvidia, el asunto se siente irrelevante. Si una empresa ya tiene hardware de Nvidia, quizá puedan intentar algún argumento, pero ¿eso no entra más bien de lleno en el terreno de las prácticas anticompetitivas?
    • No veo en qué se diferencia esto de Wine/Proton. El EULA de Microsoft probablemente tenga condiciones parecidas; si fueran aplicables, ¿Microsoft no habría enviado las mismas órdenes de cese y desistimiento a los desarrolladores de Wine?
    • Hay que volver a subrayar que esa cláusula, a diferencia de lo que afirma el artículo, estaba en el EULA de CUDA desde enero de 2022 y, a diferencia de la actualización del artículo, también estaba incluida en la descarga.
    • ¿Eso importa? No se necesita permiso de nadie para implementar un sistema con una interfaz compatible con otro sistema.
      Aunque se violaría el EULA, no hace falta aceptar el EULA mientras no descargues software CUDA, y los autores de ZLUDA probablemente pudieron evitarlo.
    • NVIDIA no tiene autoridad para hacer eso. Aquí no interviene ningún SDK de NVIDIA.

  • Que “Intel también acabó determinando que ‘no había un caso de negocio para ejecutar aplicaciones CUDA en GPU Intel’” es bastante frustrante.

    • En pocas palabras, toda empresa que alcanza cierto tamaño y edad termina soñando con ser monopolista más que con ser competidora.
    • La división gráfica de Intel era tan mala que tuvo que dejar de usar el nombre Intel HD por la mala impresión que dejó en la gente.

  • Se confirmó algo que cualquiera que haya tocado alguna vez GPGPU de AMD sabe. Lo único que impide que AMD se convierta en una empresa de 2 billones de dólares es un software realmente espantoso.
    Recuerdo haber encontrado un bug en el compilador OpenCL de AMD [1], y también era muy fácil matar el compilador OpenCL con un error de segmentación. Eso nunca se corrigió, así que dejé de reportarlo.
    Que AMD no haya desarrollado un competidor de CUDA es una de las decisiones más cortoplacistas que he visto. No entiendo por qué no cambiaron a la junta directiva por gente que entienda que, aunque fabriques el mejor hardware, si el software que lo usa es, por decirlo muy suavemente, pésimo, nadie lo va a comprar ni usar.
    Los clientes tenemos que comprar caras tarjetas Nvidia porque, al parecer, somos demasiado ricos como para preocuparnos por ese billón de dólares de valor que la junta de AMD dejó sobre la mesa. Si alguien tiene acciones de AMD, debería hacerse preguntas. Esa junta debería irse por el desagüe más cercano.
    [1] https://github.com/msoos/amdmiscompile -- al final esto sí se corrigió

    • ¿Puedes explicarme qué es GPGPU como si se lo explicaras a JavaScript?
      Mi entendimiento ingenuo es que una tarjeta gráfica es una computadora rara a la que puedes subirle instrucciones y datos y dejar que calcule por su cuenta.
      No entiendo por qué CUDA es tan importante. ¿AMD no podría simplemente permitir acceso directo a sus GPU como si fueran un arreglo de 4096 placas Arduino?
    • Exacto. Por otro lado, AMD suele ser más amigable con el open source que Nvidia. Nvidia fue activamente hostil durante un tiempo; basta ver el video de Linus diciendo “F* you!”.
      Las empresas que desarrollan hardware, en general, son malas haciendo software. Hay excepciones, pero no muchas, y esas empresas de hecho han sido recompensadas en su cotización bursátil. No conozco la cultura de la división de software de AMD, pero normalmente arreglar algo así requiere cambios bastante grandes.
      Es difícil que se resuelva solo cambiando a la junta. Si las órdenes de la alta dirección no son el único factor que arrastra a la empresa hacia abajo, habría que cambiar muchas más capas de gestión y reemplazar a bastantes mandos medios. Si la contratación de software no se hizo bien, a veces incluso hay que cambiar a contribuidores individuales.
    • No entiendo por qué AMD no colabora con Intel para impulsar SYCL como el método estándar de GPGPU y programación heterogénea.
      Intel es buena en software, SYCL es un estándar abierto, así que ambas empresas podrían beneficiarse del mismo código, y los clientes podrían ejecutar código SYCL incluso en Threadripper si quisieran. Algunos Threadripper de hoy son tan rápidos como algunas GPU.
      ¿AMD intenta construir su propio ecosistema cerrado y propietario? No entiendo por qué no se compromete con un estándar abierto multiplataforma.
    • A mí AMD Software en sí me gustaba bastante. Era fácil limitar la tasa de frames a 60 para evitar que la GPU se fuera al máximo cuando un juego o software no lo soportaba de forma nativa, y también podía configurar con una tecla rápida la repetición instantánea, que va grabando continuamente los últimos minutos, como Shadowplay.
      Cuando mi UPS no era buena, también podía limitar la energía de la GPU, y podía hacer overclock automático para estirar mi RX 580 más o menos un año más.
      Pero el software/los drivers desde alrededor de 2020 hacen que los títulos de VR crasheen en menos de una hora. Tampoco hay paquete de software para Linux, y CoreCtrl no es tan bueno. A veces la repetición instantánea simplemente no funciona. Nunca logré hacer funcionar bien ROCm con LLM locales ni en Windows ni en Linux, y a DKMS le encanta hacer un montón de compilaciones inútiles en cada apt upgrade.
      Estoy pensando si para mi próxima GPU me voy por una Intel Arc por curiosidad, o simplemente vuelvo a Nvidia. Las candidatas serían algo como A580, RX 6600 o RTX 3050, aunque también podría aguantar hasta que bajen los precios de otros componentes.

  • ¿Existe algún lenguaje de programación que compile a varios lenguajes de kernels, como Metal, CUDA o lo que sea del lado de AMD? Si no existe, ¿por qué no?
    Un compilador de C compila a varias arquitecturas de CPU. ¿No debería haber también un compilador para arquitecturas de GPU? Tal vez simplemente nadie lo ha construido todavía.

    • ¿Cuenta si incluimos OpenCL?
      https://www.khronos.org/api/opencl
    • OpenMP 5 especificó soporte para GPU. Una búsqueda rápida sugiere que algunos compiladores ahora lo soportan al menos parcialmente.

  • ¿Alguien ha usado esto para correr herramientas de fotogrametría open source como Meshroom? El artículo menciona algunas herramientas propietarias, pero mis necesidades son bastante pequeñas.

  • Esto se parece muchísimo al caso Oracle contra Google por el uso de bytecode de la JVM.

    • No me parece. El punto en disputa no es la conversión de bytecode, sino atar al hardware la propiedad intelectual de bibliotecas de más alto nivel.
      Es parecido a que Google dijera “nuestras aplicaciones de Android solo pueden ejecutarse en teléfonos aprobados por Google”. Según entiendo, Google en la práctica sí hace algo así con cosas como el framework de Play o Maps.

  • Hace poco escuché un rumor interesante: la persona de NVIDIA que estuvo a cargo de CUDA tuvo que luchar durante años para conseguir recursos y convencer a la empresa de tomar este proyecto en serio.
    Sin CUDA, NVIDIA jamás se habría convertido en la empresa de casi 1 billón de dólares que es hoy.

  • También está relacionado que geohot siguiera peleándose con costosas GPU de AMD: https://twitter.com/tinygrad/status/1764734675002810622