Radeon ProRender for Blender: a path traced renderer that works on CPUs too

A path tracer that is not tied to one graphics card

This is a hardware-agnostic rendering plug-in for Blender that uses accurate ray-tracing technology to produce images and animations of your scenes, and it provides real-time interactive rendering and continuous adjustment of effects.

The supported device list is the headline, because it is not what you would expect from a Radeon-branded product. The README lists AMD GPUs in the Vega, Navi 1x, Navi 2x and Navi 3x families. It lists NVIDIA GPUs. It lists Apple Mx GPUs. And it lists AMD and Intel CPUs.

So a CPU-only machine can run the renderer, and a machine with an NVIDIA card can too. For a render farm of mixed hardware, or a laptop without a discrete GPU, or a build agent in CI, that is the difference between using the plugin and not using it.

The second part of the pitch is the interactive side. Real-time interactive rendering and continuous adjustment of effects means the path tracer is not only for the final frame. You can adjust lighting and materials and see the result update, rather than waiting for a batch render to find out what you did not like about it.

The licence is Apache-2.0, the primary language is Python, the default branch is master, and the last push was on 2026-09-10. The homepage points at the Radeon ProRender suite on gpuopen.com.

The release tags follow Blender, not the plugin

The Releases section at the top of the README is a mapping table, and it works differently from most plugins.

The links given are for Blender 4.1, 4.2 and 4.3, pointing at the tag v3.6.11, and for Blender 4.0, pointing at v3.6.10. For older Blender versions the README points at the releases list.

So the plugin version and the Blender version are two different numbers, and the plugin version tracks the Blender version it was built against. The recent release history shows the same pattern. v3.7.0 is titled as Radeon ProRender for Blender v3.7.0 for Blender 5.2 LTS and came out on 2026-09-10. v3.6.12 was for Blender 4.5 LTS in August 2025, and v3.6.11 covered Blender 4.1, 4.2 and 4.3 in December 2024.

The practical consequence is that the newest tag is not necessarily the one for you. If you are on Blender 4.5, the plugin release you want is v3.6.12, not the v3.7.0 that came out a year later for a different Blender generation. The README solves this by listing the mapping up front rather than making you work it out from tag names.

It also means the plugin is released on Blender's schedule, and a new Blender release can leave you without a matching plugin build until the maintainers catch up. That is a normal risk for any add-on that links against a native core library.

Building it means Visual Studio and four submodules

The build requirements section is specific and dates the project.

You need Blender 4.1 or newer, and Python 3.11, with the note that Blender 4.1 uses 3.11, x64 for Core, and the remark that all code, addon and misc are tested with python3. You need python-cffi, and the two commands given for it are `py -3.11 -m pip install cffi` and `py -3.11 -m pip install numpy`.

The compiler requirement is Visual Studio 2015 SP3, 2017 or 2019 with the SDK 8.1 and the 2015.3 v140 toolset installed, and the note that on Visual Studio 2019 you would need to install the Windows SDK 8.1 manually from the Microsoft website. cmake 3.x is needed, and you have to make sure it is added to the PATH environment variable.

The plugin includes four submodules, and they are named: the RadeonProRender SDK, shared components, the Image Processing Library, and third party components with miscellaneous tools. The update command is:

git submodule update --init -f --recursive

Then the build itself is one command, run build.py to build.

There is a note about the Visual Studio solution file that saves a lot of confusion. The .sln provided is for easy editing and searching of files on Windows, and the Blender code builds on the command line rather than in the solution file. Visual Studio does provide support for debugging Python when you attach to the running Blender process with the loaded addon.

The repository layout shows what is where. There is src/ for the plugin source, BlenderPkg/ for the packaging directory, and the three SDK directories as top level entries, RadeonProRenderSDK, RadeonProRenderSharedComponents and RadeonProImageProcessingSDK. There are build scripts for Windows, for OS X in two flavours including an arm64 one, cmd_tools/, docs/, and per-platform readmes with README-LNX.md and README-OSX.md alongside the main one.

Running the addon without installing it

The development loop is documented separately from the build, and it is the part that will tell you whether the build worked.

First, make sure you have no installed addon for the Blender version you want to use, and remove the installed version if needed. Then set the environment variable BLENDER_EXE to the blender.exe you want to use, through the command line or the system environment settings. Then run run_blender_with_rpr.cmd.

The example given is:

`set BLENDER_EXE="C:\Program Files\Blender Foundation\Blender 2.93\blender.exe" && run_blender_with_rpr.cmd`

So the idea is to point the script at a specific Blender binary and run it with the addon loaded from your build tree rather than from an installed copy. The reason for removing the installed version first is obvious once stated: if Blender loads the installed addon, your code changes do nothing, and you will spend an afternoon debugging a build that was never loaded.

The repository carries the equivalents for the other platforms, with run_blender_with_rpr_Ubuntu.sh and run_blender_with_rpr_osx.sh next to the Windows .cmd file, and build.cmd, build.sh and build_osx.sh as the matching build scripts.

There is also a vs_path.bat in the root, which fits the pattern of the whole project: a small Windows helper script to put the Visual Studio toolchain on the path so the native part of the addon can be compiled from a shell.

Debugging Python inside a C application

The Debugging section is a good illustration of the difficulty of working on this kind of add-on, because you are debugging Python that is running inside a native application that you did not build.

The logging story comes first. It uses Python's logging module underneath, and rprblender.utils.logging has functions similar to logging. It also includes a callable class Log which provides a simplified interface to do logging, with an example that constructs a log with a tag and calls it with a sync, a mesh and an object.

The detail that matters for a large codebase is the filtering. logging.debug takes the same arguments as print, with a tag which is a string suffix for the logger name used for filtering, and logging.limit_log(name, level_show_always) allows you to filter out what does not start with the name, expecting levels equal to or above level_show_always. And configdev.py, loaded very early, can be used to include code like limit_log to configure your session, with a second example that turns on config.pyrpr_log_calls to log all Core function calls to the console, described as something that can be VERY useful.

For the IDE side, the README is enthusiastic about Visual Studio, which it says has really nice and working mixed Python and C stack debugging, and calls it recommended. For Blender itself, the advice is to build Blender in Release or RelWithDebInfo, with a pragma to turn off optimisation in the region you care about, and there is a pydevd snippet for attaching from PyCharm.

That last detail is the honest summary of the situation. The addon is Python, but it sits on top of a native core, so the useful debugging tools are the ones that can cross that boundary.

Making a release means editing a version string in three places

The Making a new release section is five steps and reads like a checklist, and each step tells you where something is kept.

You move to the BlenderPkg directory. You run build_osx-arm64.sh for Mac for MX processors. You tag the commit in the build folder's ProRenderBlenderPlugin with git tag builds/x.y.zz. You push the tag with git push --tags. And you increase the version in src/rprblender/__init__.py.

The version lives in the source, not in a metadata file, which is the older convention but perfectly workable. The tag format builds/x.y.zz is not the v3.6.11 style you see in the releases list, which tells you there are two different tagging schemes in the repository, one for the build artefacts and one for the plugin versions.

The Python conventions are also spelled out, and they are modern for a project of this vintage. The aim is to conform to pep8, with at minimum 4 spaces for indentation and utf-8 sources, and a .gitconfig in the root of the project that you should set your editor to use. The README goes on to name PyCharm as recommended, noting its default settings are fine and that it also picks up .editorconfig automatically, Tortoise Merge with its Enable EditorConfig checkbox, and the Visual Studio EditorConfig extension.

The Git guidance is about avoiding merge commits, with two settings: merge.ff only, which rejects merges that would result in a merge commit, and pull.rebase true, which converts pull to do, essentially fetch and rebase. The suggestion for a meaningful history is one commit per feature, with git merge <branch> --squash to turn a branch into a single change set.

Editorial conclusion

Adopt this add-on if you need path traced stills or animation from Blender and you do not want to be tied to one GPU vendor, since the supported device list covers AMD, NVIDIA and Apple hardware as well as CPUs. Do not expect a modern build workflow, because the documented toolchain is Visual Studio 2015 through 2019 with the 8.1 SDK, and the add-on version and the Blender version are separate numbers you have to match. Before you build, update the submodules with git submodule update --init -f --recursive, and read the release list at the top of the README, because the newest tag for your Blender version is not always the newest tag overall.

Frequently asked questions

Official sources

1. GPUOpen-LibrariesAndSDKs/RadeonProRenderBlenderAddon on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases