• Merge branch 'blender2.7' into arcpatch-D4349

See here the results of this change in terms of node compilation times.

Script used for this research. Needs to be run blender containing D2264 patch.

Patch created D4349

• D2264: Multi Process OpenCL Kernel Compilation

Here are the measurements of how much effort it takes to compile a certain node.

@Piotr (arcman) Not expected. Can you add your system info and clinfo to this ticket. Will try to confiscate a Vega64 here and see if I can reproduce the issue.

In your review you added a comment to use execv and _execv due to possible incorrect argument passing.
The execv functions rewrite the current process and fails to receive the correct arguments.
Googling did not give me any useful answer (process forking).

• D2264: Cycles OpenCL Multi Process Compilation

• Merge branch 'master' into arcpatch-D2264
• D2264 Cycles OpenCL Multi process compilation

• Reduce overhead by bundling small (static) kernels in a single program.

@Piotr (arcman) Hi, just to be sure that it is not an out of memory issue. can you try to render it with Simplify texture limit set to 1024?

Hi, can you try to explain in more detail what this issue is about?
If I read and understand correctly you compare a NVidia driver on Windows to an AMD MacOS driver on Apple.
Different OSes and hardware and drivers lead to other programs and memory usage.
If this is the case the difference is in the driver and hardware.

• refactored system_call_self to use a reserved capacity string. The previous implementation had a popential security risk, when passed parameters exceeded 10k.
• tweaked load_kernels. The split kernel were compiled when the SplitKernelFunctions are created. This made the compilation of the split kernels to be done in the main blender process before the compilation processes were started.
• renamed load_kernels to add_kernel_programs as load kernels had to construct the list of programs to load cq compile.
• construct the right source when compiling. Due to changes in Cycles, the relative paths and setting names were incorrect.
• ordered the split kernels so the largest kernels are compiled first.

• Most 'huge' kernels are not effected by current implementation as they are compiled before this logic. (for example split kernel).
• Should we compile every program this way. I will make this an option in the program so small kernels do not start new processes, only large kernels/programs.

Will continue at D2264

Hi Lukas,

Merged master into D2264

Something went wrong. Arcanist created a new object D4313 where I merged latest master in this code. I will continue working there.

I have gone over the compositor and workbench engine. In the compositor I only found minor stuff what is is not needed to be mentioned. In the workbench engine I did found something that we might want to fix later on.

Not sure we want to go for this (hacky) solution or make BAT more cross platform aware. Will test BAT on Windows in the next few weeks and see if everything works as expected.

Ah never mind. the UNIFORM COLOR. I see now what you tried to do with the draw border shader :-)

Hi Clement,

Technically the patch is ok. So I will approve.

added a log with some details where to find the issue.

• D3675: Weightpaint drawing