MNEE: Brecht will commit the patch this week. Olivier is still looking into some improvements and Metal support is disabled, but this should not block things.
Light Groups: Lukas is reviewing, Brecht will help where needed, still planned to be committed for 3.2.
AMD HIP: Brian mentions ROCm 5.1 driver for Linux is planned to be released this week. Brecht will then update buildbot with the latest compiler version and we can enable it. AMD Vega cards were enabled on Windows, but it’s still failing for some scenes/cards, Brian investigates. The AMD HIP Windows SDK also needs to be updated, potentially this may solve some issues.
Color Management: there was a new ACES configuration released from the OpenColorIO project, which is aimed to be a more user friendly and light version that can work well for apps like Blender. Brecht is working on various changes to ensure Blender works well with this configuration.
Cycles Development
Sebastian announced the Intel Open Path Guiding Library, and his work to integrate this into Cycles. A patch to integrate this into Cycles will become public later, it’s still under development. The first version would be CPU only, but GPU support is planned. First priority is to improve handling of more complex BSDFs with multiple lobes.
Stefan presented the Intel OneAPI backend, aimed at new discrete Intel GPUs. It was mainly developed by Nikita Sirgienko. Ideally this could be integrated in Blender 3.2 to go along with hardware releases, but the deadline is very tight, so this is unclear still.
Patrick contributed a Hydra Render Delegate, that allows Cycles to be integrated into other applications such as Omniverse, usdview and Houdini. However note that this is not currently an officially supported feature. The build process is currently quite rough and any help making it easier is welcome. In particular each application uses different library versions, and Cycles should be compiled with compatible versions.
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.
Just wondering: is the Intel Open Path Guiding Library only compatible with Intel chipsets or will it be enabled for Apple Silicon / Metal as well in the near future?
Since it will be CPU only in the beginning, will there be a toggle to enable/disable it to ensure consistent results when rendering an animation where some frames are on the CPU and some frames are on the GPU at the same sample counts?
Requests for assisting in picking a new GPU is best to be asked elsewhere. As for your other questions, I will try to answer them as best as I can:
I am 99.99% certain the answer is yes with regard to Cycles rendering.
Maybe. According to the patch for OneAPI support in Blender, it reads.
Being based on the open SYCL standard, this implementation could also be extended to run on other compatible stacks in the future.
Whether or not this will happen is a different story.
I don’t know. You will get a better answer from someone with more knowledge than me.
If you’re asking “What GPUs are planned to be supported in Cycles HIP with ROCm 5.1 on Linux?” the answer is “AMD Vega and newer discrete GPUs”. However, this could change. Vega support might be removed. Support might be extended to older GPUs like Polaris. I can not predict the future with 100% accuracy. At the very least, RDNA2 and newer discrete GPUs will be supported initially.
There are plans to optimize performance on the CPU in Cycles. For example, this task: https://developer.blender.org/T92572 . How quickly these optimizations get implemented is based on various factors.
The guiding feature will be something you can turn on and off as you like.
By default, it will be probably disabled and you can turn it on if you want.
We build our SIMD optimization on the same code base Embree does.
So Apple Silicon support might already be there but is not tested yet.
The plan is to have CPU based guiding running on all major systems Blender
supports when we release it (unless I am missing some strange experimental platform ;)).
I haven’t tested it (don’t have an AMD CPU here), but I’m not aware of anything preventing it and it certainly is our intention to support Arc GPUs wherever possible.
In theory, yes. The OSS version of the DPC++ compiler includes its own HIP plugin. In practice, I would expect that native HIP will remain the most performant and best supported method of using AMD GPUs in Cycles.
I have not requested assistance to buy new GPU but i will evaluate by myself based on the information i can receive ( In fact it was not in the question list ).
And i am pretty sure that if i ask assistance elsewhere most of the people will suggest to buy the green solution that work only with proprietary drivers.
Anyway thank you for the answers.
Apparently finally we have good news for who wants to use Cycles with GPU that work with free and open source drivers in GNU/Linux.
Thank you, for what i read Intel OneAPI should be an open solution.
This is very interesting but i do not understand if you will still need ROCm under GNU/Linux.
I would be also cool if we could use AMD and Intel GPU in the same system ( just Intel OneAPI or Intel OneAPI + ROCm ).
Anyway good news, thank you.
Just to make sure that there is no misunderstanding:
For using Cycles on Intel GPUs, there’s oneAPI. This is what we at Intel are working on.
For using Cycles on AMD GPUs, there’s HIP. AMD is working on that.
Using Cycles on Intel and AMD GPUs simultaneously, there is no solution for this right now and I am not aware of anyone working on that.
The “theory” that one day in future we could work with a single free and open source backend is fascinating, so i wish a collaboration in that direction
For platforms we ship you missed nothing, for architectures downstream users are shipping you may have missed a few however as long as the dep is optional and blender can be build without it, this shouldn’t be a problem.
Introducing Orochi - dynamic loading of HIP/CUDA® from a single binary - GPUOpen I mentioned in the meeting. Here is the common CUDA / HIP kernel launch library. Would replace CLEW and HIPEW in Blender code and more. Of course this is new and being able to support Intel and further lesson code deduplication would be great.
curious how to obtain “AMD HIP Windows SDK” for other purposes than Blender building?
right now we have ROCM SDK 5.1 released for Linux only officially…
I’m assuming it’s including also ROCM compiler stack in addition to possible amdhip linking library and headers for Windows…
Hi @lukasstockner97
Nice to see Light Groups finally landed into Blender, thanks!
I’d like to ask, will it be possible to render several HDRi as different Light Groups at once?
