Cycle X (and OpenCL)

Discussion related to the LuxCore functionality, implementations and API.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Cycle X (and OpenCL)

Post by Sharlybg »

Dade wrote: Sun Apr 25, 2021 9:49 am
Dez! wrote: Sun Apr 25, 2021 12:58 am I didn't understand the situation. Are we in a panic?
No but there is quite big strategic decision ahead: what to do ? And how to get there ?

My current feeling is to start to make (most of) CPU code compatible with CUDA C++: you can compile the code with a normal C++ compiler for CPUs or with CUDA for CPUs and GPUs.
At that point I would have all the building blocks to write new CUDA-only render engines solving a long list of problems:

1) One single source code (no more C++ and OpenCL C code for the same stuff). The current code is expansive to maintain (i.e. it slows down the development of new feature);

2) Writing a new material in OpenCL C is currently mind bending. Writing the interpreted code is extremely hard (i.e. I'm the only one who has ever done it and it is likely to ever do). Plain C++ will solve the problem.

3) Solving #2 would finally allow me to introduce a new material system (or better to extend the current options).

4) Having all the same building blocks available both for CPUs and GPUs would allow to have the same rendering engines available for both: stuff like BiDir on GPUs, light tracing on GPUs, etc.

5) more fine grained control of GPU memory would allow to have a scene editing on GPU as fast as CPU editing;

And more.

This is what the stinky corpse of OpenCL is costing us at the moment. The draw back is to sell our bodies and souls to NVIDIA.

Blender Foundation is effectively locking in all Blender user base with NVIDIA. Don't have any doubt: if you think to have Cycle X for AMD or Intel, you are drunk. The technical architecture of Cycle X has CUDA written all over the places. There is never going to be a fully functional Cycles X outside CUDA. The best case scenario is to have an half broken support like current Cycle OpenCL support.

Are we going to lock in all LuxCore user base with NVIDIA too ?
Maybe it can allow GPU light cache compute (a bit like Unreal GPU Lightmass ).
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Cycle X (and OpenCL)

Post by lacilaci »

Sharlybg wrote: Thu May 06, 2021 3:44 pm
Dade wrote: Sun Apr 25, 2021 9:49 am
Dez! wrote: Sun Apr 25, 2021 12:58 am I didn't understand the situation. Are we in a panic?
No but there is quite big strategic decision ahead: what to do ? And how to get there ?

My current feeling is to start to make (most of) CPU code compatible with CUDA C++: you can compile the code with a normal C++ compiler for CPUs or with CUDA for CPUs and GPUs.
At that point I would have all the building blocks to write new CUDA-only render engines solving a long list of problems:

1) One single source code (no more C++ and OpenCL C code for the same stuff). The current code is expansive to maintain (i.e. it slows down the development of new feature);

2) Writing a new material in OpenCL C is currently mind bending. Writing the interpreted code is extremely hard (i.e. I'm the only one who has ever done it and it is likely to ever do). Plain C++ will solve the problem.

3) Solving #2 would finally allow me to introduce a new material system (or better to extend the current options).

4) Having all the same building blocks available both for CPUs and GPUs would allow to have the same rendering engines available for both: stuff like BiDir on GPUs, light tracing on GPUs, etc.

5) more fine grained control of GPU memory would allow to have a scene editing on GPU as fast as CPU editing;

And more.

This is what the stinky corpse of OpenCL is costing us at the moment. The draw back is to sell our bodies and souls to NVIDIA.

Blender Foundation is effectively locking in all Blender user base with NVIDIA. Don't have any doubt: if you think to have Cycle X for AMD or Intel, you are drunk. The technical architecture of Cycle X has CUDA written all over the places. There is never going to be a fully functional Cycles X outside CUDA. The best case scenario is to have an half broken support like current Cycle OpenCL support.

Are we going to lock in all LuxCore user base with NVIDIA too ?
Maybe it can allow GPU light cache compute (a bit like Unreal GPU Lightmass ).
GPU lightmass is literally just rendering low res textures to be used as lightmap/for lighting. It is just a faster and somehow better lightmass renderer(old one was on CPU and afaik only photon based lightmapping - so a lot of leaks and settings to tweak)

This is no future for rendering. I hope that UE5 can provide offline rendering quality gi instead of lightmass/GPU lightmass cause it's still pain to use:
You still need proper UV maps with proper density and heavier scenes might take as long to render as an offline rendering. Then you change one thing in scene and you need to recalculate everything cause it is not possible to change only local lightmaps...

Honestly. Biggest dragdown in luxcore I find right now is render startup. You drop few models and few high res textures and from getting data from blender to starting luxcore rendering can be in some cases even longer than the rendering.

I know it's a different thing for cycles since it is blender integrated tool. But even octane that has to move scene data from blender to octane server does this super fast.

This compounds to some insane times when rendering animations.

I do hope that blender devs making persistent data doable for cycles will help luxcore too. Luxcore can still beat even cycles x in many cases but it's all for nothing if I Everytime I press render Im repeating same process of exporting all the same stuff to the renderer.

All the design process and iterations starts to drag down the whole work completion time to some crazy amount so in the end cycles x being 5x slower is still very fast...
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Cycle X (and OpenCL)

Post by Sharlybg »

Yes sure i understand. I am running an animation currently while wondering if i can't render multiple frame at once because of reload everything
each time. But the feature seem to be already in place as Dade said it is Blendluxcore side now to make it available for user. ;)
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Cycle X (and OpenCL)

Post by juangea »

Octane uses a custom build and they implemented their own export system, so it’s not comparable to LuxCore which is a pure addon, the majority of problems come from the very own limitation due to Blender Python API
User avatar
MetinSeven
Posts: 137
Joined: Sun Aug 18, 2019 10:19 am
Location: Netherlands
Contact:

Re: Cycle X (and OpenCL)

Post by MetinSeven »

What about Luxcore macOS, preferably utilizing Metal, but at least optimized for ARM / Apple Silicon?

I'm not going along with the NVIDIA bias of the Blender devs, and would love to see Luxcore take the lead when it comes to macOS support.

I'm planning a return to macOS, hopefully if later this year more powerful iMacs will be released, and would love being able to keep using Luxcore without (real) drawbacks compared to using a Windows PC + NVIDIA GPU.

Thanks.
visualizer • illustrator • animator • 3D designer — metinseven.nl
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Cycle X (and OpenCL)

Post by juangea »

You are right for this, but it's not related to OpenCL right now I think (correct me if I'm wrong).

To support M1 and other similar ones on Mac AFAIK the required technology is Metal, and for that there is a need for an specialised developer, so in the end I don't think it goes against what has been said here, the thing is that in general OpenCL is dead and dragging the general evolution of the engine, and Metal is a different leg of all this I think.

I also agree that support for the M1's and successors can be a great thing for LuxCore, however Metal/Others will come sooner than what people think.
User avatar
MetinSeven
Posts: 137
Joined: Sun Aug 18, 2019 10:19 am
Location: Netherlands
Contact:

Re: Cycle X (and OpenCL)

Post by MetinSeven »

Yeah, sorry, I'm deviating a bit from the OpenCL discussion. :oops:

I just love Luxcore and really hope my transition to macOS won't become a handicap when it comes to using Lux.

By the way, I recently had an interesting discussion with the developer of MoI 3D about the relativity of the necessity to use Metal to get the most out of macOS computing power.
visualizer • illustrator • animator • 3D designer — metinseven.nl
juangea
Donor
Donor
Posts: 332
Joined: Thu Jan 02, 2020 6:23 pm

Re: Cycle X (and OpenCL)

Post by juangea »

I don't think you are deviating, it's logical to link one thing with the other.

It's just that I think the situation is a bit different :)

But I may be wrong, Dade would know better :)
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Cycle X (and OpenCL)

Post by Dade »

juangea wrote: Wed May 19, 2021 7:22 pm But I may be wrong, Dade would know better :)
It is about finding someone who want to port and/or write the code. At moment, we have no one. I think no developer or platform maintainer has a M1 Mac.
Support LuxCoreRender project with salts and bounties
User avatar
MetinSeven
Posts: 137
Joined: Sun Aug 18, 2019 10:19 am
Location: Netherlands
Contact:

Re: Cycle X (and OpenCL)

Post by MetinSeven »

I understand. I really hope Luxcore will get more developer attention and funding. I would definitely start funding Luxcore if that would enable someone to spend more time on macOS development.

I'm glad to see that U3Dreal in the Luxcore Discord (the 'Luxcord' ;) ) is already supporting ARM Macs. That's an important step.
visualizer • illustrator • animator • 3D designer — metinseven.nl
Post Reply