alpha06 bugs

[Dade]

I may have finally understood how the NVIDIA compiler bug work (or better doesn't work): when you explicitly mark a function for inlining (or not), you have also to explicitly mark any function called by the marked function. If you don't the compiler is very likely to generate broken code.
It is like if the compiler inline the code in one place and than it fails any other function invocation (because the function has been inlined and doesn't exist).

Anyway, applying this principle I have marked the vast majority of OpenCL functions (as inline or not) and it seems to work well. I haven't found a scene able to crash the new code and the compilation speed is greatly improved (i.e. LuxMark Mix scenes from 60-90 secs to 10-15 secs).

I have attached to this message a pyluxcore.pyd for Windows 64 with OpenCL support. It includes the workaround and it can be used to replace the one used by BlendLuxCore, can you check if it works for you too ?

[B.Y.O.B.]

Note: the pyluxcore.pyd file has to be placed in the bin folder of your BlendLuxCore installation, replacing the existing pyluxcore.pyd.

[Asticles]

Just tested,

After some time rendering, with old pyluxcore, it was at 1.0M, and with the new, 1.7M

Thanks!

[jensverwiebe]

I may have finally understood how the NVIDIA compiler bug work (or better doesn't work): when you explicitly mark a function for inlining (or not), you have also to explicitly mark any function called by the marked function. If you don't the compiler is very likely to generate broken code.
It is like if the compiler inline the code in one place and than it fails any other function invocation (because the function has been inlined and doesn't exist).

Anyway, applying this principle I have marked the vast majority of OpenCL functions (as inline or not) and it seems to work well. I haven't found a scene able to crash the new code and the compilation speed is greatly improved (i.e. LuxMark Mix scenes from 60-90 secs to 10-15 secs).

I have attached to this message a pyluxcore.pyd for Windows 64 with OpenCL support. It includes the workaround and it can be used to replace the one used by BlendLuxCore, can you check if it works for you too ?

You could have asked me and test my build. Also i said i have a patch avaialble.
Anyway, weeks ago i talked with NVidia about this problem and the next compiler might fix this behaviour.

EDIT: my patch still is faster, perhaps cause i also optimized camera and lightfuncs, but have no time to sort this out atm..
EDIT2: just saw you did too in between, odd that i get another balance.( hotel tad slower, mic a lot faster in compile, hmmm )
EDIT3: nvm, found it, hotel now 2.7s and mic 6.5s

[B.Y.O.B.]

Jens, I think it would help if you forked the LuxCore repository on github and commit your changes in your fork.
Then we can easily see them and you can send us a pull request, so we don't have to resort to patch files which get forgotten in old threads easily.
Just my thoughts. It's great that you also spent time to debug this annoying compiler and even talked to Nvidia about the issue.

[jensverwiebe]

Jens, I think it would help if you forked the LuxCore repository on github and commit your changes in your fork.
Then we can easily see them and you can send us a pull request, so we don't have to resort to patch files which get forgotten in old threads easily.
Just my thoughts. It's great that you also spent time to debug this annoying compiler and even talked to Nvidia about the issue.

I only have a huge patch still, cause i played a lot with profiling.
Thats more for showing another dev.
I don't wanna create a fork for this right now.( have also not yet an github account )
Lets see what NVidia says, awaiting second answer anytime soon.
Hopefully this all gets obsolete then, or even faster ( hope never dies ).

Another thing:
You may have noticed NVidia does not provide cuda9.1 toolkit for ubuntu 14.04.
But i copied the 16.04 installation ( cuda-9 dir ) just over from my 16.04 to the 14.04 and it works just fine.
Just in case you planned only to upgrade the distro just for the toolkit == not neccesary. Lot of ppl complained i saw.

[Sharlybg]

I notice that Area light lost the opacity feature. First i thoughs it is now ruled by the camera visibility check box. But after test i note that area are now unable to produce light while being transparent to other light source in the scene.

[B.Y.O.B.]

It did not exactly "lose" the opacity feature, it's just something that was not yet implemented (I know, it's sometimes hard to tell if a feature was omitted or just not implemented yet).

[Sharlybg]

I think i ve found a bug. It s related to bidirectional engine and camera clipping. Bidir engine sometime give some weird shadows line on top of render like the camera didn't correctly cut the obstacle. Note that i'd already got this problem with my japan taste project. Also note that path and path ocl work fine.

Pathocl engine

bidir engine

[B.Y.O.B.]

Can you upload a test scene?