AMD HIPRT 3.2 adiciona suporte às APUs Medusa e ao CUDA 13

A AMD publicou o HIPRT 3.2 em 21 de outubro de 2026, a primeira atualização da sua biblioteca de ray tracing para HIP desde janeiro. Ela adiciona três novos alvos de GPU que a Phoronix associa às futuras APUs Medusa da AMD, além de suporte ao CUDA 13. Também é uma versão com quebra de compatibilidade: apps compilados com a versão 3.1 precisam ser recompilados antes de rodar.

A versão está marcada como pre-release no GitHub, e o selo "Latest" ainda está na 3.1.0, lançada em 5 de janeiro de 2026.

O que é o HIPRT

O HIPRT é "uma biblioteca de ray tracing para HIP", segundo a página do GPUOpen da AMD. O HIP é a interface de programação em C++ da AMD para GPUs, a resposta da AMD ao CUDA da Nvidia. O ray tracing renderiza uma imagem seguindo raios de luz por uma cena 3D, e a parte lenta é descobrir qual objeto cada raio atinge.

Esse é o trabalho do HIPRT. Ele testa raios contra triângulos e formas personalizadas, e constrói BVHs, ou bounding volume hierarchies (hierarquias de volumes delimitadores). Uma BVH é uma árvore de caixas aninhadas ao redor da cena, o que permite que a GPU ignore a maioria dos objetos para cada raio. A biblioteca também lida com máscaras de raio, BVHs salvas e importadas, e motion blur.

A AMD a mantém pequena de propósito, para que um app HIP possa adotá-la sem aprender muitos tipos novos de kernel. Ela roda em GPUs da AMD e da Nvidia. O ray tracing acelerado por hardware exige uma GPU AMD RDNA 2 ou mais recente. A Phoronix diz que software multiplataforma "como o Blender" a usa.

O que há de novo no HIPRT 3.2

As notas de versão no GitHub listam as mudanças completas. As principais novidades:

Mudança	Detalhe
Novos alvos de GPU	gfx1170, gfx1171 e gfx115E, que a Phoronix identifica como APUs Medusa
CUDA 13	Melhorias de compatibilidade com o CUDA 13 da Nvidia
Shear em frames SRT	As transformações agora podem inclinar um objeto, e não apenas escalar, girar e mover
Getters de transformação	Quatro novas funções de código de dispositivo leem as transformações object-to-world e world-to-object de uma instância
Compiladores incluídos	As DLLs hipRTC e comgr passam de 6.4 para 7.1; agora o hipRTC 7.8 e mais recentes podem ser carregados
Busca do SDK	HIP e hipRTC são carregados primeiro a partir do SDK em HIP_PATH ou ROCM_PATH
Velocidade	As normais dos triângulos são decodificadas uma vez após a travessia, e as funções de transformação são desenroladas (unrolled)

Os nomes gfx são os códigos internos da AMD para designs de GPU. A Phoronix descreve a Medusa como a família Zen 6 de CPUs e APUs de cliente da AMD, chips que combinam uma CPU e uma GPU. As próprias notas no GitHub listam apenas os códigos gfx, não o nome Medusa.

A mudança na busca do SDK corrige um problema no Windows. Uma cópia do HIP distribuída com o driver gráfico podia sobrepor, ou ter prioridade sobre, o SDK que o desenvolvedor de fato instalou.

As mudanças incompatíveis para planejar

O HIPRT 3.2 eleva HIPRT_API_VERSION para 3002, e hiprtCreateContext rejeita binários compilados com a 3.1.x. Na prática, nada que foi compilado com a versão antiga continua funcionando.

• hiprtFrameSRT ganha um campo de shear e cresce de 48 para 64 bytes. Seu alinhamento sobe de 16 para 64 bytes.
• Os tipos de travessia e de pilha viram template aliases. Isso quebra as forward declarations e remove as constantes de tamanho e alinhamento.
• HIPRT_ASSERT é substituído por uma função hiprtAssert().
• hiprt::ptr() foi removido em favor de hiprt::component().
• A maioria das structs da API agora define valores padrão para seus membros.

Correções de bugs nesta versão

Várias correções tratam de corrupção de memória e travamentos:

• O refit, que atualiza uma BVH depois que objetos se movem, gravava vértices nas posições erradas e corrompia nós em GPUs gfx1201.
• Empacotar um triângulo sem par podia causar um acesso ilegal à memória.
• Comportamento indefinido no acesso a vetores podia permitir que o compilador descartasse gravações na memória.
• compactScenes copiava só metade de cada registro de instância.
• Em sistemas com várias GPUs, o compilador agora usa o contexto do HIPRT, e não o que estiver ativo no momento.
• Nomes de dispositivo com barras, como "AMD Instinct MI250X / MI250", não quebram mais o cache de kernels.
• Os códigos de GPU são interpretados como hexadecimal, então o gfx115E não é mais cortado.

O que isso significa para desenvolvedores

Mantenha a 3.1 em produção por enquanto. A versão 3.2 é um pre-release, então teste-a primeiro em um branch. Compare a saída de renderização com a da 3.1 nas mesmas cenas antes de trocar.

Planeje uma recompilação, não uma simples substituição. A verificação da versão da API falha na criação do contexto, então um binário antigo não vai seguir funcionando aos trancos com bugs estranhos. Ele vai se recusar a iniciar, e isso é mais fácil de detectar nos testes.

Verifique qualquer código que copie dados de transformação manualmente. Se o seu app empacota valores de hiprtFrameSRT em um buffer de GPU com um stride fixo de 48 bytes, esse layout agora está errado. Um tamanho de 64 bytes e um alinhamento de 64 bytes significam novos offsets e um buffer maior.

Procure no seu código os nomes removidos. HIPRT_ASSERT, hiprt::ptr() e forward declarations de tipos de travessia vão todos falhar na compilação. Corrigi-los é mecânico, mas um monorepo pode ter muitos pontos de chamada.

Atualize antes se você esbarrar em um dos bugs corrigidos. Equipes que veem refits de BVH corrompidos em gfx1201, ou erros hipErrorInvalidImage no Windows, têm motivo para testar a 3.2 cedo. As notas de versão dizem que o alvo de offload explícito mira esse erro em alguns toolchains.

Se você só usa o HIPRT por meio de um app como o Blender, não há nada a fazer. A mudança chega até você quando esse app atualizar a cópia que traz embutida.