- User Since
- Jul 4 2014, 11:26 PM (158 w, 6 d)
Tue, Jul 18
It looks like a driver / memory problem. Everything is working fine for me here on Arch with the xf86-video-amdgpu package. Does this happen consistently? Does fully updating the system followed by a reboot help?
Wed, Jul 12
Fri, Jul 7
This file is in fact too complex to render. OpenCL will only allow a certain amount of memory to be allocated at once (seems 4gb is most common). In Cycles each of geometry, BVH, textures, etc get allocated into their own buffer. If any one of these exceeds the limit for one buffer the allocation will fail and rendering will abort. So even tho your card may have more than enough total memory available to render the scene, the memory available for the individual buffer is insufficient.
Thu, Jul 6
I've pushed a commit (222b96e5) that will give you a better error message if your scene is too large. Please test again with a build containing this commit and reopen this report if you get any errors aside from the new message ("Scene too complex to fit in available memory.") Thanks.
Fri, Jun 30
Wed, Jun 28
Thanks for the clear and detailed report. I will fix the errors seen with the mega kernel, but that does not mean you will be able to use it to render with your GPU.
Jun 11 2017
Jun 10 2017
Jun 8 2017
Jun 5 2017
I just tried it. What I said is correct.
This is sort of a known limitation. Blenders way of doing creases is very odd and unique and makes no sense in the context of adaptive subdivision (Blender changes the strength of the crease depending on the level of subdivision, but for adaptive the level is effectively infinite for which Blenders method would be nonsense). I intend to propose a change in blenders creasing behavior for 2.8, but for now the mismatch exists.
May 30 2017
We will be dropping support for GCN1 because we cant fix these issues for a variety of reasons:
- I don't have a GCN1 card to test on or try to find a workaround.
- Everything seems to be fine on GCN2 and 3 as well as Nvidia OpenCL, so we know the kernels work.
- That means this is most likely a driver bug, which is something we cant fix anyways.
- It seems that AMD hasn't provided updates for these cards in a while now.
May 25 2017
This was supposed to be merged into T44674 but phabricator seems to have done something weird... no option to fix it either...
Closing for a few reasons:
May 19 2017
I cant reproduce this on my hardware. My guess is the scene is too large, but we should probably have a better error message in that case. I'll try to put something together for that later.
May 16 2017
Might be nice to record more info into system-info output, but not sure theres anything else useful in this patch.
Im unable reproduce here. Please update your drivers and try again with latest master.
May 9 2017
- Use VLOG only
- Added code to touch cached files are they are used
May 3 2017
Made requested changes
May 2 2017
It would be nice to blacklist the older cards, but I havent found a way to do it yet.
Interesting render results. Unfortuantly @Aaron Carlisle (Blendify) is correct, we arnt supporting GCN1 cards anymore.
May 1 2017
Apr 29 2017
Apr 28 2017
- Fixed path termination again
- Removed ifdef around ray flags
- Rebased on master
Closing as these changes are already in master.
Apr 26 2017
Apr 25 2017
Reuploading with context, couldnt see where inline comments where attached to.
- Fixed ifdefs
- Fixed usage of wrong PathRadiance in do_volume and subsurface_scatter after the change in ray_index for loop iteration.
- Fixed logic for path termination
- Rebased on master
Apr 22 2017
Apr 21 2017
@Tom (vejn) Please open new reports for new issues, putting different issues into the same report is quite confusing.
This could be a driver issue with GCN 1 cards as all cards mentioned in this report are that generation. I cant reproduce this with the cards I have available, and if it is a driver bug there's nothing that we can do anyways. There is a new version of the drivers released recently you guys could try, but we may have to drop support for these cards.
Apr 19 2017
Apr 18 2017
Only minor stuff, don't want to be too picky. I think it will be fine to commit, but maybe would be nice if @Sergey Sharybin (sergey) or someone else could test CUDA split first (I would test it but I've been having issues with CUDA lately).
Apr 11 2017
Apr 8 2017
Apr 7 2017
Mar 31 2017
Only did a quick look right now, will look over the rest later. I like the changes to how kernels are handled.
Mar 29 2017
Im fine with this too.