Zum Inhalt springen

AMD HIPRT 3.2 bringt Unterstützung für Medusa-APUs und CUDA 13

HIPRT 3.2, AMDs Raytracing-Bibliothek für HIP, bringt drei Medusa-APU-Ziele und CUDA 13. Apps, die gegen 3.1 gebaut wurden, müssen aber neu kompiliert werden.

Von Tech AI Wire Team

4 Min. Lesezeit

XLinkedIn
Eine AMD-Radeon-Grafikkarte auf einem sonnigen Schreibtisch vor einem Monitor, der eine per Raytracing gerenderte Szene mit Chrom- und Glaskugeln zeigt.

AMD hat HIPRT 3.2 am 21. Oktober 2026 veröffentlicht, das erste Update seiner Raytracing-Bibliothek für HIP seit Januar. Es bringt drei neue GPU-Ziele, die Phoronix mit AMDs kommenden Medusa-APUs in Verbindung bringt, dazu Unterstützung für CUDA 13. Es ist außerdem ein Release mit Breaking Changes: Apps, die gegen Version 3.1 gebaut wurden, müssen neu kompiliert werden, bevor sie laufen.

Das Release ist auf GitHub als Pre-Release markiert, und das Abzeichen "Latest" hängt weiterhin an 3.1.0, das am 5. Januar 2026 erschien.

Was HIPRT ist

HIPRT ist laut AMDs GPUOpen-Seite "eine Raytracing-Bibliothek für HIP". HIP ist AMDs C++-Programmierschnittstelle für GPUs, AMDs Antwort auf Nvidias CUDA. Raytracing erzeugt ein Bild, indem es Lichtstrahlen durch eine 3D-Szene verfolgt, und der langsame Teil ist die Berechnung, welches Objekt jeder Strahl trifft.

Genau diese Aufgabe übernimmt HIPRT. Die Bibliothek testet Strahlen gegen Dreiecke und eigene Formen, und sie baut BVHs, also Bounding Volume Hierarchies. Ein BVH ist ein Baum aus verschachtelten Boxen um die Szene, mit dem die GPU für jeden Strahl die meisten Objekte überspringen kann. Die Bibliothek unterstützt außerdem Strahlmasken, gespeicherte und importierte BVHs sowie Bewegungsunschärfe.

AMD hält sie bewusst klein, damit eine HIP-App sie einbinden kann, ohne viele neue Kernel-Typen lernen zu müssen. Sie läuft auf GPUs von AMD und Nvidia. Hardwarebeschleunigtes Raytracing erfordert eine AMD-GPU mit RDNA 2 oder neuer. Laut Phoronix nutzt plattformübergreifende Software "wie Blender" die Bibliothek.

Was in HIPRT 3.2 neu ist

Die Release Notes auf GitHub führen die Änderungen vollständig auf. Die wichtigsten Neuerungen:

ÄnderungDetail
Neue GPU-Zielegfx1170, gfx1171 und gfx115E, die Phoronix als Medusa-APUs identifiziert
CUDA 13Verbesserte Kompatibilität mit Nvidias CUDA 13
Scherung bei SRT-FramesTransformationen können ein Objekt jetzt auch schräg stellen, nicht nur skalieren, drehen und verschieben
Transform-GetterVier neue Funktionen im Device-Code lesen die Object-to-World- und World-to-Object-Transformationen einer Instanz
Mitgelieferte CompilerDie DLLs von hipRTC und comgr steigen von 6.4 auf 7.1; hipRTC 7.8 und neuer lässt sich jetzt laden
SDK-SucheHIP und hipRTC werden zuerst aus dem SDK in HIP_PATH oder ROCM_PATH geladen
GeschwindigkeitDreiecksnormalen werden nach der Traversierung einmal dekodiert, und Transform-Funktionen werden ausgerollt

Die gfx-Namen sind AMDs interne Codes für GPU-Designs. Phoronix beschreibt Medusa als AMDs Zen-6-Familie von Client-CPUs und APUs, also Chips, die eine CPU und eine GPU vereinen. Die GitHub-Notizen selbst nennen nur die gfx-Codes, nicht den Namen Medusa.

Die Änderung bei der SDK-Suche behebt ein Problem unter Windows. Eine mit dem Grafiktreiber ausgelieferte Kopie von HIP konnte das SDK überdecken, das ein Entwickler tatsächlich installiert hatte, also Vorrang davor erhalten.

Die Breaking Changes, die Sie einplanen sollten

HIPRT 3.2 hebt HIPRT_API_VERSION auf 3002 an, und hiprtCreateContext weist Binärdateien zurück, die gegen 3.1.x gebaut wurden. In der Praxis funktioniert nichts mehr, was gegen die alte Version kompiliert wurde.

  • hiprtFrameSRT erhält ein Feld für die Scherung und wächst von 48 auf 64 Bytes. Seine Ausrichtung steigt von 16 auf 64 Bytes.
  • Traversierungs- und Stack-Typen werden zu Template-Aliasen. Das bricht Vorwärtsdeklarationen und entfernt die Konstanten für Größe und Ausrichtung.
  • HIPRT_ASSERT wird durch eine Funktion hiprtAssert() ersetzt.
  • hiprt::ptr() entfällt zugunsten von hiprt::component().
  • Die meisten API-Structs setzen jetzt Standardwerte für ihre Member.

Fehlerkorrekturen in diesem Release

Mehrere Korrekturen betreffen Speicherbeschädigung und Abstürze:

  • Refit, das ein BVH aktualisiert, nachdem sich Objekte bewegt haben, schrieb Vertices in die falschen Slots und beschädigte Knoten auf GPUs mit gfx1201.
  • Das Packen eines Dreiecks ohne Partner konnte einen unzulässigen Speicherzugriff auslösen.
  • Undefiniertes Verhalten beim Vektorzugriff konnte dazu führen, dass der Compiler Schreibzugriffe auf den Speicher verwirft.
  • compactScenes kopierte nur die Hälfte jedes Instanz-Datensatzes.
  • Auf Systemen mit mehreren GPUs nutzt der Compiler jetzt den HIPRT-Kontext statt des jeweils aktuellen.
  • Gerätenamen mit Schrägstrichen, etwa "AMD Instinct MI250X / MI250", führen nicht mehr zu Fehlern im Kernel-Cache.
  • GPU-Codes werden als Hexadezimalzahlen eingelesen, sodass gfx115E nicht mehr abgeschnitten wird.

Was das für Entwickler bedeutet

Bleiben Sie in der Produktion vorerst bei 3.1. Version 3.2 ist ein Pre-Release, testen Sie es also zuerst auf einem Branch. Vergleichen Sie die Render-Ausgabe auf denselben Szenen mit 3.1, bevor Sie wechseln.

Planen Sie eine Neukompilierung ein, keinen Drop-in-Austausch. Die Prüfung der API-Version schlägt beim Erstellen des Kontexts fehl, ein altes Binary läuft also nicht mit seltsamen Fehlern weiter. Es verweigert den Start, und das lässt sich beim Testen leichter erkennen.

Prüfen Sie jeden Code, der Transformationsdaten von Hand kopiert. Wenn Ihre App hiprtFrameSRT-Werte mit einem festen Abstand von 48 Bytes in einen GPU-Puffer packt, ist dieses Layout jetzt falsch. Eine Größe von 64 Bytes und eine Ausrichtung von 64 Bytes bedeuten neue Offsets und einen größeren Puffer.

Durchsuchen Sie Ihren Code nach den entfernten Namen. HIPRT_ASSERT, hiprt::ptr() und Vorwärtsdeklarationen von Traversierungstypen lassen sich alle nicht mehr kompilieren. Sie zu beheben ist mechanische Arbeit, aber in einem Monorepo kann es viele Aufrufstellen geben.

Aktualisieren Sie früher, wenn Sie auf einen der behobenen Fehler stoßen. Teams, die beschädigte BVH-Refits auf gfx1201 oder Fehler vom Typ hipErrorInvalidImage unter Windows sehen, haben einen Grund, 3.2 früh zu testen. Laut den Release Notes richtet sich das explizite Offload-Target bei einigen Toolchains gegen genau diesen Fehler.

Wenn Sie HIPRT nur über eine App wie Blender nutzen, müssen Sie nichts tun. Die Änderung erreicht Sie, wenn diese App ihre mitgelieferte Kopie aktualisiert.

Quellen

  1. HIPRT 3.2.0.ceba893 release notes - GitHub (AMD GPUOpen)
  2. AMD HIPRT 3.2 Released With Medusa APU Support - Phoronix
  3. HIP RT - AMD GPUOpen

Ähnliche Artikel