- User Since
- Mar 27 2015, 2:47 AM (112 w, 3 d)
Sun, May 21
If it was reported in another bug report, why did you report it again?
I see no errors in latest buildbots
Apr 17 2017
Apr 16 2017
I confirm all of this, even the "holes not covered" part, using the supplied test case.
can you confirm that your issue is the same described in T51074?
Mar 19 2017
For a more up-to-date discussion of this issue, see here:
Yes, that's exactly what I said --
Mar 18 2017
It turns out that these compiler warnings --
Mar 13 2017
The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports. Patches are available upstream for both problems, as mentioned above.
It turns out that the "invalid argument type 'X *' to unary expression" compile errors are the result of a known bug in LLVM. It is said to be fixed in LLVM-v5; see here:
This same problem (actually, several problems) has been reported here; it's not distribution- or hardware-specific:
Mar 12 2017
Adding device specific code for a few specific cases does not abstract that away.
The more code we can share between CPU/CUDA/OpenCL the better, every device specific code we add can get out of sync and makes it more work to maintain, so I rather not do this.
I didn't reuse CL_M_*_F since we need the defines for C++ and CUDA too,
and adding an OpenCL specific variation would not simplify the code.
Mar 10 2017
It appears that the openCL standard header file <cl_platform.h> already defines
almost all of these constants:
There's a whole header file with this problem:
Mar 27 2015
modifiers do not affect objects, they affect geometries (i.e. object’s data). Since empties have no data/geometry, they cannot have modifiers...
why is there no way that an empty object can be used to control the visibility of its children?
Is there a reason why this should be so? Can recursive application at least be made an option?