VUDA: implementación de CUDA sobre Vulkan

• VUDA es una biblioteca solo de encabezados basada en Vulkan que proporciona una interfaz de la API Runtime de CUDA para escribir aplicaciones aceleradas por GPU
• Sus funciones siguen la especificación de CUDA runtime dentro de lo posible, y para el uso general se puede consultar la documentación de referencia de la API NVIDIA CUDA Runtime
• Se puede acceder a todas las funciones incluyendo vuda.hpp y usando el espacio de nombres vuda::; vuda_runtime.hpp encapsula y redirige las funciones de CUDA
• El flujo de trabajo de ejemplo usa llamadas de la API Runtime de CUDA como cudaSetDevice, cudaMalloc, cudaMemcpy y cudaFree, y cuando no se usa NVCC ejecuta un módulo de shader de Vulkan con vuda::launchKernel("add.spv", "main", ...)
• La documentación incluye los apartados Change List, Setup and Compilation, Deviations from CUDA e Implementation Details

[GN⁺]

Comentarios en Hacker News

• No es una implementación de CUDA, sino de la API de runtime de CUDA
  Esta API se usa para configurar la tarjeta, asignar y copiar memoria, y ejecutar kernels
  Lo importante es que con esto no se puede escribir código de kernel que realmente corra en la GPU

  • Por un momento me ilusioné pensando que eso significaba poder ejecutar código CUDA en GPUs de AMD, pero al leer la explicación vi que no es así
  • Entonces me pregunto para qué sería útil esto
  • Si quiere presentarse como una alternativa a CUDA, necesita soporte para PTX y soporte de desarrollo para varios lenguajes
    De lo contrario, ni siquiera puede arrancar con muchas cargas de trabajo
• 1. Esto implementa una API tosca de estilo C
     También existe un wrapper de API Modern C++ que ofrece verificación automática de errores, control de recursos con RAII, etc.: https://github.com/eyalroz/cuda-api-wrappers
     Por cierto, yo soy el autor
  2. Implementar la API de runtime no es la elección correcta
     Para cosas como el aislamiento de contexto o agregar dinámicamente kernels JIT recién compilados como módulos, lo importante es implementar la API del driver
  3. Este proyecto no llega ni a 3000 líneas
     Envolver toda la API central de CUDA, es decir driver, runtime, NVTX, CUDA-C++ y compilación JIT de PTX, me llevó más de 14,000 líneas

• Me pregunto qué relación tiene esto con el objetivo del que hablaba George Hotz: hacer posible el machine learning en chips AMD y romper el dominio de Nvidia
  No soy experto, pero este enfoque parece potente e importante
  Aun así, el sistema es tan complejo que dudo que una sola persona pueda construirlo, y para arrancar parece que haría falta patrocinio empresarial
  Quizá AMD podría interesarse en pagar ingenieros y mejorarlo de forma iterativa

  • Hotz no está hablando solo de bibliotecas en espacio de usuario, también habla del driver

    The software is terrible! There’s kernel panics in the driver. You have to run a newer kernel than the Ubuntu default to make it remotely stable. I’m still not sure if the driver supports putting two cards in one machine, or if there’s some poorly written global state. When I put the second card in and run an OpenCL program, half the time it kernel panics and you have to reboot.
    También toca la parte de espacio de usuario, pero está claro que ve mucho por arreglar en toda la pila, por encima y por debajo de bibliotecas como esta

  • Encontré https://www.youtube.com/watch?v=Mr0rWJhv9jU y https://geohot.github.io/blog/jekyll/update/2023/06/07/a-div...
    Ahora me siento un poco más tranquilo sobre mi experiencia usando AMD
    Parecía que había problemas graves con el driver de GPU, y resultó que no era solo yo

• Si alguien quiere entrenar o ejecutar modelos de machine learning con una GPU AMD en Windows, le conviene revisar torch-directml y tensorflow-directml

  • No tengo claro si DirectML tiene más sentido que AMD persiguiendo compatibilidad con CUDA mediante ROCm/MiOpen/HIP
    CUDA y DirectX parecen demasiado de bajo nivel para usarse como una API compatible sobre hardware muy distinto, es decir AMD y Nvidia, sin sacrificar mucho rendimiento
    cuDNN es de más alto nivel, así que hay más margen para ofrecer compatibilidad sin pérdida de rendimiento manteniendo implementaciones de kernels separadas para hardware de AMD y Nvidia
    Pero gran parte de lo que hacen frameworks como PyTorch no se basa solo en cuDNN, sino también en kernels personalizados
    La mejor opción para AMD parece ser una API de bajo nivel sólida e inquebrantable, y soporte para compiladores optimizadores de machine learning de alto nivel que faciliten a proveedores de frameworks como PyTorch, TensorFlow y JAX construir soporte encima
    Al final, quienes se benefician de eso son los proveedores de frameworks, así que AMD tendría que colaborar muy de cerca con ellos
    Es raro que AMD haya tratado el soporte de machine learning como algo secundario durante años
    Puede que haya pensado que el mercado de machine learning para consumo era pequeño comparado con el de gráficos y videojuegos, y que no valía la pena el esfuerzo, pero como demostró Nvidia, este es el camino hacia contratos de centros de datos mucho más rentables
  • Me pregunto cómo funciona realmente
    La última vez que probé DirectML, el soporte era malo y había poco software que lo usara
    El rendimiento tampoco parecía muy bueno
    Ahora uso una instalación de Linux, y gracias a ROCm puedo usar herramientas populares como Automatic111 webui y oobabooga
  • ¿Eso realmente funciona?
    Si AMD sacara una GPU a precio razonable que le gane a Nvidia en machine learning, quizá compraría una GPU nueva
    Las GPUs Nvidia decentes son demasiado caras como para justificar la compra

• Parece un proyecto muerto
  El último commit es de febrero de 2022

  • Y además ese commit solo agregaba una línea
    La mayor parte del código es de hace entre 3 y 5 años

• Nunca he programado GPUs directamente, así que pregunto: ¿cómo se compara esto con HIP?
  ¿Podría ser una capa de abstracción eficiente sobre GPUs de Nvidia y AMD?

  • Según https://news.ycombinator.com/item?id=34399633, hipify-clang es una herramienta basada en clang que traduce código fuente CUDA a código fuente HIP
    Convierte el código CUDA a un árbol de sintaxis abstracta, luego los matchers de transformación lo recorren y generan el código fuente HIP
    Además, aquí está la lista de APIs CUDA compatibles con hipify-clang: https://rocm.docs.amd.com/projects/HIPIFY/en/latest/supporte...

• No espero mucho de AMD
  Deberían haber creado herramientas de compatibilidad hace mucho tiempo

• Este tipo de proyectos aparecen con bastante frecuencia, pero no han logrado ganar impulso, y yo sigo usando GPUs de Nvidia
  No creo que este vaya a ser muy distinto

• Bastante interesante
  Entonces, ¿eso significa que mi programa acelerado con CUDA debería poder ejecutarse también en dispositivos AMD e Intel?