Cycle X (and OpenCL)

[Dade]

Today, Blender Foundation has announced Cycle X: https://code.blender.org/2021/04/cycles-x

Aside form the consideration that we were quite right given the list of new features added and old removed: they are introducing a micro-kernel architecture (check, done many years ago), they are dropping tile rendering (check, tile rendering has always been a second grade citizen in LuxCore), volumes stack (check, done many years ago), etc.

They are also dropping OpenCL support.

On one side this is an opportunity for us because we are left as the only OpenCL option available (may be, Indigo Render is still using it too ). On other side, I consider this the official announce of OpenCL death.

R.I.P.

[sarmath]

Hello

Here is very interesting interview with Brecht and Sergey what to expect with some benchmarks...and speed up is jaw dropping

https://www.youtube.com/watch?v=awMjwhJVRMw

[Sharlybg]

They are leaning more toward us now at least in term of architecture. They want also path guiding ( look like our caching feature + light tracing just make them react ).
For the 700% faster i think it is more related to turing and ampere arch more than something else ( The bmw scene is showing the same patern ). Just look like same performance aren't replicated on CPU.
About Opencl and AMD i think unless they come ( AMD and INTEL ) with RtX raytracing performance level artists will just drop them right at the beginning.

[Continuum]

I think OpenCL will be alive in some form for many years to come, Intel has built a ecosystem around it (SyCl, but it only works on Intel GPUs at the moment), and if they do release their promised GPU's it could see a resurgence. AMD HIP looks interesting, but i can't find a way to get it to work on Windows.

I am not a OpenCL fanboy , I just like cross platform comparability. A Vulkan compute would have been nice (since it now supports ray tracing on all hardware). Direct-X, is looking like at attractive option.

Just my thoughts on the issue.

[PetrT]

Cycles X plans looks great
But what NLM denoiser will be removed is not good.

[Dez!]

I didn't understand the situation. Are we in a panic? Or are we all right?

[Sharlybg]

I didn't understand the situation. Are we in a panic? Or are we all right?

Not all. Why go panic when your main competitor restart evrything from zero and decide to follow the same path you are running in since decades ?
We made good decision in the past so we don't have to worry. For me if cycles keep the same graphical look it is a no go. I mean i like realism and in general cycles have this CGI cartoonish look i can't explain even EEVEE was a threat to cycles before this move.

The entiere undustry is moving forward at great pace (look how unreal 4.26 change the film industry and imagine unreal 5). As i say Before offline renderer will need to Up the game a bit more to equilibrate the fight. Anyway there is no Short cut for Maximum Realism (Offline renderer ) And offline renderer will stay king there for comming decades.

[Dade]

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 ?

[juangea]

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.

Keep in mind that OpenCL is dead, but support for AMD and Intel GPU's is not.

They will rewrite a solution to this, probably based on Vulkan but I'm not entirely sure, the target was to fully remove the current OpenCL kernel because it was buggy and delivered A LOT of unsolvable problems (mostly related to drivers), so It's not that Cycles will turn into a CPU / NVidia GPU only render engine, it will be as it has always been, it's just the started with CUDA/Optix.

[Dade]

so It's not that Cycles will turn into a CPU / NVidia GPU only render engine

Uh ? It already is: is there someone using Cycles with OpenCL ? Do you ?

I'm just predicting it will continue to be a CPU/NVIDIA-only solution.