LuxCoreRender Forums

Just for my understanding, does this have any downside?
I mean, in the specified cases a kernel recompilation is not triggered any more, but does the initial compile time increase (say because a feature is now always included) or not?

acasta69 wrote: ↑Sun Dec 29, 2019 2:35 pm Just for my understanding, does this have any downside?
I mean, in the specified cases a kernel recompilation is not triggered any more, but does the initial compile time increase (say because a feature is now always included) or not?

Yes, removing conditional compilation leads to have to compile more code and to execute conditional evaluation at run-time instead of at compile time. It also leads to use more ram as conditional structure size is removed too (i.e. the space to store volume information is allocated even if the scene doesn't include volumes).

However it is a downside of a couple of % points because most of the stuff has not a linear cost: compile 11 lines of code instead of 10 doesn't cost a 10% more and GPUs are fast to evaluate constant conditions (there is no divergence).

@Dade, what do you think about (pre-)compiling in background when using BlendLuxCore

Background:
Because most of the time when I am modeling objects or setting up the scene most CPU's cores are idle. (Pre-)Compiling of scene, objects and openCL kernel could principally be done on 25% of CPU's core. Time could be reduced this way attractively for rendering when switching view port render from CPU to GPU or starting final render on GPU.

FarbigeWelt wrote: ↑Wed Jan 01, 2020 5:19 pm @Dade, what do you think about (pre-)compiling in background when using BlendLuxCore

Background:
Because most of the time when I am modeling objects or setting up the scene most CPU's cores are idle. (Pre-)Compiling of scene, objects and openCL kernel could principally be done on 25% of CPU's core. Time could be reduced this way attractively for rendering when switching view port render from CPU to GPU or starting final render on GPU.

We know exactly what type of kernel to compile only when the scene is exported from Blender so we would have to continuously export/compile the scene after every edit to try to "anticipate" the rendering.

The main problem is that, not only OpenCL compilers are slow, they are also single thread ... can you believe that ? The same companies selling CPUs with tons of cores are also giving their costumers single thread drivers

The main problem is that, not only OpenCL compilers are slow, they are also single thread ... can you believe that ? The same companies selling CPUs with tons of cores are also giving their costumers single thread drivers

how on earth this can be possible ? what a shame

Dade wrote: ↑Wed Jan 01, 2020 7:04 pm

FarbigeWelt wrote: ↑Wed Jan 01, 2020 5:19 pm @Dade, what do you think about (pre-)compiling in background when using BlendLuxCore

Background:
Because most of the time when I am modeling objects or setting up the scene most CPU's cores are idle. (Pre-)Compiling of scene, objects and openCL kernel could principally be done on 25% of CPU's core. Time could be reduced this way attractively for rendering when switching view port render from CPU to GPU or starting final render on GPU.

We know exactly what type of kernel to compile only when the scene is exported from Blender so we would have to continuously export/compile the scene after every edit to try to "anticipate" the rendering.

The main problem is that, not only OpenCL compilers are slow, they are also single thread ... can you believe that ? The same companies selling CPUs with tons of cores are also giving their costumers single thread drivers

Make cpu rendering so fast no one cares about opencl or gpu rendering, problem solved or.... optix

Make cpu rendering so fast no one cares about opencl or gpu rendering, problem solved or.... optix

There is a reason why theses great renderer are GPU only

Fstorm
Octane
Redshift

If we go optix so AMD user will be left on the Dust ?

Sharlybg wrote: ↑Thu Jan 02, 2020 7:39 am

Make cpu rendering so fast no one cares about opencl or gpu rendering, problem solved or.... optix

There is a reason why theses great renderer are GPU only

Fstorm
Octane
Redshift

If we go optix so AMD user will be left on the Dust ?

there is a reason why fstorm, octane, redshift don't use opencl too
what is putting amd user to dust is opencl not optix.

By the way, will these improvements help with viewport rendering?
Right now adjusting anything about materials etc in blender is extremely slowly on opencl, using cpu the changes update quick but cpu is very noisy to see some subtle texture adjustments.

lacilaci wrote: ↑Thu Jan 02, 2020 5:38 am Make cpu rendering so fast no one cares about opencl or gpu rendering, problem solved

My RTX 2070 Super is "only" 2 times faster than my AMD 3900X. It is a huge difference compared my old PC where the GPU was several time faster than the CPU (AMD 290X Vs i7 3930K).

AMD/Intel need to put out a competitive GPU with NVIDIA: GPUs development is becoming more and more stagnant. It is the same situation of CPUs a couple of years ago.

lacilaci wrote: ↑Thu Jan 02, 2020 5:38 am or.... optix

This thread is about CUDA support under disguise: being able to compile the GPU kernel only once is one of the requirement to be able to support CUDA. But it is a long way.