I have an AMD graphics card, and I want to accelerate Blender using OpenCL. However, Blender does not support the use of OpenCL acceleration with AMD cards. What is the technical explanation for this, and will there be a fix?

  • $\begingroup$ Are you talking about rendering in blender-internal or cycles? Please give more information. $\endgroup$
    – Daniel
    Commented May 29, 2013 at 22:27
  • 2
    $\begingroup$ Blender Internal has no GPU acceleration so Cycles it is in this case. $\endgroup$
    – jesterKing
    Commented May 29, 2013 at 22:45
  • $\begingroup$ Is this valid? - I thought we were going to reject hardware questions. $\endgroup$
    – ideasman42
    Commented May 29, 2013 at 23:00
  • 1
    $\begingroup$ @ideasman42 to a point as he is merely asking a question that requires no answer with instructions etc. Also since this is probably the first one and is such a common question in the community, it could slide. $\endgroup$
    – iKlsR
    Commented May 29, 2013 at 23:07

3 Answers 3


NVidia hardware and compilers support true function calls, which is important for complex kernels. It seems that AMD hardware or compilers do not support them, or not to the same extent.

To see why this is a problem, consider this example. There are 5 places where the shading nodes are executed, and there are 20 places in the shading nodes where perlin noise is used. Because no true function calls are supported, the compiler must copy the perlin noise code 100x. You can see how this would make the final code size blow up and cause issues for the compiler.

Note that V-Ray RT at this time also does not support running their full OpenCL kernel on AMD (only an older and simpler version), and Luxrender with OpenCL is also running into kernel size issues when adding more features. So that's a good indication kernel size is the main issue here.


I have been looking into this a bit and I found the answer after looking through the source code for a part of the AMD OpenCL compiler. AMD open sourced a part of their opencl compiler in 2012.

OpenCL translates the Cycles data into an LLVM intermediate representation, and then into AMD's internal language. During this step, it targets a specific fake-forward compatible GPU-like architecture with a fixed amount of registers.

The problem arises because the code OpenCL uses to do this does not include the ability to spill registers. Cycles due to its complexity requires more registers at this point in the translation process but the function that translates aborts with E012:Insufficient Local Resources!

Interestingly enough this same code has the following lines where it finds out it is out of registers:

// No physical register available. Has to spill.
// TODO: add spiller

This does not mean that adding the support will make Cycles work but this is the current road block people hit when they try to compile with the latest driver catalyst 13.01 and higher.

The page with the commit
The actual code in the LLVM repository

  • $\begingroup$ wait, how did you look through the source of AMD's ocl compiler? I thought it was close source as suggested by other answers. $\endgroup$
    – greatwolf
    Commented Jun 4, 2013 at 19:34
  • 2
    $\begingroup$ Yes the source is closed but a part of it is open-sourced. The LLVM intermediate representation to AMD intermediate language translation was committed to the LLVM repository about 9 months ago. I updated my answer to reflect this $\endgroup$ Commented Jun 4, 2013 at 19:37
  • $\begingroup$ only problem is that we have no way of knowing if they fixed this. But the exact error comes from this part of the compiler. $\endgroup$ Commented Jun 4, 2013 at 19:51
  • $\begingroup$ This difficulty of using opencl with cycles has been around for a long while. I was hoping that in 2013 that opencl tools would mature enough to knock this barrier down. It doesn't seem to be the case sadly. $\endgroup$
    – greatwolf
    Commented Jun 4, 2013 at 20:08

Compiling of the kernels fails due to extreme memory requirements. The Cycles kernels are rather big, and the AMD compilers are unable to cope with that.

There are two places where changes can be done: the compiler could be improved or cycles code could be reorganised. Both are huge projects and not very likely to happen. So unfortunately and sadly we'll have to suffer vendor-lock for Cycles for the time being.

You can always look into GPU accelerated renderers that don't suffer this, like Luxrender.

  • 2
    $\begingroup$ Cycles being big may not be the only problem, since AMD's OpenCL drivers are closed source we cant know, but its likely their compiler isn't doing a very good job also - which would make sense if comparable NVidia cards can run cycles. I hate to speculate but we don't have much to go by here. $\endgroup$
    – ideasman42
    Commented May 29, 2013 at 23:16
  • $\begingroup$ Aye, but based on IRC discussions regarding this topic this is how I understand the current situation. I didnt mean to imply Cycles is the only problem. Just that where-ever the needed changes are to be done isgoing to take time. $\endgroup$
    – jesterKing
    Commented May 29, 2013 at 23:19
  • $\begingroup$ What do you mean by "AMD compilers"? Do you mean the AMD-supplied OpenCL compilers? $\endgroup$
    – fouric
    Commented May 30, 2013 at 5:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .