AMD HIPRT 3.2 prend en charge les APU Medusa et CUDA 13

AMD a publié HIPRT 3.2 le 21 octobre 2026, la première mise à jour de sa bibliothèque de ray tracing pour HIP depuis janvier. Elle ajoute trois nouvelles cibles GPU que Phoronix associe aux futurs APU Medusa d'AMD, ainsi que la prise en charge de CUDA 13. C'est aussi une version qui casse la compatibilité : les applications compilées avec la version 3.1 doivent être recompilées avant de pouvoir fonctionner.

La version est marquée comme pré-version sur GitHub, et le badge « Latest » reste sur la 3.1.0, sortie le 5 janvier 2026.

Ce qu'est HIPRT

HIPRT est « une bibliothèque de ray tracing pour HIP », selon la page GPUOpen d'AMD. HIP est l'interface de programmation C++ d'AMD pour les GPU, la réponse d'AMD au CUDA de Nvidia. Le ray tracing produit une image en suivant des rayons de lumière à travers une scène 3D, et l'étape lente consiste à déterminer quel objet chaque rayon touche.

C'est précisément le travail de HIPRT. Il teste les rayons contre des triangles et des formes personnalisées, et il construit des BVH, ou hiérarchies de volumes englobants. Un BVH est un arbre de boîtes imbriquées autour de la scène, qui permet au GPU d'ignorer la plupart des objets pour chaque rayon. La bibliothèque gère aussi les masques de rayons, les BVH sauvegardés et importés, et le flou de mouvement.

AMD la garde volontairement petite, pour qu'une application HIP puisse l'intégrer sans apprendre de nombreux nouveaux types de kernels. Elle fonctionne sur les GPU AMD comme sur les GPU Nvidia. Le ray tracing accéléré par le matériel nécessite un GPU AMD RDNA 2 ou plus récent. Phoronix indique que des logiciels multiplateformes « comme Blender » l'utilisent.

Les nouveautés de HIPRT 3.2

Les notes de version sur GitHub détaillent l'ensemble des changements. Les principaux ajouts :

Changement	Détail
Nouvelles cibles GPU	gfx1170, gfx1171 et gfx115E, que Phoronix identifie comme des APU Medusa
CUDA 13	Améliorations de compatibilité avec CUDA 13 de Nvidia
Cisaillement sur les frames SRT	Les transformations peuvent désormais incliner un objet, et pas seulement le mettre à l'échelle, le faire pivoter et le déplacer
Accesseurs de transformations	Quatre nouvelles fonctions de code device lisent les transformations objet-vers-monde et monde-vers-objet d'une instance
Compilateurs fournis	Les DLL hipRTC et comgr passent de 6.4 à 7.1 ; hipRTC 7.8 et les versions ultérieures peuvent désormais être chargés
Recherche du SDK	HIP et hipRTC sont chargés en priorité depuis le SDK indiqué par HIP_PATH ou ROCM_PATH
Vitesse	Les normales des triangles sont décodées une seule fois après le parcours, et les fonctions de transformation sont déroulées

Les noms gfx sont les codes internes d'AMD pour ses conceptions de GPU. Phoronix décrit Medusa comme la famille Zen 6 de CPU et d'APU pour postes clients d'AMD, des puces qui combinent un CPU et un GPU. Les notes GitHub elles-mêmes ne mentionnent que les codes gfx, pas le nom Medusa.

Le changement de recherche du SDK corrige un problème sous Windows. Une copie de HIP livrée avec le pilote graphique pouvait masquer, c'est-à-dire prendre le pas sur, le SDK que le développeur avait réellement installé.

Les changements incompatibles à prévoir

HIPRT 3.2 fait passer HIPRT_API_VERSION à 3002, et hiprtCreateContext rejette les binaires compilés avec la 3.1.x. En pratique, rien de ce qui a été compilé avec l'ancienne version ne continue de fonctionner.

• hiprtFrameSRT gagne un champ de cisaillement et passe de 48 à 64 octets. Son alignement passe de 16 à 64 octets.
• Les types de parcours et de pile deviennent des alias de templates. Cela casse les déclarations anticipées et supprime les constantes de taille et d'alignement.
• HIPRT_ASSERT est remplacé par une fonction hiprtAssert().
• hiprt::ptr() est supprimé au profit de hiprt::component().
• La plupart des structs de l'API définissent désormais des valeurs par défaut pour leurs membres.

Les corrections de bugs de cette version

Plusieurs corrections visent des corruptions de mémoire et des plantages :

• Le refit, qui met à jour un BVH après le déplacement d'objets, écrivait des sommets aux mauvais emplacements et corrompait des nœuds sur les GPU gfx1201.
• L'empaquetage d'un triangle sans paire pouvait provoquer un accès mémoire illégal.
• Un comportement indéfini dans l'accès aux vecteurs pouvait permettre au compilateur de supprimer des écritures en mémoire.
• compactScenes ne copiait que la moitié de chaque enregistrement d'instance.
• Sur les systèmes multi-GPU, le compilateur utilise désormais le contexte HIPRT plutôt que le contexte actif, quel qu'il soit.
• Les noms de périphériques contenant des barres obliques, comme « AMD Instinct MI250X / MI250 », ne cassent plus le cache des kernels.
• Les codes GPU sont analysés en hexadécimal, si bien que gfx115E n'est plus tronqué.

Ce que cela signifie pour les développeurs

Gardez la 3.1 en production pour l'instant. La version 3.2 est une pré-version, donc testez-la d'abord sur une branche. Comparez le rendu avec celui de la 3.1 sur les mêmes scènes avant de basculer.

Prévoyez une recompilation, pas un simple remplacement. La vérification de version de l'API échoue à la création du contexte, donc un ancien binaire ne continuera pas tant bien que mal avec des bugs étranges. Il refusera de démarrer, ce qui est plus facile à repérer lors des tests.

Vérifiez tout code qui copie les données de transformation à la main. Si votre application range des valeurs hiprtFrameSRT dans un tampon GPU avec un pas fixe de 48 octets, cette disposition est désormais fausse. Une taille de 64 octets et un alignement de 64 octets impliquent de nouveaux décalages et un tampon plus grand.

Cherchez les noms supprimés dans votre code. HIPRT_ASSERT, hiprt::ptr() et les déclarations anticipées des types de parcours ne compileront plus. Les corriger est mécanique, mais un monorepo peut compter de nombreux points d'appel.

Passez plus tôt à la nouvelle version si vous êtes touché par l'un des bugs corrigés. Les équipes qui constatent des refits de BVH corrompus sur gfx1201, ou des erreurs hipErrorInvalidImage sous Windows, ont une raison de tester la 3.2 tôt. Selon les notes de version, la cible d'offload explicite vise cette erreur sur certaines chaînes d'outils.

Si vous n'utilisez HIPRT qu'à travers une application comme Blender, vous n'avez rien à faire. Le changement vous parviendra quand cette application mettra à jour sa copie intégrée.