Looks fine I guess, would be nice to deduplicate things more but not so important.

This patch is very usefull to work on the kernel in the train with a laptop, thank you. But it's very slow using the AMD 17.3.1 driver and Intel CPU as device. The default cube at 50% HD and 10 spp takes 8 minutes to render. Would it be possible to make it render at a more normal speed?

I'm not sure why it causes slowdown, it is more about getting things to work, not about speed. How does the speed compares to 2.78c?

In any case, we are in very restricted environment here where we need latest drivers to have decent speed on newer hardware. If the performance on older drivers (which are declared deprecated without bringing any usable replacement) is so poor afraid we can't do much from Blender side.

@Sergey Sharybin (sergey) thanks for the update, I will test and report. The slowdown is with latest driver, but with CPU device. GPU is fast as usual. But when working on laptop, it's great to be able to compile the kernel for CPU. With master, it won't compile. With this patch it compiles. Only problem is that OpenCL CPU is (hopefully was) approximatively 400x slower than normal CPU render. It may be a driver bug, but Luxcore works great on OpenCL CPU on the same machine with same driver.

New version has the same problem, works but is insanely slow, making testing nearly impossible. Can someone else test on Intel CPU with Radeon Crimson 17.3.1 (driver from March 2017) ?

Not entirely happy with how locals are done but not sure theres really a good way to go. Maybe have DEFINE_SPLIT_KERNEL_FUNCTION_LOCALS_$N and have kernel functions like kernel_func(KernelGlobals *kg, ccl_local unsigned int* local_1, unsigned int* local_2, ...)? That way we get errors if the number of locals falls out of sync.

Otherwise tho I think we should get this into master, as we keep getting reports related to this.