Cycle X (and OpenCL)

Discussion related to the LuxCore functionality, implementations and API.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: Cycle X (and OpenCL)

Post by lacilaci »

Well...
Nvidia will actively look for devs doing rendering using their tech and they will actively support them. We've seen this few times, even cycles got optix support done by nvidia person and they also have a lot of tools and branches for unreal engine and they support game devs and assist to use their tech...

Yes, they do it in their own interest but you have to ask yourself, wtf is amd and intel doing? Apple has new m# arm chips that put to shame powerful cpus even with passive cooling and they also support devs utilizing metal.. But again, what is amd and intel doing? Amd stacks cores on top of cores in their cpus and intel is just adding numbers to their naming scheme.

As a "normal" end user I don't really see any benefit for cpu rendering or gpu rendering other than nvidia and it's been like this for years now... I don't even remember any client or someone I know or work with that uses cpu rendering and for gpu rendering everyone I know is using nvidia hw cause everything else is more or less trash.
CodeHD
Donor
Donor
Posts: 437
Joined: Tue Dec 11, 2018 12:38 pm
Location: Germany

Re: Cycle X (and OpenCL)

Post by CodeHD »

Really interesting to see this new development - and your comments as well as future plans about it, Dade.
I have only seen this now, as I have taken too little time recently to follow this board despite my continued interest in the topic.

One question to follow up one the LuxCore development: Would you consider this to become a "LuxCoreRender 3.x"?
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 »

CodeHD wrote: Tue Apr 27, 2021 9:53 pm One question to follow up one the LuxCore development: Would you consider this to become a "LuxCoreRender 3.x"?
I have already, it is a bit useless but, I guess, we can rise the hype like everyone seem eager to do nowadays.
Support LuxCoreRender project with salts and bounties
JulianoLisboa
Posts: 146
Joined: Sat Feb 22, 2020 3:29 am

Re: Cycle X (and OpenCL)

Post by JulianoLisboa »

Dade wrote: Tue Apr 27, 2021 10:59 pm
CodeHD wrote: Tue Apr 27, 2021 9:53 pm One question to follow up one the LuxCore development: Would you consider this to become a "LuxCoreRender 3.x"?
I have already, it is a bit useless but, I guess, we can rise the hype like everyone seem eager to do nowadays.
Does this mean that we can already use bidir or ligth tracing over the GPU?
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 »

JulianoLisboa wrote: Wed Apr 28, 2021 4:07 am
Dade wrote: Tue Apr 27, 2021 10:59 pm
CodeHD wrote: Tue Apr 27, 2021 9:53 pm One question to follow up one the LuxCore development: Would you consider this to become a "LuxCoreRender 3.x"?
I have already, it is a bit useless but, I guess, we can rise the hype like everyone seem eager to do nowadays.
Does this mean that we can already use bidir or ligth tracing over the GPU?
He is just saying to consider to use new name for the new version not that he have an early code of the hypothetical Luxcore 3.0. As he say before it is a lot of work and we shouldn't hold breath :mrgreen: .

About new name i think yes it is really useless from a Development and performance point of view but It help non programmer understand that there is probably a performance and or Feature gap with the new software. So people start to take a look ask about and the hype start. A bit of Hype is what We need :mrgreen:
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 »

Agree, a bit of communication and knowledge by people is needed, many people don't even know LuxCore at all, I'm amazed because even subscriptors to my youtube channel don't know LuxCore engine even when I have several videos about it, so more PR is needed no matter what, and I think, we users, have a big responsibility on it :)
JulianoLisboa
Posts: 146
Joined: Sat Feb 22, 2020 3:29 am

Re: Cycle X (and OpenCL)

Post by JulianoLisboa »

Sharlybg wrote: Wed Apr 28, 2021 8:55 am
JulianoLisboa wrote: Wed Apr 28, 2021 4:07 am
Dade wrote: Tue Apr 27, 2021 10:59 pm

I have already, it is a bit useless but, I guess, we can rise the hype like everyone seem eager to do nowadays.
Does this mean that we can already use bidir or ligth tracing over the GPU?
He is just saying to consider to use new name for the new version not that he have an early code of the hypothetical Luxcore 3.0. As he say before it is a lot of work and we shouldn't hold breath :mrgreen: .

About new name i think yes it is really useless from a Development and performance point of view but It help non programmer understand that there is probably a performance and or Feature gap with the new software. So people start to take a look ask about and the hype start. A bit of Hype is what We need :mrgreen:
Oh my god, sorry. The google translation made me misunderstand. I feel ashamed. I hope you understand that I am a great admirer of Luxcore, yesterday in a Portuguese live about Cycles X, I talked about Luxcore so much in the chat that the live ended up being a comparison of Cycles with Luxcore. Having attracted a few more users to him. I will look forward to version 3.0
CodeHD
Donor
Donor
Posts: 437
Joined: Tue Dec 11, 2018 12:38 pm
Location: Germany

Re: Cycle X (and OpenCL)

Post by CodeHD »

Dade wrote: Tue Apr 27, 2021 10:59 pm
CodeHD wrote: Tue Apr 27, 2021 9:53 pm One question to follow up one the LuxCore development: Would you consider this to become a "LuxCoreRender 3.x"?
I have already, it is a bit useless but, I guess, we can rise the hype like everyone seem eager to do nowadays.
I should clarify that I don't actually care about the name myself (sorry for putting in in other's heads :D )
What I was interested in is wether the material rewrite etc. that you consider during this would - in your view - make it such a significant difference;
or, if the major framework would reamin the same.
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 »

CodeHD wrote: Wed Apr 28, 2021 5:05 pm What I was interested in is wether the material rewrite etc. that you consider during this would - in your view - make it such a significant difference;
My idea is to have a smaller granularity: current materials will be the result of combining B(R/T)DF in various way. It will like the old LuxRender did materials (as sum, layers, etc. of BRDF/BTDF) however that architecture was never exposed to the user.

This solution doesn't break SDL (Scene Description Language) compatibility but allow an (optional) more fine control over materials allowing to build custom one (at SDL level, without having to write code).
Support LuxCoreRender project with salts and bounties
bestman8
Posts: 16
Joined: Sat Jul 25, 2020 6:45 pm

Re: Cycle X (and OpenCL)

Post by bestman8 »

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 ?
the current opencl has already a lot of issues on amd gpu's so if not supporting it will have all those benefits is there really a choice to make?
it might not harm to have a version with opencl avalible but maybe just updates for blender version and not new features (unless they are very small and dont cost any real amount of time to implament).
Post Reply