The announcement that the OpenCL rendering kernels were dropped is something that we got a lot of feedback on. We’d like to announce more about ongoing work with GPU vendors to bring support back in other forms, but it will take some time until we can do that.
Juan is working on documentation and images for light spread. He also suggest support light spread angle 0 for projectors, Brecht will add it to the list of things to improve for sampling light spread.
Eevee & Viewport
The crashes on selection with NVIDIA cards is looking like a bug in VBO garbage collection. Appears to be up to Clément now to find the issue, as this is not a driver bug as far as we can tell.
Kévin continued working on OpenSubdiv GPU support. He has some initial meshes displaying in the viewport but results are not correct yet.
Practical Info
This is a weekly video chat meeting for planning and discussion of Blender rendering development. Any contributor (developer, UI/UX designer, writer, …) working on rendering in Blender is welcome to join and add proposed items to the agenda.
For users and other interested parties, we ask to read the meeting notes instead so that the meeting can remain focused.
would it be possible for me to attend the meeting? I am working on the crowdrender addon, so definitely rendering in Blender related. Keen to have some input into the cycles API/addon. We currently have a limited ability to interact with cycles and would love to propose some changes that are fairly small, but would allow us, and others to use cycles in a far more efficient manner.
The meeting is for contributors. If you plan to contribute improvements, it can be proposed and organized in the meeting. If it’s for support or requests, post it in the forums here.
Yes, we’re planning on making a contribution to enhance the way cycles can be used from python scripts. How do I make a proposal exactly? Do I just fill in the google sheet and then attend the meeting?
To propose a design change or addition, you can make a topic in the forum here or submit a patch on developer.blender.org. Then to bring that to the attention of the meeting, you can add a link to it in the Google doc.
We try to keep the meetings quick and efficient, so it’s not so much the place to present ideas for the first time, but rather to coordinate work and make decisions.
The announcement that the OpenCL rendering kernels were dropped is something that we got a lot of feedback on. We’d like to announce more about ongoing work with GPU vendors to bring support back in other forms, but it will take some time until we can do that.
As someone with AMD GPU hardware, but fully aware of how OpenCL has stalled in recent years, and it’s deficiencies in comparison to CUDA/OptiX, and with familiarity of the tough choices that sometimes have to be made in development, I fully understood the vibe of the announcement that OpenCL’s rendering kernels will be dropped.
I absolutely understand the decision and I have absolute confidence that Blender Foundation is committed to finding another solution to support AMD GPUs as soon as possible.
However this does put me in a difficult position. My main compute device for rendering is an AMD GPU…
Hypothetically, lets say Blender 3.1 releases with a merged Cycles X, but no AMD GPU support yet.
My options would be:
Switch to CPU-Only. The performance of this would be unacceptably slow for my fast paced job.
Stay on Blender 3.0 indefinitely until AMD support is added. If this situation persisted for a long time, say 12 months or longer, that would be definitely ‘suck’.
‘Go by an NVIDIA GPU’. I would… if it was that simple. But I think everyone is aware of how hard it is to even find a GPU that isn’t out of stock right now, let alone find a high performance NVIDIA 3000 series GPU for a reasonable price.
I remain optimistic that hopefully there will be an AMD compatible solution merged into Cycles X, before Cycles X is merged into Blender. Either a new OpenCL kernel or a different API entirely.
However, if that isn’t possible, @brecht would it be possible to retain the old OpenCL kernels and the old Cycles as an option for AMD hardware? Like having two separate versions of Cycles in Blender basically, ‘Cycles’ and ‘Cycles X’, with Cycles X only available to CUDA/OptiX. Then when Cycles X is merged, users with AMD GPUs would at least not be hit hard by the performance regression of losing GPU acceleration. Later when Cycles X is compatible with AMD hardware, ‘Cycles’ could be removed.
Having both Cycles and Cycles X in a single Blender version is not something we can do, it’s too complex to implement and maintain. Even more so if we’d have to do that for 12 months or longer. But we expect it will not be that long for AMD GPU support, though it’s hard to make predictions about development timelines.
Thankyou kindly for the response Brecht, and I understand, that makes sense. I figured it probably wouldn’t be possible, otherwise it would already be the plan, but also figured it didn’t hurt to ask anyway.
I have development experience as well and I know what you mean about it being hard to make predictions for development timelines. Hard to put a number on a process like that.
I appreciate all the hard work, and I’m sure it’ll be all fine in the long run.
Thankyou @bsavery for the reply! I hope I didn’t sound like I was whinging, and I still have full confidence that the team is doing the best that can and as fast as possible. I appreciate all the hard work and the support that AMD and yourselves are offering to Blender. Cheers.
And we’re working on Cycles-X support