AMD hat HIPRT 3.2 veröffentlicht, eine Aktualisierung seiner Raytracing-Bibliothek für Anwendungen, die mit HIP entwickelt wurden. Die Liste der Änderungen umfasst Unterstützung für die Architekturen, die als gfx1170, gfx1171 und gfx115E identifiziert wurden, zusammengefasst in den Release-Notes unter dem Namen Medusa. Außerdem wurden Funktionen eingeführt, mit denen Transformationen aus dem Code abgefragt werden können, der auf der GPU ausgeführt wird.
Die Veröffentlichung wird ausdrücklich als „pre-release“ bezeichnet. Es handelt sich um eine Bibliothek für Entwickler, nicht um einen neuen Radeon-Treiber noch eine Funktion, die eigenständig in installierten Spielen erscheint. Ihre Wirkung hängt davon ab, ob Programme sie übernehmen, sie gegebenenfalls neu kompilieren und die von HIPRT bereitgestellten Raytracing-Pfade verwenden.
Die Medusa-Bezeichner erscheinen in der offiziellen Liste
Die Aufnahme von gfx1170, gfx1171 und gfx115E bestätigt, dass AMD die Bibliothek darauf vorbereitet hat, diese Grafikziele zu erkennen. Die Notizen gruppieren sie als Unterstützung für Medusa, einem Namen, der mit einer zukünftigen APU-Familie verbunden ist. Diese Kompatibilitätsliste offenbart keine kommerziellen Spezifikationen: sie gibt nicht an, wie viele Recheneinheiten die Chips besitzen, welche Systeme sie verwenden werden oder wann sie vorgestellt werden.
Die Aktualisierung ändert auch die Art und Weise, wie Architekturkennungen interpretiert werden. Ab sofort werden sie hexadezimal analysiert, damit Bezeichner mit Buchstaben, wie gfx115E, nicht abgeschnitten werden. Es ist eine scheinbar kleine technische Korrektur, aber notwendig, damit die Auswahl des Codes, der jeder GPU zugeordnet wird, nicht aufgrund der Gerätenomenklatur fehlschlägt.
HIPRT ermöglicht das Erstellen und Durchlaufen von Beschleunigungsstrukturen, die im Raytracing verwendet werden. In dieser Version werden Funktionen hinzugefügt, um Transformations an Instanzen in beiden Richtungen abzurufen, vom Objekt- in den Weltkoordinatenraum und vom Welt- in den Objektkoordinatenraum. Es gibt Varianten sowohl für zweistufige Szenen als auch für mehrstufige Strukturen. Entwickler können diese Daten aus dem Code abfragen, der auf dem Gerät ausgeführt wird.
Diese Abfrage der Transformationen erleichtert es, Geometrie und Strahlen konsistent zu halten, wenn eine Instanz ihre Position oder Orientierung ändert. Die Ergänzung wirkt sich auf die verfügbaren Werkzeuge zur Programmierung von Szenen aus; sie bedeutet nicht, dass ein bereits veröffentlichtes Spiel automatisch visuelle Qualitätsverbesserungen erhält. Jede Anwendung muss die neuen Aufrufe dort integrieren, wo sie sinnvoll sind.
Neue Transformationen und Änderungen, die eine Rekompilierung erforderlich machen
Die SRT-Strukturen beinhalten ein Scherkraftfeld zwischen Skalierung und Translation. Diese Änderung verändert die Größe von hiprtFrameSRT, von 48 auf 64 Bytes, sowie deren Ausrichtung, von 16 auf 64 Bytes. Der Hinweis warnt, dass bestehende Anwendungen neu kompiliert werden müssen. Ein Programm, das gegen HIPRT 3.1 kompiliert wurde, kann diese Struktur nicht mehr so behandeln, als behielte es die bisherige Ordnung.
Um eine stille Inkompatibilität zu vermeiden, wird HIPRT_API_VERSION auf 3002 erhöht. Falls ein früheres Binary versucht, einen Kontext mit der neuen Bibliothek zu erstellen, gibt hiprtCreateContext hiprtErrorInvalidApiVersion zurück. Die Aktualisierung ändert außerdem die öffentliche Repräsentation von Traversal- und Stack-Typen, die fortan als Template-Alias-Typen bezeichnet werden. Die Namen bleiben zwar erhalten, aber einige Forward-Declarations funktionieren nicht mehr und die exponierten Größen- und Align-Konstanten verschwinden.
CUDA 13, Leistung und Fehlerbehebungen
HIPRT 3.2 unterstützt CUDA 13 und aktualisiert die enthaltenen Bibliotheken von hipRTC und comgr. Die Suche nach HIP-Bibliotheken priorisiert das SDK, das durch HIP_PATH oder ROCM_PATH angegeben wird, sofern diese Variablen definiert sind. Unter Windows verhindert dies, dass eine Kopie, die sich im System32-Verzeichnis befindet, vor der vom Programmierer verwendeten SDK-Version geladen wird. Wenn diese Routen nicht definiert sind, bleibt die Suchreihenfolge unverändert.
Die Hinweise weisen auf zwei Leistungseinstellungen hin: Die Normalen der Dreiecke werden nach der Traversierung einmal dekodiert, statt für jeden möglichen Schnittpunkt separat, und die Transformationsfunktionen werden während der Kompilierung bereitgestellt.
Zu den Korrekturen gehört ein unbefugter Speicherzugriff beim Packen bestimmter Dreiecks-Paare, Fehler beim Aktualisieren von BVH-Strukturen in gfx1201 und beschädigte Daten beim Kompaktmachen von Szenen. Ebenso wird die Initialisierung des Compilers in Konfigurationen mit mehreren GPUs behoben und die Behandlung von Gerätenamen mit Pfad-Trennzeichen verbessert. Es handelt sich um verschiedene Probleme, die Stabilität und Strukturengenerierung betreffen, nicht um eine einzige Änderung des Raytracing-Algorithmus.
Das Build-System erfährt außerdem Änderungen für CMake-Generatoren mit mehreren Konfigurationen. Die Skripte deklarieren besser ihre Ausgabedateien, damit ein Kernel neu generiert wird, falls einer fehlt, und Python wird nur benötigt, wenn wirklich diese Kernel kompiliert werden. Es handelt sich um Anpassungen für diejenigen, die HIPRT in größere Projekte integrieren und sicherstellen müssen, dass Builds auf unterschiedlichen Maschinen dasselbe Ergebnis liefern.
Die Veröffentlichung folgt auf HIPRT 3.1, datiert auf den 5. Januar 2026, und fasst etwa neun Monate Arbeit zusammen. Derzeit präsentiert das Repository HIPRT 3.2 als Vorabversion. AMD hat diese Kennzeichnung weder mit einem stabilen Radeon Software-Update verknüpft noch Medusa-Produkte darauf basierend angekündigt.
