Cycles Development Updates

63 posts were merged into an existing topic: Cycles Spectral Rendering

Attendees

  • Brecht Van Lommel (Blender)
  • Christophe Hery (Meta)
  • Brian Savery (AMD)
  • Nikita Sirgienko (Intel)
  • Patrick Mours (NVIDIA)
  • Jeffrey Liu

Notes

  • Intel OneAPI: support for this landed in Blender 3.3. For anyone with an Intel Arc GPU, feedback is welcome. The main remaining issue for the 3.3 release is ahead-of-time compilation.
  • AMD HIP: the main issue right now is the texture resolution bug on Vega/RDNA, we are hoping it will be fixed in ROCm 5.3 but this is not clear yet.
  • Apple Metal: two optimizations landed in the past few weeks, for shader sorting and intersection kernel specialization.
  • Path guiding: this was submitted for code review, currently waiting for a new OpenPGL release and updated patch. There will also be a meeting soon about integrating MNEE and path guiding.
  • Spectral: various patches from Andrii Symkin are landing to refactor code for this. No actual functionality yet, but important groundwork.
  • Principled v2: Lukas published a branch with an early (incomplete) version, there is a feedback topic with active discussion.
  • Sampling pattern: Lukas made a patch with an improved scrambling method, but more work is needed to optimize it and integrate well.
  • OptiX temporal denoise: Patrick mentions he started working on making this available from the UI.
  • Many Lights: support for surfaces is getting more complete and many issues were fixed (weekly reports, feedback), but still more work needed. From discussion, it appears that adaptive splitting may be important to handle cases where the heuristic is not ideal. Adapting splitting combined with importance resampling to keep just 1 light ray for easy GPU support will be tested.
6 Likes

Still waiting for light linking here :laughing:

1 Like

OK, so the first thing we need to be clear about is it the actual download install file or the size of the installed folder on ones hard drive.

If its the download, Blender 3.2.1 for Windows is currently 213MB, so even at 30% more it would be around 277MB. Granted that’s a bit more, but in the total scheme of the Internet now days, it really isn’t all that much and I speak as someone with a 100GB monthly data limit.

I think that’s really blowing things somewhat out of proportion. We are talking the Cycles core, there’s a good chance it doesn’t even load in at start-up and if you then only use Eevee it may not load at all. So load time and RAM usage is still way way low.

Basic SATA SSD’s are dirt cheap now days for 512GB or less, the CPU/RAM/Motherboard/PSU/GPU and very likely even the case will all individually cost more, so at this stage we just don’t even have a PC, so running Blender is a moot point.

Also, lets look at the irony about all this. On one hand we have some threads and various posts about how people want Cycles to render at ‘better quality’ and here we are talking about an addition to Cycles that will do just that but it’s all too hard because it may make Blender use a little more disk space or a few MB’s more RAM… guess they should stop all work on Geometry Nodes (can’t add any more nodes) or Texture Painting or Sculpting, surely that’s going to make Blender load slower…

1 Like

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.

4 Likes

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

Done.

4 Likes

Ok, thanks.

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

3 Likes

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.

9 Likes

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…

9 Likes

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.

8 Likes

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.

2 Likes

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.

https://developer.blender.org/rB286e535071c8f9a906c6c36b8dac0eda6384c79a

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

3 Likes

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.

2 Likes