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?
Reduce the number of OpenCL kernel compilations
Re: Reduce the number of OpenCL kernel compilations
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).
- FarbigeWelt
- Donor
- Posts: 1046
- Joined: Sun Jul 01, 2018 12:07 pm
- Location: Switzerland
- Contact:
What about (pre-)compiling in background when using BlendLuxCore?
@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.
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.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
MacBook Air with M1
MacBook Air with M1
Re: What about (pre-)compiling in background when using BlendLuxCore?
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.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.
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
Re: Reduce the number of OpenCL kernel compilations
how on earth this can be possible ? what a shameThe 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
Re: What about (pre-)compiling in background when using BlendLuxCore?
Make cpu rendering so fast no one cares about opencl or gpu rendering, problem solved or.... optixDade wrote: ↑Wed Jan 01, 2020 7:04 pmWe 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.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.
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
Re: Reduce the number of OpenCL kernel compilations
There is a reason why theses great renderer are GPU onlyMake cpu rendering so fast no one cares about opencl or gpu rendering, problem solved or.... optix
Fstorm
Octane
Redshift
If we go optix so AMD user will be left on the Dust ?
Re: Reduce the number of OpenCL kernel compilations
there is a reason why fstorm, octane, redshift don't use opencl too
what is putting amd user to dust is opencl not optix.
Re: Reduce the number of OpenCL kernel compilations
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.
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.
Re: What about (pre-)compiling in background when using BlendLuxCore?
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.
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.