From CUDA® to AMD ROCm™ Software Without Starting Over

Why Portability Matters More Than Ever

For years, CUDA® came with an unspoken assumption: if you wrote in CUDA, you were also choosing where it would run.

That model made sense when the GPU was the center of the system and everything else adapted around it. The software and hardware choice were effectively the same decision. But many embedded systems are no longer being built this way.

Today, the GPU is no longer the whole story. The CPU matters. The NPU matters. Networking, memory behavior, display pipelines, power, footprint, and lifecycle all matter. In this environment, the right hardware choice is no longer simply the one with the most familiar GPU stack. It’s the one that fits the entire system. AMD built AMD Ryzen™ AI Embedded P100 and AMD Ryzen AI Embedded X100 Series processors specifically around this reality, combining “Zen 5” CPU cores, AMD RDNA™ 3.5 graphics, and AMD XDNA™ 2 NPU acceleration on a single device.

This shift changes the fundamental starting point of new designs in a very practical way:

Do you want your software tied to one GPU stack, or the freedom to architect your design around the platform that makes the most sense for your product?

This is why portability matters now in a way it did not before.

It’s not about starting over or rewriting everything you have built. It’s about making sure the software investment you have already made does not lock you into a system architecture that may no longer be the best fit.

Why this matters even if CUDA already works

If CUDA is working for you today, the obvious reaction is: why change?  The answer is not that CUDA suddenly stopped being useful. The answer is that application and performance requirements are also shifting.

If every future product you develop will be built around NVIDIA® system-on-modules, with the rest of the system architected around that choice, the current model may still be fine. But many modern systems are moving in a different direction. They are more integrated, more power-constrained, more cost-sensitive, and more dependent on CPU, GPU, and NPU resources working together.

This is exactly where portability starts to matter. When your software is portable, you are no longer forced to choose the most familiar GPU. You get to choose the platform that best fits the full system.

What portability actually means

At a technical level, the problem is straightforward. CUDA binaries are NVIDIA-specific. AMD GPUs employ different instruction sets and binary formats, so code compiled for NVIDIA does not simply move across unchanged. That is exactly why Heterogeneous-Compute Interface for Portability (HIP) exists. AMD designed HIP as a C++ runtime API and kernel language closely aligned with CUDA that gives you a practical way to move existing CUDA applications to AMD platforms. Part of the AMD ROCm™ software solution, HIP is a CUDA-like environment for portable GPU development, and HIPIFY is the toolset for automatically translating CUDA code into portable HIP C++.

The important part is what this means to you. You do not need to choose between staying in CUDA forever and rewriting your code from scratch. You can take what you already have, make it portable, and preserve a single source base that can target both CUDA and the AMD ROCm platform backends. That is the core promise behind HIP portability.

Portability is not a leap. It is a workflow.

What that workflow looks like in real code

The easiest way to understand why this works is to look at how little the programming model actually changes.

If you are used to writing CUDA with managed memory, this pattern is already familiar:

And here is the same thing after porting to HIP:

That's the whole change: a CUDA → HIP rename that HIPIFY does for you. The kernel is untouched, the structure is untouched, and most importantly for an embedded design, there is no host-to-device copy anywhere, because with unified memory, there's nothing to copy across.

This is also where an integrated platform quietly removes GPU inefficiencies. If you're porting older CUDA code that uses the classic cudaMalloc + cudaMemcpy pattern, HIPIFY converts those calls one-to-one and the code runs correctly, but on AMD Ryzen AI Embedded platforms you may not need them. The explicit copy functions exist to move data across PCIe® to a separate memory domain; with the CPU and iGPU sharing DRAM, you can drop the staging buffers and the transfers entirely. The result is less code, lower latency, and a smaller memory footprint, exactly the kind of system-level simplification that matters on power- and cost-constrained edge designs.

The takeaway is twofold. For many common runtime patterns, migration can start as a rename—not a rewrite. And on AMD Ryzen AI Embedded platforms, the idiomatic version of your code can be simpler than the discrete-GPU original code you started with.

HIPIFY turns migration into something measurable

Before you touch a line of code, you can already answer the biggest question: how hard is this going to be?

HIPIFY provides a way to scan and understand your CUDA codebase before migration. It includes both hipify-clang and hipify-perl, each serving different purposes. hipify-clang performs AST-based translation using the Clang frontend, enabling accurate, context-aware conversion of production CUDA code. Because it relies on semantic parsing, it requires the presence of CUDA headers, such as cuda_runtime.h, and appropriate include paths so that Clang can correctly resolve and interpret the source code. In contrast, hipify-perl is a lightweight, text-based tool that uses pattern matching for quick scans and initial translation but lacks semantic understanding and requires more manual validation. HIPIFY can automatically convert many CUDA runtime API calls, kernel launch syntax, and common language elements, while clearly identifying areas that need manual attention.

This matters because it turns migration from a vague risk into something you can quantify.

You are no longer asking, “Will this be painful?”

You are asking, “Which functions port directly, and which functions will take time?”

This is a much healthier place to start.

As just one example, in AMD internal testing of a phased-array beamforming application, HIPIFY preserved up to 81% of CUDA code.¹ Understanding what needs your attention and what is already ready for test helps you to establish the level of effort required to migrate your code. And because HIP can also target the NVIDIA backend, you can stabilize functionality on the systems you already have before turning your attention to AMD targets. That incremental, validate-as-you-go path is part of AMD CUDA-to-HIP/ROCm migration training.

Why Ryzen AI Embedded X100 Series processors change the conversation

This is where the platform story becomes much more interesting.

When your software is portable, you stop considering a platform as the one that runs your code and the default for your next design. You start evaluating hardware as the system that best fits my product. That is exactly why an AMD Ryzen AI Embedded X100 Series processor matters in this conversation.

The AMD Ryzen AI Embedded X100 Series processor is not just a target with integrated graphics. It’s a single-chip embedded platform that combines high-performance “Zen 5” CPU cores and AMD RDNA 3.5 graphics. X100 balances CPU and GPU performance, delivering low-latency AI and system-level responsiveness without the extra complexity of stitching CPUs and GPUs together as separate devices. X100 also integrates a low-power, performant NPU, designed to accelerate inference with the AMD Ryzen AI software platform. Developers can also explore use of the NPU for a variety of workloads such as image and signal processing with the AMD Riallto framework, adding additional value to the AMD NPU for diverse embedded applications. All this matters because the device is balanced for modern workloads, very different than the classic GPU-first architecture that was popular in the past.

So, instead of building around a discrete accelerator and then managing PCIe hops, discrete memory domains, and building the rest of the system around it, you can target a platform where CPU, GPU, and NPU are fully integrated. This can simplify packaging, memory movement, power, and thermal design. For many edge and embedded products, this system-level simplification matters every bit as much as raw accelerator throughput.

And, the Ryzen AI Embedded X100 Series processor is not only about architecture on paper. When you combine its CPU concurrency, integrated AMD RDNA 3.5 graphics, AMD XDNA 2 NPU acceleration, and unified shared memory, the message becomes much clearer: you are not giving up system capability to gain portability. In many cases, you can architect a platform that is better aligned to the problem you are trying to solve.

Ryzen AI Embedded P100 Series processors carry the same logic into more cost- and power-constrained designs. They give you the same CPU/GPU/NPU integration in a smaller embedded footprint, making portability valuable even when you are not building an X100-class system.

NVIDIA has enjoyed a strong position in the minds of developers because CUDA is mature, familiar, and heavily associated with AI. But this has led to the assumption that the GPU stack must be the center of gravity for system design.

If your product is truly a GPU-first box, that assumption may be fine. But if you are building a system where CPU concurrency, networking, display, graphics, and AI must coexist, then a GPU-first design is not automatically the best answer. Basing your platform around Ryzen AI reduces complexity instead of adding to it.

Portability only matters if the ecosystem around it is credible

Of course, no one adopts a new portability path on faith alone. You need tooling. You need documentation. You need examples. You need a learning path. That is why it is more useful to describe AMD ROCm software as a backed, open-source software stack than to simply say “open source.” The value is not openness for its own sake. The value is that you get flexibility and support without having to adopt a toolchain that is not backed by the vendor.

AMD publishes a porting guide and a public CUDA-to-ROCm migration course designed specifically for developers who already know CUDA and want to understand the conversion path in a structured way. Furthermore, AMD has more than 900 customer-facing employees invested in your success with AMD Embedded platforms.

All of this matters because the real barrier here is not syntax. It is confidence. You need to know that there is a supported way to do this.

The bigger shift

The most important thing to understand is that this is no longer only a GPU decision. It is a software leverage decision.

If your code stays tied to one vendor’s stack, then every future product inherits that vendor’s constraints. If your code becomes portable, you regain freedom over architectural decisions. That means you can choose a discrete GPU when it’s right. You can choose an integrated APU-like AMD Ryzen AI Embedded X100 Series when it aligns with your needs. You can let the product requirements drive the architecture instead of letting old software assumptions drive you to work around it.

That is the real benefit. Not abstract portability. Not “open” as a slogan. But something much more practical:

You keep the software you have already built, and you get the freedom to build a platform that is ready for what comes next.

The most valuable part of your GPU software is not the vendor it started on. It is the engineering investment already inside it. HIP and HIPIFY give you a practical path to preserve your CUDA investment while expanding your options. And once your code is portable, platforms like AMD Ryzen AI Embedded X100 and AMD Ryzen AI Embedded P100 Series processors become much more compelling—not just as alternatives to NVIDIA, but as integrated system platforms that may fit your next design far better than a GPU-first architecture.

That is why portability matters more now than it did when CUDA first became the default. Learn more about CUDA-to-HIP migration with HIPIFY and explore how the AMD ROCm platform can help you prepare for your next embedded design.