CUDA para AMD en Windows funciona, pero solo a través de una vía de compatibilidad limitada
Los usuarios de AMD ahora cuentan con una configuración reproducible de CUDA para AMD en Windows, pese a que CUDA sigue siendo una plataforma de NVIDIA. El proyecto comunitario traduce llamadas CUDA seleccionadas mediante ZLUDA y luego las ejecuta a través de las bibliotecas HIP de AMD. Su creador informa de una carga de trabajo de entrenamiento de IA completada en una Radeon RX 9060 XT.
Este logro importa porque cruza una frontera difícil. Los desarrolladores pueden partir de una aplicación de Windows creada para la pila de software de NVIDIA y ejecutarla en una configuración de AMD compatible. No necesitan reescribir primero esa aplicación para HIP.
Sin embargo, el resultado no convierte CUDA en una solución independiente del hardware. La configuración depende de una capa de compatibilidad, versiones de software fijadas y reemplazos incompletos de bibliotecas. Actualmente, solo un modelo de GPU tiene estado validado en el proyecto.
Por tanto, la verdadera competencia no es simplemente entre el hardware de AMD y NVIDIA. Se trata de la compatibilidad con aplicaciones CUDA existentes frente a la fiabilidad del soporte nativo del proveedor. La nueva configuración avanza en el primer objetivo sin ofrecer el segundo.
El proyecto convierte un binario CUDA en una carga de trabajo para AMD
El cambio importante es una ruta documentada y repetible desde una aplicación de Windows orientada a CUDA hasta una GPU de AMD.
El proyecto de compatibilidad de código abierto reúne scripts de instalación, preparación del entorno de ejecución, diagnósticos y validación. Se basa en ZLUDA y en el software HIP para Windows de AMD, en lugar de implementar otro entorno de ejecución de GPU desde cero.
ZLUDA es una capa de traducción que presenta interfaces compatibles con CUDA a una aplicación. Redirige las operaciones compatibles hacia funciones correspondientes disponibles en la pila de GPU anfitriona.
HIP, la Heterogeneous-compute Interface for Portability, es el entorno de ejecución de C++ y el lenguaje de kernels de AMD para software portátil de GPU. En esta configuración, HIP proporciona la capa inferior que finalmente se comunica con la GPU Radeon.
La ruta comienza con un programa de Windows que espera componentes CUDA de NVIDIA. ZLUDA recibe esas llamadas y dirige las operaciones de bibliotecas compatibles hacia equivalentes de AMD.
Por ejemplo, las operaciones de cuBLAS pueden llegar a rocBLAS, mientras que las llamadas a cuSPARSE pueden llegar a rocSPARSE. Estas bibliotecas manejan cargas de trabajo habituales de álgebra lineal y matrices dispersas.
El repositorio incluye un instalador de PowerShell que comprueba la GPU detectada, el controlador, el SDK de HIP y las bibliotecas matemáticas necesarias. Luego descarga una compilación fijada de ZLUDA y verifica los archivos descargados mediante hashes SHA-256.
El instalador también puede recuperar LibTorch 2.3.0 compilado para CUDA 11.8. LibTorch es la distribución en C++ de PyTorch, utilizada cuando las aplicaciones incorporan funciones de PyTorch sin un entorno de ejecución de Python.
Esa descarga ocupa unos 2,66 GB, según el repositorio. Los usuarios que no necesiten LibTorch pueden omitirla.
Tras la instalación, los scripts crean informes específicos de la máquina sobre el entorno de ejecución y la GPU. Otro diagnóstico ejecuta la utilidad cuda_check de ZLUDA contra la pila AMD instalada.
Para iniciar una aplicación es necesario usar el script envoltorio del proyecto. Este coloca las bibliotecas de compatibilidad necesarias junto al ejecutable objetivo y configura las rutas del entorno de ejecución HIP para ese proceso.
Este modelo de preparación local limita los cambios en todo el sistema. También expone una debilidad central: cada aplicación sigue dependiendo de las funciones y bibliotecas CUDA exactas que ZLUDA puede traducir.
El proyecto informa de comprobaciones correctas para la interfaz del controlador CUDA, cuBLAS, cuBLASLt, cuSPARSE y cuFFT. Esos resultados se aplican a su combinación validada de máquina y software.
No establecen compatibilidad general entre las aplicaciones de Windows. Un programa puede superar las comprobaciones básicas del entorno de ejecución y, más adelante, llegar a una función no compatible durante otra carga de trabajo.
El repositorio afirma que solo la Radeon RX 9060 XT, identificada por el objetivo gfx1200 de AMD, tiene estado de referencia validada. Otras arquitecturas Radeon detectadas siguen siendo candidatas sin verificar.
Ese lenguaje es importante. La detección significa que un script reconoce el dispositivo y su arquitectura. No significa que la aplicación, la capa de traducción y las bibliotecas funcionarán juntas.
Por qué CUDA para AMD en Windows importa ahora
El proyecto aborda el coste de migración en torno a las aplicaciones CUDA, no la titularidad de CUDA ni la ventaja de hardware de NVIDIA.
CUDA es la plataforma y el modelo de programación de computación paralela de NVIDIA. Su modelo de programación abarca la ejecución de kernels, la gestión de memoria, la sincronización y bibliotecas optimizadas para GPU de NVIDIA.
Muchas aplicaciones dependen de algo más que código fuente con estilo CUDA. Llaman a bibliotecas como cuBLAS, cuFFT, cuSPARSE y cuDNN, al tiempo que dependen de comportamientos específicos del entorno de ejecución.
Este software acumulado genera costes de cambio. Comprar una GPU diferente no convierte automáticamente en portátil un programa de Windows dirigido a CUDA.
Normalmente, los desarrolladores tienen tres opciones generales. Pueden seguir con hardware de NVIDIA, portar el programa a otra interfaz o situar una capa de traducción entre la aplicación y el hardware.
AMD admite la ruta de portabilidad mediante HIP. Sus herramientas HIPIFY traducen muchas construcciones de código fuente CUDA a C++ HIP portátil.
La conversión de código fuente puede ser una decisión sólida a largo plazo cuando los desarrolladores controlan la aplicación. También exige pruebas, mantenimiento y, en ocasiones, cambios manuales para APIs no compatibles.
Esa ruta aporta poco a un usuario que solo dispone de un binario compilado para Windows. También genera trabajo para equipos pequeños que mantienen dependencias específicas de CUDA.
ZLUDA apunta a esa brecha. Intenta preservar la interfaz orientada a CUDA que espera la aplicación mientras traduce operaciones en tiempo de ejecución.
Este enfoque se parece más a un puente de compatibilidad que a un nuevo estándar de programación. La aplicación sigue hablando CUDA, mientras el puente asigna las solicitudes compatibles a la pila de software de AMD.
Windows hace que el problema sea especialmente relevante. AMD ha ampliado allí su soporte para computación con GPU, pero su pila para Windows históricamente ha expuesto menos componentes que ROCm en Linux.
AMD describe el Windows HIP SDK como un subconjunto de la plataforma ROCm más amplia. Sus matrices de soporte también limitan la cobertura oficial a los sistemas operativos y GPU incluidos en las listas.
Las versiones recientes de ROCm han mejorado las opciones nativas para Windows, incluido el soporte de PyTorch en hardware Radeon seleccionado. El soporte nativo reduce la necesidad de traducción cuando las aplicaciones ya ofrecen una vía para AMD.
Sin embargo, el soporte nativo de PyTorch no resuelve todas las dependencias de CUDA. Una aplicación de Windows podría incluir una compilación de LibTorch específica para CUDA o cargar directamente bibliotecas de NVIDIA.
El nuevo repositorio aborda esa situación menos conveniente. Su motivación declarada fue una aplicación de entrenamiento con LibTorch orientada a CUDA que necesitaba ejecutarse en una GPU AMD de escritorio.
El proyecto informa de que su aplicación de prueba completó inferencia, actualizaciones de aprendizaje por refuerzo y trabajo de optimización. La red contenía 2.216.347 parámetros y ejecutó una iteración de validación que cubría 65.536 pasos temporales.
Estas cifras describen una carga de trabajo real, en lugar de una prueba sintética de API. Dan al proyecto más credibilidad que un iniciador que solo abre una ventana de aplicación.
Aun así, la prueba sigue siendo limitada. Una red de aprendizaje por refuerzo relativamente pequeña no puede representar todos los transformadores, generadores de imágenes, simulaciones científicas o canalizaciones de renderizado.
La presión de desarrollo recae de forma más directa sobre la experiencia de software de AMD en Windows. Cada experimento de compatibilidad exitoso pone de relieve la demanda de aplicaciones que todavía asumen CUDA.
NVIDIA también enfrenta una presión de otro tipo. Las capas de traducción ponen a prueba cuánto de la base de aplicaciones de CUDA depende de interfaces esenciales que otro entorno de ejecución puede reproducir.
Ninguna de estas presiones produce un cambio inmediato de plataforma. Sí demuestra que los desarrolladores siguen buscando formas de sortear las fronteras de aplicaciones específicas de cada proveedor.
El mecanismo preserva APIs, no toda la plataforma CUDA
ZLUDA puede traducir interfaces seleccionadas, pero las aplicaciones CUDA a menudo dependen de comportamientos que van mucho más allá de esas interfaces.
Una aplicación CUDA suele contener código anfitrión que se ejecuta en la CPU y trabajo de dispositivo que se ejecuta en la GPU. El anfitrión asigna memoria, transfiere datos e inicia kernels.
El binario también puede llamar a bibliotecas optimizadas. Estas bibliotecas suelen determinar si una aplicación de IA o científica funciona a una velocidad útil.
ZLUDA presenta reemplazos para componentes orientados a CUDA y los conecta a backends no NVIDIA. En hardware AMD, esos backends usan bibliotecas HIP y ROCm.
Este modelo puede funcionar bien cuando un programa se mantiene dentro de las funciones de entorno de ejecución implementadas y las bibliotecas asignadas. Se vuelve frágil cuando la aplicación espera comportamientos ausentes.
La compatibilidad de versiones añade otra capa. Las aplicaciones CUDA pueden dirigirse a distintos kits de herramientas, formatos binarios, bibliotecas y supuestos del compilador.
El repositorio fija ZLUDA v6 preview 69, AMD HIP SDK 6.4 y LibTorch 2.3.0 con CUDA 11.8. Fijar versiones convierte una colección cambiante de dependencias en una combinación comprobable.
Esa disciplina mejora la reproducibilidad. También significa que los usuarios no deben asumir que los componentes más nuevos son intercambiables.
Un HIP SDK más reciente puede cambiar rutas de bibliotecas, símbolos exportados u objetivos de dispositivos compatibles. Una aplicación más reciente orientada a CUDA puede llamar a funciones que su capa de compatibilidad fijada no implementa.
El proyecto informa de que cuBLAS, cuBLASLt, cuSPARSE y cuFFT superaron su comprobación de entorno de ejecución. Estos componentes cubren operaciones importantes de matrices, computación dispersa y transformadas de Fourier.
La pieza ausente más significativa es cuDNN. La biblioteca CUDA Deep Neural Network de NVIDIA proporciona primitivas optimizadas utilizadas por muchas cargas de trabajo de redes neuronales.
El repositorio afirma que cuDNN no está disponible con su configuración validada del HIP SDK estable para Windows. También señala que el SDK carece de la colección completa de bibliotecas ROCm AI disponible en otros entornos.
Esa omisión crea una frontera estricta para las aplicaciones. El software con un uso intensivo de convoluciones que espera cuDNN puede fallar, requerir una pila de desarrollo más reciente o necesitar trabajo adicional de compatibilidad.
La carga de trabajo de aprendizaje por refuerzo completada no necesitó cuDNN en la ruta probada. Las operaciones de matrices densas fueron suficientes para las funciones que ejercitó.
Ese detalle explica tanto el resultado como sus límites. El proyecto seleccionó una carga de trabajo compatible con las bibliotecas disponibles en su máquina.
La traducción en tiempo de ejecución también difiere de la portabilidad a nivel de código fuente. El código HIP puede compilarse y optimizarse para distintos backends, mientras que una capa de compatibilidad binaria debe inferir y redirigir el comportamiento existente.
El trabajo a nivel de código fuente brinda a los desarrolladores más control sobre el ajuste específico de cada arquitectura. La traducción ofrece acceso inicial más rápido cuando modificar la aplicación original no es práctico.
Ningún método garantiza un rendimiento idéntico. Las GPU difieren en ancho de ejecución, comportamiento de memoria, soporte de instrucciones y hardware especializado.
Una función traducida puede producir resultados correctos utilizando una ruta menos eficiente. A la inversa, una biblioteca de proveedor asignada puede rendir bien porque AMD ya optimizó la operación subyacente.
Esto explica por qué una sola prueba comparativa no puede resolver la cuestión más amplia del rendimiento. La sobrecarga de traducción es solo un factor, mientras que la selección de bibliotecas y el comportamiento de los kernels pueden dominar el tiempo total de ejecución.
El repositorio registró una comparación controlada el 13 de septiembre de 2026. Ejecutó diez iteraciones por entorno de ejecución en la misma carga de trabajo de aprendizaje por refuerzo de la RX 9060 XT.
Después de eliminar la primera iteración de calentamiento de cada prueba, la ruta upstream alcanzó una mediana reportada de 13.278 pasos totales por segundo. Una superposición personalizada recuperada alcanzó 12.876.
El repositorio calcula que la superposición personalizada fue aproximadamente un 3,03 por ciento más lenta en esa prueba. Por ello, mantiene la ruta pública upstream como predeterminada.
Esta comparación evalúa dos configuraciones de compatibilidad en una sola máquina. No compara la tarjeta Radeon con una GPU NVIDIA ni con una implementación HIP nativa.
Las cifras históricas del repositorio utilizaron otra configuración de entrenamiento. No pueden compararse directamente con la prueba controlada.
Para los desarrolladores, el resultado útil es más simple. Los componentes públicos completaron la carga de trabajo elegida sin archivos binarios privados ni recuperados.
Esto facilita inspeccionar y reproducir el procedimiento. Los resultados independientes en otro hardware determinarán si se convierte en algo más que una referencia para una sola máquina.
Una GPU verificada deja una gran brecha de compatibilidad
La configuración es un experimento respaldado por evidencia, no soporte general de CUDA para tarjetas Radeon.
La RX 9060 XT es actualmente el único dispositivo validado que figura en el proyecto. Los scripts reconocen familias adicionales de arquitectura AMD, pero las etiquetan como candidatas.
La matriz oficial de soporte de AMD es una limitación independiente. La empresa afirma que las GPU ausentes de su tabla actual no cuentan con soporte oficial en la distribución relevante de Windows.
Incluso una GPU incluida en la lista no hereda la validación del repositorio. El soporte oficial de HIP y una traducción CUDA exitosa prueban capas distintas del sistema.
Un usuario necesita un controlador AMD compatible, una instalación funcional de HIP, bibliotecas compatibles, un comportamiento correcto de ZLUDA y una aplicación que se mantenga dentro de la cobertura implementada.
Un fallo en cualquiera de estas capas puede producir un error o un resultado incorrecto. Algunos problemas aparecerán durante la instalación, mientras que otros solo surgirán tras un cálculo sostenido.
La corrección merece más atención que el simple éxito al iniciar la aplicación. Las cargas de trabajo numéricas pueden completarse y aun así generar resultados distintos debido a comportamientos de precisión, bibliotecas o implementación.
Un plan de validación serio debería comparar los resultados esperados, el comportamiento del entrenamiento y la repetibilidad. También debería probar presión de memoria, ejecuciones prolongadas y recuperación ante errores.
El repositorio proporciona scripts y una carga de trabajo documentada, lo que ayuda a otros usuarios a iniciar ese proceso. La validación independiente sigue siendo escasa porque el proyecto es nuevo y la cobertura de hardware es limitada.
ZLUDA describe su software como un reemplazo directo de CUDA para GPU que no son NVIDIA. Su repositorio público también incluye una larga lista de cambios de implementación y versiones preliminares.
Sin embargo, una interfaz de reemplazo directo no equivale a compatibilidad completa de comportamiento. El historial de versiones de ZLUDA refleja correcciones continuas para cargadores, comportamiento del compilador, tipos de datos y gestión de versiones de CUDA.
El software preliminar puede introducir regresiones. Un proyecto que fija una versión funcional evita parte de esa variabilidad, pero también pierde correcciones posteriores de compatibilidad.
El software de seguridad de Windows genera otro riesgo práctico. La interceptación en tiempo de ejecución y la redirección de bibliotecas pueden parecerse a técnicas utilizadas por software malicioso.
Los usuarios deberían obtener binarios únicamente de versiones upstream identificadas y verificar los hashes. No deberían desactivar controles de seguridad amplios solo para forzar la ejecución de un paquete desconocido.
La verificación de hashes del repositorio resulta útil en este caso. Reduce la probabilidad de que una descarga modificada entre silenciosamente en el entorno de ejecución.
No audita el código upstream ni establece la seguridad de cada dependencia. Las organizaciones deberían aplicar sus procedimientos habituales de revisión de software y control de artefactos.
Las licencias también requieren un manejo cuidadoso. El repositorio incluye su propia licencia y avisos de terceros, mientras que ZLUDA utiliza licencias de código abierto.
CUDA sigue siendo una plataforma de NVIDIA con componentes propietarios y condiciones de licencia. Los usuarios deben entender qué archivos redistribuibles contiene su aplicación y qué descarga la configuración de compatibilidad.
El repositorio enfatiza una ruta basada únicamente en upstream público. Esa elección ayuda a separar el método actual de acuerdos experimentales anteriores que involucraban bibliotecas recuperadas o privadas.
Los equipos empresariales afrontan otro problema: la responsabilidad del soporte. AMD no ofrece soporte oficial para una receta comunitaria de compatibilidad con CUDA simplemente porque utilice el SDK de HIP.
NVIDIA no ofrece soporte para aplicaciones CUDA que se ejecuten en GPU AMD. El responsable del mantenimiento del proyecto no puede sustituir los compromisos de servicio de ninguno de los dos proveedores.
Esto hace que la configuración sea poco adecuada para cargas de trabajo que exigen tiempo de actividad garantizado sin una amplia cualificación interna. Sigue siendo más atractiva para laboratorios, aficionados y desarrolladores que prueban la portabilidad.
Los equipos que la evalúen deberían conservar informes de las máquinas, versiones exactas de paquetes, resultados de validación y registros de aplicaciones. Una base de conocimiento de ingeniería con capacidad de búsqueda puede mantener esos artefactos vinculados a cada prueba.
También deberían aislar las pruebas de los entornos de producción. Una máquina dedicada o una imagen desechable de Windows facilita la reversión cuando hay conflictos entre controladores o bibliotecas.
La pregunta central no es si se inicia una muestra. Es si la aplicación exacta produce resultados correctos y repetibles en el hardware requerido por el equipo.
Las capas de compatibilidad someten la ventaja de software de CUDA a una nueva prueba
El proyecto cuestiona en los márgenes la dependencia de las aplicaciones respecto a CUDA, al tiempo que refuerza lo difícil que sigue siendo lograr una compatibilidad completa.
La ventaja de NVIDIA incluye hardware, controladores, compiladores, herramientas de depuración, bibliotecas optimizadas, documentación y años de integración en aplicaciones. CUDA es la interfaz que conecta esas piezas.
Un proyecto de compatibilidad puede reproducir llamadas seleccionadas sin reproducir todo ese entorno de desarrollo. Esta diferencia explica por qué estos proyectos atraen atención antes de lograr una fiabilidad generalizada.
Para AMD, la compatibilidad ofrece una forma de llegar a aplicaciones que los proveedores no han portado. El soporte nativo de ROCm y HIP sigue siendo la ruta más limpia cuando los desarrolladores mantienen ambos backends.
Las dos estrategias pueden coexistir. La traducción sirve a binarios CUDA existentes, mientras que HIP respalda software diseñado o convertido para despliegues entre proveedores.
DirectML y otras interfaces de Windows ofrecen alternativas adicionales. Pueden proporcionar aceleración independiente del proveedor, pero las aplicaciones deben adoptarlas explícitamente.
OpenCL y SYCL también persiguen la portabilidad en distintos niveles. Su presencia no ha eliminado las bibliotecas específicas de CUDA ni los supuestos de las aplicaciones.
La discusión en Hacker News expuso esta tensión. Algunos comentaristas argumentaron que los estándares abiertos merecen más atención porque las interfaces cerradas restringen la elección de hardware.
Otros destacaron que las interfaces portables suelen ofrecer experiencias de desarrollo más débiles. Otra postura crítica sostuvo que la optimización específica para cada hardware impide que una capa genérica iguale a todos los proveedores.
Ambas posiciones describen limitaciones reales. Los desarrolladores quieren portabilidad, pero los kernels de alto rendimiento dependen de detalles de arquitectura y bibliotecas ajustadas.
ZLUDA elige la compatibilidad por encima de la pureza. Permite que la aplicación mantenga sus supuestos orientados a CUDA y traduce lo que puede.
Este enfoque reduce el trabajo inicial de migración. También conserva CUDA como el lenguaje que espera la aplicación, en lugar de sustituirlo por un estándar independiente.
Esta es la inversión central del proyecto. Ejecutar un programa orientado a CUDA en AMD puede debilitar la dependencia del hardware sin eliminar la dependencia del software respecto a CUDA.
Si más aplicaciones funcionan, CUDA podría actuar como una interfaz ampliamente utilizada cuyos binarios alcanzan varios backends. Ese resultado presionaría la exclusividad de hardware de NVIDIA.
Si la compatibilidad sigue siendo específica de cada carga de trabajo, los experimentos podrían demostrar en cambio la profundidad de la integración de software de NVIDIA. Cada biblioteca ausente se convierte en otra razón para que los desarrolladores permanezcan en hardware CUDA compatible.
El avance nativo de AMD en Windows cambia el cálculo. Mejores bibliotecas HIP y un soporte más amplio para PyTorch brindan una base más sólida a los proyectos de traducción.
También reducen la necesidad de traducción cuando las aplicaciones pueden adoptar paquetes oficiales de AMD. Es una forma saludable de solapamiento, no necesariamente un conflicto.
La señal competitiva importante será el comportamiento de las aplicaciones. Las matrices de soporte importan, pero los usuarios experimentan la compatibilidad mediante programas que se instalan, terminan su trabajo y devuelven resultados correctos.
Una lista de nombres de API traducidos no puede sustituir esa evidencia. Tampoco puede hacerlo un benchmark aislado sin una implementación nativa comparable.
Los informes futuros más valiosos describirán la versión de la aplicación, la GPU, el controlador, el SDK de HIP, la versión de ZLUDA, las bibliotecas utilizadas, las comprobaciones de salida y el rendimiento sostenido.
Los informes negativos serán igualmente importantes. Un fallo documentado identifica la función ausente o el supuesto incompatible que los responsables de mantenimiento deben abordar.
Esta evidencia también puede orientar a los proveedores de aplicaciones. Fallos repetidos en torno a una dependencia pueden justificar un backend HIP nativo u otra ruta de ejecución portátil.
Por ello, el repositorio importa incluso si nunca se convierte en un entorno de ejecución universal. Crea una superficie de prueba reproducible para medir dónde comienza y termina la dependencia de CUDA.
Tres señales determinarán lo que ocurra después
Los informes sobre más hardware, una cobertura de bibliotecas más profunda y resultados estables en aplicaciones decidirán si esto se convierte en una opción práctica para Windows.
La primera señal es la validación independiente en GPU Radeon adicionales. El resultado de la RX 9060 XT necesita replicarse en hardware RDNA3 y RDNA4 con soporte oficial.
Los informes exitosos deberían incluir versiones exactas y comprobaciones de salida. Una simple captura de pantalla o el nombre del dispositivo detectado no establecerán la compatibilidad de la carga de trabajo.
Varios resultados coherentes reforzarían la afirmación de que la configuración es portable entre los dispositivos Windows de AMD. Fallos frecuentes específicos de la arquitectura la limitarían a una configuración de referencia.
La segunda señal es la cobertura de cuDNN o de una alternativa equivalente para redes neuronales. Muchas aplicaciones de IA dependen de operaciones que la pila estable validada no proporciona actualmente a través de esta ruta.
El soporte podría llegar mediante una distribución HIP más reciente, mapeos adicionales de ZLUDA, cambios en las aplicaciones u otro puente de bibliotecas. Cada vía conlleva distintos costes de mantenimiento.
Las aplicaciones funcionales con uso intensivo de convoluciones ampliarían materialmente la relevancia del proyecto. Una ausencia continuada mantendría muchas cargas de trabajo de imágenes y modelos fuera de su alcance práctico.
La tercera señal es la estabilidad ante actualizaciones de aplicaciones y herramientas. El éxito actual depende de versiones fijadas de ZLUDA, HIP y LibTorch orientado a CUDA.
Los desarrolladores deberían observar si las versiones posteriores de ZLUDA conservan la prueba, si los paquetes HIP más recientes para Windows siguen siendo compatibles y si las aplicaciones más nuevas introducen llamadas no compatibles.
Un proyecto de compatibilidad gana valor cuando las actualizaciones no requieren redescubrir una combinación frágil. Las regresiones indicarían que el enfoque aún necesita un mantenimiento manual intensivo.
En esa evaluación, el rendimiento debería seguir a la corrección. Una aplicación traducida que ocasionalmente devuelve resultados erróneos tiene poco valor, independientemente de su rendimiento.
Después de verificar la corrección, las comparaciones deberían incluir una compilación HIP nativa cuando exista. También deberían utilizar ajustes equivalentes de la aplicación y el mismo hardware.
Las comparaciones con NVIDIA pueden responder a una pregunta de compra, pero no aíslan la sobrecarga de traducción. La arquitectura de GPU, la capacidad de memoria y las bibliotecas del proveedor pueden afectar al resultado.
El proyecto actual ya ha superado un umbral significativo. Convirtió una colección de componentes upstream en un procedimiento repetible para Windows y completó la carga de trabajo que lo motivó.
No ha superado el umbral que su título memorable sugiere. CUDA para AMD en Windows sigue siendo una promesa de compatibilidad vinculada a software específico y a una GPU validada.
Los desarrolladores interesados en probarlo deberían comenzar con las versiones documentadas del repositorio y los scripts de diagnóstico. Antes de instalar nada, deberían comprobar su GPU frente a la lista de compatibilidad actual de AMD.
A continuación, deberían elegir una carga de trabajo con un resultado de referencia conocido y correcto. Esa referencia importa más que si el programa detecta un dispositivo llamado CUDA.
Los equipos deberían registrar los fallos y publicar informes de compatibilidad reproducibles cuando sea posible. La evidencia compartida revelará si el puente admite una categoría de aplicaciones o solo ejemplos aislados.
La cuestión más amplia tiene ahora una forma medible: ¿cuánto software CUDA puede trasladarse a hardware AMD sin cambios en el código fuente, y qué se rompe primero?
Durante los próximos meses, habrá que seguir la matriz de compatibilidad, el progreso relacionado con cuDNN y los resultados de aplicaciones reales de Windows. Esas señales determinarán si CUDA para AMD en Windows se vuelve fiable o sigue siendo un experimento instructivo.
