AMD OpenCL error - Cycles
Open, IncompletePublic



on AMD RX 480 I get this error, while the same scene renders perfectly with CUDA on GTX 970.

'Opencl error -61 CL_INVALID_BUFFER_SIZE in CLCreateBuffer'

Blender 2.78RC
Win7 64


  1. Driver version used?
  2. Did it work in 2.77a? Does it work in latest master?
  3. Does it render with smaller tile size? (like 384x384)

Attach an example file which trigger this bug.
In my experience, 16.7.1 crashed in some scenes, but 16.30 on Linux and 16.8.3 on windows never had any problem, so try with one of those.

Alma Talp (AlmaTalp) added a comment.EditedSep 19 2016, 8:16 PM

Thanks, I try to be more specific:

  1. Driver version: 16.8.2 and 16.9.1

Didn't work in 2.77a (viewport rendering)
Didnt work with 2.78 RCII (viewport rendering)
Didn't work with 2.78 daily build C2D7D47 (viewport rendering)

Unfortunately I cannot share the files because of its content (copyrighted).
It uses 2K and 4K textures and more than 10.000 objects (mostly instanced).

  1. Does not render with smaller tilesize

With 16.9.1 viewport rendering does not work, normal render works, but with these problems:

  • no remaining time is shown (lack of refreshing I think)
  • no image in the actually rendered region is shown, just after the tile is finished
  • canceling render is extremely unresponsive

Idea: could this problem be related to some kind of texture number limitations handled differently in viewport render and final render?

I also tried to use split kernel (debug mode) with nVidia + AMD GPU OpenCL mode (together), it resulted error in 'standard' rendering, also half of the image was rendered in progressive mode (OpenCL error -4) Mem object allocation error in clenque NDrangeKernel

Tom (vejn) added a subscriber: Tom (vejn).EditedSep 20 2016, 11:28 AM

I got OpenCl error when rendering with latest build.
AMD 7870, 16.9.1
Does not depend on tile size.

Brecht Van Lommel (brecht) lowered the priority of this task from "Unbreak Now!" to "Incomplete".Sep 25 2016, 2:10 AM
Brecht Van Lommel (brecht) removed Thomas Dinges (dingto) as the assignee of this task.

We really need a way to reproduce the issue to investigate this. Even if you can't share the original .blend, it is usually possible to investigate what is going on, incrementally removing meshes, materials, textures, etc. until you find more details about what goes wrong specifically and can redo it in a simple .blend.

Even if it requires a complex .blend you can usually replace meshes, materials, textures with dummies to the point that there is nothing of value in the .blend anymore that you can't share.

I spent this afternoon with finding the problem.

I came out with this: when I have about 60 of 4K textures, I got the problem. Same file renders on CUDA.

Important: it affects viewport rendering; tiles-based final render (F12) works.

Another thing: I got blue screen several times instead of error message during the tests.

Brecht Van Lommel (brecht) raised the priority of this task from "Incomplete" to "Normal".EditedSep 26 2016, 12:18 AM

Is this a card with 4 GB memory? It sounds like an out of memory error that we should be handling more gracefully. If it's a more than 4 GB, we might be reaching limits of 32 bit pointers.

With 60 4k textures memory usage would be:

single channel byte textures960MB
rgba byte textures3840MB
single channel float textures3840MB
rgba float textures15360MB

These are RGB, RGBA and greyscale textures together.

As I wrote it renders on a GTX 970 (3.5 GB memory), I use RX 480 8 GB for OpenCL.

Hello guys, I just tested with 2.78a; still I get this error with another file, only 2 GB texture memory used on RX480, renders well on GTX 970.
Is there any news on this? Thanks.

Use 16.10.4 and try to check motion blur before rendering.

Thanks, it does not work. Viewport rendering just reproduces the same error, it is not related to motion blur; it is related to the number of textures.

Alma Talp (AlmaTalp) added a comment.EditedJan 17 2017, 4:56 AM

Hello Guys, is there any news on this? I downloaded the latest builds and still cannot use my RX480 for viewport rendering.

Your GPU is running out of memory because the tile size is too large. Unfortunately the tile size for viewport rendering isn't the same as for final renders and isn't controllable from the UI. To change the tile size for viewport rendering you'll have to use python. Set['Scene'].cycles.debug_tile_size to the desired size.

This kind of thing is handled better in the cycles_split_kernel branch, hopefully we can merge those changes into master soon.

Hello Mai, thanks for the answer.
I have zero knowledge in python; would you please write me down what I exactly should do (and then how to revert back?)



I just made a quick test with the actual version of my 'big scene' on RX480 with the latest nightly build.

It does not render at all. No viewport render, no final render.

For final render I tested with different tilesizes, from 100 x 100 to 1000 x 1000, also progressive rendering.

Same scene renders well with GTX 1070, about 5,5 GB RAM usage (I added some more stuff to my scene since the last test and I bought a new nVidia card as AMD seems to be completely useless for work).

To change the tile size setting for viewport rendering open the python console editor in blender and enter a line such as['Scene'].cycles.debug_tile_size = 64, changing Scene and 64 as needed.

If your scene isn't rendering at all it means you've ran out of GPU memory, the only things to do in that case is to reduce scene complexity or use another device.


'If your scene isn't rendering at all it means you've ran out of GPU memory, the only things to do in that case is to reduce scene complexity or use another device.'

I didn't run out of memory; please take a look on the second part of my former reply. Thanks.

I made some tests with for the viewport.

Changing tilesize makes artifacts on the screen and bad renders.


I made a test on a part of the scene.

While default tilesize for viewport render only results the 'openCL error' message and black screen, changing it to 512 or 256 starts fine at the 1st sample, but from the second makes artifacts (random image parts on the screen).

Aaron Carlisle (Blendify) lowered the priority of this task from "Normal" to "Incomplete".Mon, Apr 17, 6:09 AM

Please try a build from