AMD Talks Up The Great Opportunities Of SPIR-V IR With ROCm

While AMD ROCm 7.14 released last week as the first production release built off TheRock, there is already more to look forward to moving into the future with the AMD ROCm stack... In particular, SPIR-V with ROCm becoming a reality for unified binaries that can work across graphics architectures/targets, better portability across GPU hardware, and other improvements to the experience in targeting a unified IR. SPIR-V is the intermediate representation typically associated with Vulkan API drivers but also supported by other Khronos APIs like OpenGL and OpenCL too. AMD ROCm has been working toward a model for supporting the SPIR-V IR on ROCm to reduce having to build per-GPU targets and allowing for a more unified experience. But at the cost of higher first-launch JIT latency when there is first kernel invocation for a given GPU device/target and needing to workaround code with compile-time architecture-specific bits. This SPIR-V with ROCm has been a long time coming, as part of their MLIR play too. The topic has been covered many times on Phoronix in the past few years in seeing this trend coming about in moving toward supporting SPIR-V in ROCm... AMD Unified AI Software Stack Has The Potential To Be A Very Big Deal, AMD ROCm 6.4 Adds SPIR-V Linking Support To HIP, AMD Lands Support For Vendor Flavored SPIR-V Within LLVM, AMD Engineer Talks Up Vulkan/SPIR-V As Part Of Their MLIR-Based Unified AI Software Play, and more within various Phoronix articles. AMD put out a blog post today outlining the current level of SPIR-V support in ROCm and what's ahead. ROCm 7.2 and later is already in place with base support with functionality like the AMD GCN SPIR-V target in LLVM/Clang, the SPIRV-LLVM Translator path being production grade today, and per-process JIT caching. Still ahead though is getting the in-tree LLVM SPIR-V back-end to replace the translator as the default lowering path. JIT-at-package-level-install is also still being worked through as well as improving the debug experience in the SPIR-V AMDGCN JIT path. SPIR-V builds for per-arch device libraries also needs to be solved. The outlook is exciting with one AMD ROCm binary that would "just work" for many GPUs, a flat build time and binary size, "free" forward compatibility, fast performance, and broad library coverage. This SPIR-V on ROCm stack is already working out as a proof of success for PyTorch. More details on the SPIR-V on ROCm stack via this blog post published today. Hopefully we'll hear more about their SPIR-V activities later this week at the AMD Advancing AI event in California.