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
.
https://developer.blender.org/rB286e535071c8f9a906c6c36b8dac0eda6384c79a
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 (blender.org)
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 ā¦
And Cycles texture mipmapping/tilecache
Thanks Patrick!
Meanwhile, the Path Guiding branch is seeing daily activity again, but the buildbot for it was taken down.
Among the things being done is allowing the user to set how long the training set for a particular image will be updated as well as an option for deterministic guiding (not to mention guiding for emissive volumes and fixes).
[2022-09-06 Render & Cycles Meeting]
Attendees
- Brecht Van Lommel (Blender)
- Thomas Dinges (Blender)
- Christophe Hery (Meta)
- Brian Savery (AMD)
- Nikita Sirgienko (Intel)
- Stefan Wener (Intel)
- Patrick Mours (NVIDIA)
- Michael Jones (Apple)
Notes
- Blender 3.3 release:
- oneAPI: improvement to fallback to host memory when out of GPU memory was added.
- Metal: last minute fix for macOS 13 Beta render errors will be committed.
- Open Shading Language: Patrick worked on GPU support, a patch will be submitted soon. OSL itself supports only CPU and OptiX currently, but oneAPI support is also under development, and hopefully more GPU backends will follow.
- AMD HIP: ROCm 5.3 with Linux texture bug fix planned to be released soon, hardware ray-tracing is under development.
- Path guiding: Sebastian is working on solving remaining to doās, plan is to get this ready for Blender 3.4.
- Many lights sampling: summer of code project is ending. There is still work to be done, Brecht plans to continue this and student also may be around later in the year.
- Subsurface scattering: Christophe has a patch for taking into the IOR for the scattering direction. However one issue is that this may require another parameter to blend between diffuse and GGX transmission, since fully doing GGX may not be ideal in practice.
- MNEE: Michael looked into supporting this on Metal. Increasing the register spilling limit in the driver will be one solution. Another would be to reduce spilling, by for example moving closures to global memory.
Cool!
I really hope the new and improved Principled shader will also be ready for Master soon.
Yeah. Path Guiding looks great!
But its hard to predict when Principled V2 lands. It hasnāt been updated in some time, as Lukas was working in other areas. Also import/export compatibility might complicate some things.
I was testing it some time ago and roughness improvements are very noticeable.