We want to avoid dependency of OSL build on CUDA toolkit and OptiX. OptiX is easy to remove, CUDA may be possible by using clang though this has some issues currently. For OSL the plan seems to be for this to not be a requirement at all, but timeline is unknown.
One missing feature is image texture loading through file paths, may be possible to make it work by querying OSL shader and loading in advance?
Intel oneAPI:
Patches for oneAPI linking and kernel profiling needed review, hopefully done this week.
Stefan looks into adding support for using host memory fallback.
AMD HIP
There is a performance regression related to matrix inverse changes, will be looked into.
Hardware ray-tracing aimed for Blender 3.5.
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.
Is there any information that can be shared as to why AMD Hardware ray-tracing changed from being aimed at 3.4 or earlier about 4 months ago to the current aimed for Blender 3.5? Just curious what difficulties are being encountered.
@MetinSeven GPU support will still take some time.
We first want to figure out how to do path guiding robustly in a production context.
When this is done we gonna focus on porting our learned lessons to the GPU.
If I had to guess, I’d say it’s related to the upcoming RDNA3 launch. They probably don’t want to launch HIP-RT until it supports RDNA3, as raytracing performance on RDNA2 is kinda lackluster. So marketing, really.
All development planning is rough estimates. Something else might come up that needs attention, some implementation may take a bit more work that planned, etc.
We’re being open with Blender development process, please don’t use that as an opportunity to invent a narrative about development being postponed due to marketing, that’s just not true. Not saying there is any ill intent, just remember this forum is for collaborating with developers.
I have been doing some tests with the latest branch build on Blenderartists and noticed that path guiding can be a bit hit and miss. Sometimes the guiding finds the difficult paths and sometimes not.
I guess its doing some sort of random sampling and sometimes simply misses. I have posted some images to illustrate:
A question has been asked about how this might affect animation - does the guiding algorithm remember the paths between frames - or does this have the potential to cause flicker between frames (i.e. is path guiding temporally stable)?
Note that path guiding is not designed for caustics, it can help with them but that’s more of a side effect. If you use it to render effects like that, where some very bright paths are rarely detected, the result will not be temporally stable in general.
Path Guiding in Cycles using OpenPGL is officially supported on the platforms Blender is officially distributed on. That’s Windows (x86), Linux (x86), MacOS (ARM and x86).
is it possible to implement Hip-RT on AMDGPU open source? because it would be much easier to work with AMD cards on Linux with free drivers, RT is for game so I believe it is possible and no need to install driver, specially for other distros (I use Manjaro), or if not implemening EEVEE+RT shadows also I think would be a good combination, what about other options for render like Vulkan?
