AMD HIPRT 3.2 añade compatibilidad con las APU Medusa y CUDA 13

AMD publicó HIPRT 3.2 el 21 de octubre de 2026, la primera actualización desde enero de su biblioteca de trazado de rayos para HIP. Añade tres nuevos objetivos de GPU que Phoronix vincula a las próximas APU Medusa de AMD, además de compatibilidad con CUDA 13. También es una versión con cambios incompatibles: las aplicaciones compiladas con la versión 3.1 deben recompilarse antes de poder ejecutarse.

La versión está marcada como pre-release en GitHub, y la etiqueta "Latest" sigue en 3.1.0, que salió el 5 de enero de 2026.

Qué es HIPRT

HIPRT es "una biblioteca de trazado de rayos para HIP", según la página de GPUOpen de AMD. HIP es la interfaz de programación en C++ de AMD para GPU, la respuesta de AMD a CUDA de Nvidia. El trazado de rayos genera una imagen siguiendo rayos de luz a través de una escena 3D, y la parte lenta es averiguar con qué objeto choca cada rayo.

Ese es el trabajo que hace HIPRT. Comprueba los rayos contra triángulos y formas personalizadas, y construye BVH, o jerarquías de volúmenes envolventes. Un BVH es un árbol de cajas anidadas alrededor de la escena, que permite a la GPU saltarse la mayoría de los objetos para cada rayo. La biblioteca también gestiona máscaras de rayos, BVH guardados e importados, y desenfoque de movimiento.

AMD la mantiene pequeña a propósito, para que una aplicación HIP pueda añadirla sin aprender muchos tipos nuevos de kernel. Funciona tanto en GPU de AMD como de Nvidia. El trazado de rayos acelerado por hardware necesita una GPU AMD RDNA 2 o posterior. Phoronix dice que lo usa software multiplataforma "como Blender".

Novedades de HIPRT 3.2

Las notas de la versión en GitHub enumeran todos los cambios. Las principales novedades:

Cambio	Detalle
Nuevos objetivos de GPU	gfx1170, gfx1171 y gfx115E, que Phoronix identifica como APU Medusa
CUDA 13	Mejoras de compatibilidad con CUDA 13 de Nvidia
Cizallamiento en marcos SRT	Las transformaciones ahora pueden inclinar un objeto, no solo escalarlo, rotarlo y moverlo
Getters de transformaciones	Cuatro nuevas funciones de código de dispositivo leen las transformaciones objeto-mundo y mundo-objeto de una instancia
Compiladores incluidos	Las DLL de hipRTC y comgr pasan de 6.4 a 7.1; ahora pueden cargarse hipRTC 7.8 y posteriores
Búsqueda del SDK	HIP y hipRTC se cargan primero desde el SDK en HIP_PATH o ROCM_PATH
Velocidad	Las normales de los triángulos se decodifican una sola vez tras el recorrido, y las funciones de transformación se desenrollan

Los nombres gfx son los códigos internos de AMD para sus diseños de GPU. Phoronix describe Medusa como la familia Zen 6 de CPU y APU de AMD para equipos cliente, chips que combinan una CPU y una GPU. Las propias notas de GitHub solo enumeran los códigos gfx, no el nombre Medusa.

El cambio en la búsqueda del SDK corrige un problema de Windows. Una copia de HIP incluida con el controlador gráfico podía ocultar, es decir, tener prioridad sobre, el SDK que un desarrollador había instalado realmente.

Los cambios incompatibles que hay que planificar

HIPRT 3.2 sube HIPRT_API_VERSION a 3002, y hiprtCreateContext rechaza los binarios compilados con 3.1.x. En la práctica, nada compilado con la versión antigua sigue funcionando.

• hiprtFrameSRT gana un campo de cizallamiento y crece de 48 a 64 bytes. Su alineación sube de 16 a 64 bytes.
• Los tipos de recorrido y de pila pasan a ser alias de plantilla. Eso rompe las declaraciones adelantadas y elimina las constantes de tamaño y alineación.
• HIPRT_ASSERT se sustituye por una función hiprtAssert().
• hiprt::ptr() se elimina en favor de hiprt::component().
• La mayoría de los structs de la API ahora fijan valores predeterminados para sus miembros.

Correcciones de errores en esta versión

Varias correcciones abordan corrupción de memoria y bloqueos:

• Refit, que actualiza un BVH después de que se muevan los objetos, escribía vértices en las posiciones equivocadas y corrompía nodos en las GPU gfx1201.
• Empaquetar un triángulo sin pareja podía provocar un acceso ilegal a memoria.
• Un comportamiento indefinido en el acceso a vectores podía permitir que el compilador descartara escrituras en memoria.
• compactScenes copiaba solo la mitad de cada registro de instancia.
• En sistemas con varias GPU, el compilador ahora usa el contexto de HIPRT en lugar del que esté activo en ese momento.
• Los nombres de dispositivo con barras, como "AMD Instinct MI250X / MI250", ya no rompen la caché de kernels.
• Los códigos de GPU se interpretan como hexadecimales, así que gfx115E ya no se corta.

Qué significa para los desarrolladores

Mantén 3.1 en producción por ahora. La versión 3.2 es una pre-release, así que pruébala primero en una rama. Compara el resultado del renderizado con 3.1 en las mismas escenas antes de cambiar.

Prevé una recompilación, no un simple reemplazo. La comprobación de la versión de la API falla al crear el contexto, así que un binario antiguo no seguirá funcionando a duras penas con errores raros. Se negará a arrancar, y eso es más fácil de detectar en las pruebas.

Revisa cualquier código que copie datos de transformación a mano. Si tu aplicación empaqueta valores de hiprtFrameSRT en un búfer de GPU con un paso fijo de 48 bytes, esa disposición ahora es incorrecta. Un tamaño de 64 bytes y una alineación de 64 bytes implican nuevos desplazamientos y un búfer más grande.

Busca en tu código los nombres eliminados. HIPRT_ASSERT, hiprt::ptr() y las declaraciones adelantadas de los tipos de recorrido dejarán de compilar. Corregirlos es mecánico, pero un monorepo puede tener muchos puntos de llamada.

Actualiza antes si te topas con uno de los errores corregidos. Los equipos que vean refits de BVH corruptos en gfx1201, o errores hipErrorInvalidImage en Windows, tienen un motivo para probar 3.2 pronto. Las notas de la versión dicen que el objetivo de offload explícito apunta a ese error en algunas toolchains.

Si solo usas HIPRT a través de una aplicación como Blender, no tienes que hacer nada. El cambio te llegará cuando esa aplicación actualice su copia incluida.