Cycles Development Updates

16 posts were split to a new topic: 7-Zip as a more efficient alternative to Zip for compressing Blender builds

Hi guys, I’ve split the extensive spectral Cycles subdiscussion from this thread to the Cycles Spectral Rendering thread. Please feel free to continue the spectral Cycles discussion there, thanks.


While you’re at it, can you pull the 7zip conversation above out as well?

1 Like

What forum category? It’s not anywhere I typically visit. Following the link takes me directly to the thread, but I’m not seeing where this thread exist.

It’s under artwork > blender tests. The posts were appended to an old spectral rendering test thread.

1 Like



Ok, thanks.

Moved the Cycles Spectral Rendering thread to a more fitting category:


Perhaps it would be a good time for the devs. to stop spending time and money on supporting Intel’s OneAPI for Arc, as a lot of bad news is streaming in as of late.

As of now, Intel’s GPU division is little more than selling broken products to Chinese gamers, they have not improved at all since they hired Raja and other people from AMD. On the plus side, the idea of OneAPI being canceled could be good news for Mac. users hoping for improvements.

Eh, I’d give them a few more months before I start carving the tombstone.

Amd drivers were hot trash for the first half decade of cycles at least, and they had been making GPUs for a decade+ before then, and plenty of people held out hope for that.

It’s not like the blender devs did a bunch of work on it anyway.

But I know how much you love sensational clickbait malarkey, so shine on, you crazy diamond.


It doesn’t matter for the Blender developers. As far as I have seen, pretty much all the commits for OneAPI are coming from Intel developers directly.

Not sure what you mean with that. If the Intel developers stopped contributing OneAPI functionality to Cycles, this would be good for Mac users? How is that? From what I have seen, all the Metal contributions are from Apple developers…


As a consumer, It would be great if we had more competition on the GPU market as that benefits us. I think we should not be too picky about Arc initially and give them a real chance, I could even imagine buying a GPU from them just to help them establish themselves in the market. (Of course there are limits, if they keep messing up over time I would stop support thier products.)

Getting good Arc support in Blender is a nice step in helping strengthen the compitition on the market.


100% Agree there!
It’s great that Intel is contributing to Blender to get their side in order, even if they’ve been stumbling with the drivers for their first discreet gpu lineup.

I really hope they succeed and we can get prices down for everybody.


For all we know, Intel’s raytracing could be substantially faster than AMD’s current RT… which they haven’t even implemented in Cycles yet! The GN benchmarks just don’t show that. And their weak GPU seems to at least do fine in the newest APIs, eventually they might fix the older ones, it IS still their first proper (consumer, non-OEM) GPU and their OneAPI might be fine. AMD being terrible (almost literally 50% less performance, just like intel with dx11 vs dx12) on their official drivers in OpenGL was reported to them for at least 5-6 years and they only fixed it now, and their OpenCL support was buggy before Blender moved on to HIP (not that HIP isn’t buggy), which currently AFAIK only the blender devs have actual proper access to an API for anyways.

They have more GPUs planned after Arc, I doubt they’d just drop all of those as well. Support for OneAPI now might be beneficial in the future when they release better GPUs… Just like support for HIP now when AMD releases better GPUs and RT support…

In the recent commit that simplifies CPU architecture handling, there is mentioned that it will be important for upcoming changes.

I wonder if that means the beginning of long awaited CPU rendering improvements with SIMD?


You could be right because there are now mostly sse and avx, checks. So SIMD would be an obvious candidate. Another option might be half-precision, which he also kept in the code. Though half-precision also makes more sense with SIMD.


PMJ sampling actually does a good job with noise now.
rB50df9caef01a (

This also means faster renders and not only because the algorithm is faster (because this is compatible with adaptive sampling).


My own list of hopes:

  • Render proxys
  • Render Booleans
  • Less GRam usage for motion blur, Dof, Textures etc.
  • Better animation denoising

light linking …


light linking in blender is like this :crazy_face: