- User Since
- Jul 4 2014, 11:26 PM (167 w, 6 d)
Tue, Sep 19
The image node is set to box projection, which might be using the wrong coordinate system during bump evaluation.
Could be a duplicate of T52645, which was closed for some reason...
Mon, Sep 4
Looks to be the same compiler crash from T52589. Not sure if there's anything we can do as there's no proper error from the compiler. I don't think reverting to older drivers will help in this case either, as the crash is likely an existing issue triggered by some code change we made at some point. Maybe someone could bisect this, could help the compiler team in getting this fixed.
Please keep the discussion to the reported crash only. Discussion of other stuff can happen in irc, mailing list or another dedicated task.
Thu, Aug 31
The crash appears to be coming from the driver, AMD has been notified.
Wed, Aug 30
Tue, Aug 29
Not a bug, GC1 cards are no longer supported, this is mentioned in the release notes: https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Cycles
Sat, Aug 26
This fixes the crashes in both koro and victor for me.
Fri, Aug 25
I don't think there's a bug here. The normal map node needs tangent vectors to apply the effect correctly, there is a place in the node to select which UV map to generate the tangents from. In this file you've used the "Generated" texture coordinates, for which no tangent vectors are generated. To get correct results you need to actually UV unwrap the mesh and use the UV coordinates directly (without a mapping node).
Thu, Aug 24
This is not a bug, the split kernel allocates a block of memory (usually 2gb, but could be different depending on drivers) for passing ray state between kernels. Older version also allocate memory for this purpose, but drivers and code changes may have cause the amount to change. Rendering will not be affected by this.
Aug 23 2017
Aug 9 2017
I don't like it, but I'm not going to hold this up. Maybe add a note to the manual?
Final render is actually a few percent faster with this, I don't have an explanation.
This was fixed in the very next commit from the one you tested. Any newer build will be fine.
Aug 8 2017
Made changes to make likes shorter.
There's not really enough info to go off here, the only interesting thing in the log is "Error: EXCEPTION_ACCESS_VIOLATION" but that says almost nothing. Is there a another crash log somewhere? Please look for one and also check that your drivers are up to date.
Aug 7 2017
Removed use of memcpy on device_memory.
I don't think there is a good non-arbitrary default for clamp values besides leaving them disabled. In a scene using real world values for sun and sky for instance a clamp of 10 is very low and very notiable on lighting quality. This conflicts with the intention of the filmic transforms, and so I think it would be better to leave the defaults for clamping as is to avoid more issues in that area.
Aug 5 2017
- Rebase on master
- Created MemoryManager class to contain logic of managing buffers
- Rename and cleanup
- Removed old image packing code
Aug 3 2017
Only GCN 2 and higher are supported, so closing.
Jul 26 2017
Not really sure what GPU you have from your description, but you must have GCN 2 architecture or newer to use it with Cycles. You can look to see if its listed as such here: https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units.
Jul 25 2017
I can't reproduce this with the hardware I have available (no macOS here). Maybe @Lukas Stockner (lukasstockner97) can take a look?
Jul 20 2017
Jul 18 2017
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?
Jul 12 2017
Jul 7 2017
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.
Jul 6 2017
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.
Jun 30 2017
Jun 28 2017
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.