LuxCoreRender Forums

The bug was correctly tracked down. The root cause was a division by zero but because of some reasons, the wreckage happened when multiplying the result of the division by zero when applying a multiplication optimization in LLVM. Matt Arsenault provided a precious help to track down this bug. The re...

I managed to bisect the old LLVM version 11 I suspected to have introduced the regression, while keeping an environment able to build Mesa so I can check the behaviour of LuxMark on every bisect step. I found the commit in LLVM that introduced the regression. And in this commit, what introduces the ...

I looked for a code in LuxCore that contributes to the lighting. I picked `AdvancePaths_MK_HIT_OBJECT` from `include/slg/engines/pathocl/kernels/pathocl_kernels_micro.cl` that has a comment mentionning `MK_DL_ILLUMINATE`. I tried to see if I can modify it in a way I get an obvious effect on the rend...

So, after more research, it appears that the bug is reproducible as soon as at least one component of the vec3 returned by `MatteMaterial_ConstSample` is not zero. This function is probably not in cause. The input is believed to be always valid as it is believed to always come from hardcoded values ...

I did more research. The bug happens when `MatteMaterial_ConstSample()` function returns `(1.0 ,1.0 , 1.0)`. So, something looks really wrong. `(1.0, 1.0, 1.0)` is not NaN neither zero so we can both rule out this number being used as NaN in another compute or another compute doing a division by zer...

I verified that ROCm is affected as well, which is not surprising since both Clover and ROCm relies on LLVM. Here is the issue as reported on ROCm side: https://github.com/RadeonOpenCompute/ROCm/issues/1828 I provide a script to (re)build LuxMark 3.1 on modern systems, I successfully tested it on Ub...

I'm still able to reproduce the bug when I reduce the luxball/scene.scn scene file to this: scene.camera.lookat.orig = 0.649246990680694580078125 0.279195994138717651367188 0.148695006966590881347656 scene.camera.lookat.target =0.107509911060333251953125 1.0487911701202392578125 -0.18930505216121673...

Thank you for your answer. I was afraid investigating this from LuxMark side would not be easy, you seems to confirm it. One interesting thing I noticed in the mean time is that PoCL pthread (CPU implementation) that is also relying heavily on LLVM suffered from a very similar problem in LLVM 11, me...

Hi, I found a bug in the `-ffast-math` option of the LLVM Clang compiler that is reproduced when compiling OpenCL code using LuxMark. I'm looking for help to narrow the reproduction test with hope to get this Clang bug fixed. Some context: The Mesa Clover radeonsi OpenCL driver for AMD GCN and later...