AMD HIPRT 3.2 adds Medusa APU support and CUDA 13

AMD published HIPRT 3.2 on October 21, 2026, the first update to its ray tracing library for HIP since January. It adds three new GPU targets that Phoronix ties to AMD's upcoming Medusa APUs, plus CUDA 13 support. It is also a breaking release: apps built against version 3.1 must be recompiled before they will run.

The release is marked pre-release on GitHub, and the "Latest" badge still sits on 3.1.0, which shipped on January 5, 2026.

What HIPRT is

HIPRT is "a ray tracing library for HIP," according to AMD's GPUOpen page. HIP is AMD's C++ programming interface for GPUs, AMD's answer to Nvidia's CUDA. Ray tracing renders an image by following rays of light through a 3D scene, and the slow part is working out which object each ray hits.

That is the job HIPRT does. It tests rays against triangles and custom shapes, and it builds BVHs, or bounding volume hierarchies. A BVH is a tree of nested boxes around the scene, which lets the GPU skip most objects for each ray. The library also handles ray masks, saved and imported BVHs, and motion blur.

AMD keeps it small on purpose, so a HIP app can add it without learning many new kernel types. It runs on both AMD and Nvidia GPUs. Hardware-accelerated ray tracing needs an AMD RDNA 2 GPU or newer. Phoronix says cross-platform software "such as Blender" uses it.

What is new in HIPRT 3.2

The GitHub release notes list the changes in full. The main additions:

Change	Detail
New GPU targets	gfx1170, gfx1171 and gfx115E, which Phoronix identifies as Medusa APUs
CUDA 13	Compatibility improvements for Nvidia's CUDA 13
Shear on SRT frames	Transforms can now slant an object, not just scale, rotate and move it
Transform getters	Four new device-code functions read an instance's object-to-world and world-to-object transforms
Bundled compilers	hipRTC and comgr DLLs move from 6.4 to 7.1; hipRTC 7.8 and newer can now load
SDK lookup	HIP and hipRTC load from the SDK in HIP_PATH or ROCM_PATH first
Speed	Triangle normals are decoded once after traversal, and transform functions are unrolled

The gfx names are AMD's internal codes for GPU designs. Phoronix describes Medusa as AMD's Zen 6 family of client CPUs and APUs, chips that combine a CPU and a GPU. The GitHub notes themselves list only the gfx codes, not the Medusa name.

The SDK lookup change fixes a Windows problem. A copy of HIP shipped with the graphics driver could shadow, or take priority over, the SDK a developer actually installed.

The breaking changes to plan for

HIPRT 3.2 raises HIPRT_API_VERSION to 3002, and hiprtCreateContext rejects binaries built against 3.1.x. In practice, nothing compiled against the old version keeps working.

• hiprtFrameSRT gains a shear field and grows from 48 to 64 bytes. Its alignment rises from 16 to 64 bytes.
• Traversal and stack types become template aliases. That breaks forward declarations and removes the size and alignment constants.
• HIPRT_ASSERT is replaced by a hiprtAssert() function.
• hiprt::ptr() is removed in favor of hiprt::component().
• Most API structs now set default values for their members.

Bug fixes in this release

Several fixes address memory corruption and crashes:

• Refit, which updates a BVH after objects move, wrote vertices into the wrong slots and corrupted nodes on gfx1201 GPUs.
• Packing a triangle that has no pair could cause an illegal memory access.
• Undefined behavior in vector access could let the compiler drop memory writes.
• compactScenes copied only half of each instance record.
• On multi-GPU systems, the compiler now uses the HIPRT context rather than whichever one is current.
• Device names with slashes, such as "AMD Instinct MI250X / MI250," no longer break the kernel cache.
• GPU codes are parsed as hex, so gfx115E is no longer cut short.

What this means for developers

Keep 3.1 in production for now. Version 3.2 is a pre-release, so test it on a branch first. Check render output against 3.1 on the same scenes before you switch.

Budget for a rebuild, not a drop-in swap. The API version check fails at context creation, so an old binary will not limp along with odd bugs. It will refuse to start, and that is easier to catch in testing.

Check any code that copies transform data by hand. If your app packs hiprtFrameSRT values into a GPU buffer with a fixed 48-byte stride, that layout is now wrong. A 64-byte size and 64-byte alignment means new offsets and a bigger buffer.

Search your code for the removed names. HIPRT_ASSERT, hiprt::ptr() and forward declarations of traversal types will all fail to compile. Fixing them is mechanical, but a monorepo may have many call sites.

Upgrade sooner if you hit one of the fixed bugs. Teams seeing corrupted BVH refits on gfx1201, or hipErrorInvalidImage errors on Windows, have a reason to test 3.2 early. The release notes say the explicit offload target is aimed at that error on some toolchains.

If you only use HIPRT through an app such as Blender, there is nothing to do. The change reaches you when that app updates its bundled copy.