- User Since
- Jul 4 2014, 11:26 PM (176 w, 5 d)
Tue, Nov 21
Thu, Nov 16
Wed, Nov 15
Tue, Nov 14
Sat, Nov 11
Thu, Nov 9
Thu, Nov 2
Wed, Oct 25
How valid is it really to use the perspective camera projection for points outside the frustum? It provides a smooth transition at the frustum edges, but the further you go away it doesn't seem so meaningful. A panorama camera projection may be better.
I haven't heard anything back from them in a while, I'll try contacting them again and see what the status is. Hopefully it won't take long to get fixed.
Oct 20 2017
Oct 2 2017
Sep 27 2017
Sep 19 2017
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...
Sep 4 2017
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.
Aug 31 2017
The crash appears to be coming from the driver, AMD has been notified.
Aug 30 2017
Aug 29 2017
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
Aug 26 2017
This fixes the crashes in both koro and victor for me.
Aug 25 2017
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).
Aug 24 2017
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.