Page 4 of 10
Re: Cycle X (and OpenCL)
Posted: Tue Apr 27, 2021 1:10 pm
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.
Re: Cycle X (and OpenCL)
Posted: Tue Apr 27, 2021 9:53 pm
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"?
Re: Cycle X (and OpenCL)
Posted: Tue Apr 27, 2021 10:59 pm
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.
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 4:07 am
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?
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 8:55 am
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
.
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
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 9:29 am
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
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 12:26 pm
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
.
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
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
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 5:05 pm
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
)
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.
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 6:35 pm
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).
Re: Cycle X (and OpenCL)
Posted: Wed Apr 28, 2021 7:23 pm
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).