Hi there.
I saw the Baikal initiative, I think it's what it's behind Radeon Pro Render, but I found interesting that it has an OpenCL based AI denoiser that seems to be pretty good.
The libraries are under MIT license, so I think there should be no problem, and in general they work accross all the GPU's, AMD and Nvidia.
https://github.com/GPUOpen-LibrariesAnd ... der-Baikal
@dade do you think this could be interesting to get a faster denoiser? specially for "real time" viewport denoise, Optix viewport denoiser is pretty fast and it makes way easier the shading/lighting tasks.
Do you find interesting the use of Baikal for the OpenCL denoiser?
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
I don't see any problem in integrating another denoiser but it is worth doing if they provide some significative advantage over what we have now. Do theyjuangea wrote: ↑Mon Jan 27, 2020 4:08 pm Hi there.
I saw the Baikal initiative, I think it's what it's behind Radeon Pro Render, but I found interesting that it has an OpenCL based AI denoiser that seems to be pretty good.
The libraries are under MIT license, so I think there should be no problem, and in general they work accross all the GPU's, AMD and Nvidia.
https://github.com/GPUOpen-LibrariesAnd ... der-Baikal
@dade do you think this could be interesting to get a faster denoiser? specially for "real time" viewport denoise, Optix viewport denoiser is pretty fast and it makes way easier the shading/lighting tasks.
Integrating a denoiser can be a trivial amount of work (like with Intel Oidn) or a huge amount of work (like with BDC). So, some consideration about the cost/benefits should be done too. But, first of all, they must provide something new/better otherwise it is not worth add another amount of code to maintain.
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
Theoretically this would benefit nearly instant denoise in viewport, since it's GPU based it should be way faster, and it could provide better feedback faster because right now we have to wait a defined amount of time before we can see anything in the viewport, specially on interior scenes, for example the veryminimum is 10 seconds, hopefuly with this we can have very fast denoising in less than a second so delier several denoise phases without a real penalty for the denoise, and maintain the render refinement in viewport, so it gets improved more and more.
It's something along the lines of what the Optix denoiser does right now in Cycles (it's not in master yet, but it's in our build if you want to test it, in graphicall)
It's something along the lines of what the Optix denoiser does right now in Cycles (it's not in master yet, but it's in our build if you want to test it, in graphicall)
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
The bottleneck may be some part of Python interpreted code and not the denoiser itself, Intel Oidn requires less than 1 sec for medium/low resolutions here and 3-4 secs for 2K+. B.Y.O.B.juangea wrote: ↑Tue Jan 28, 2020 10:05 am Theoretically this would benefit nearly instant denoise in viewport, since it's GPU based it should be way faster, and it could provide better feedback faster because right now we have to wait a defined amount of time before we can see anything in the viewport, specially on interior scenes, for example the veryminimum is 10 seconds, hopefuly with this we can have very fast denoising in less than a second so delier several denoise phases without a real penalty for the denoise, and maintain the render refinement in viewport, so it gets improved more and more.
It's something along the lines of what the Optix denoiser does right now in Cycles (it's not in master yet, but it's in our build if you want to test it, in graphicall)
We could implement viewport denoising in C++ inside PyLuxCore like we have done for many other slow Python parts.
P.S. what kind of resolution do you have in mind ?
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
None specifically, usually in Cycles I tend to leave the whole viewport, so it depends on the computer I'm working and the screen, some could be bigger than 3k, others may be smaller than 1080p, but with LUx I'm used to do region, at the very least the camera fustrum, because while Lux is faster in final rendering than cycles it's true that we get to see more in less time with cycles, also since we use mainly CPU for viewport, we are limited to the speed provided by the CPU, for a big TR it's not a problem, but for an old i7-5960X it's a bit slow, so I tend to do small regions.
In the case of optix it takes less than a second, it's practically instantaneous, but if it's around a second, but we can leave it refining (I talked about this with B.Y.O.B. yesterday) could be more than enough, the "bad" thing is that OIDN depends on the CPU speed, while an OpenCL denoiser will depend on the GPU speed, and the GPU will usually be faster than the CPU, at least in my testing, even with the big TR.
But if you think with OIDN we can get nearly real time performance then may not be worh the idea of adding Baikal, just further iterate the viewport rendering method with what we have already in Lux
In the case of optix it takes less than a second, it's practically instantaneous, but if it's around a second, but we can leave it refining (I talked about this with B.Y.O.B. yesterday) could be more than enough, the "bad" thing is that OIDN depends on the CPU speed, while an OpenCL denoiser will depend on the GPU speed, and the GPU will usually be faster than the CPU, at least in my testing, even with the big TR.
But if you think with OIDN we can get nearly real time performance then may not be worh the idea of adding Baikal, just further iterate the viewport rendering method with what we have already in Lux
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
The addon saves the viewport rendered image as a PFM file in Python, however this is pretty fast and not really a problem.
Here is the log of a viewport denoising:
Code: Select all
writing pfm took 0.014 s
writing pfm took 0.013 s
writing pfm took 0.013 s
Loading input
Resolution: 1920x1032
Initializing
version=1.0.0, msec=17.3379
Denoising 100%
msec=1433.49
Saving output
loading pfm took 0.019 s
assigning to bgl.Buffer took 0.630 s
- Writing 3 PFM files for combined, normals and albedo takes 0.04 seconds
- OIDN takes 1.433 seconds to denoise
- Loading the resulting PFM file takes 0.019 seconds
- Transferring the loaded array of pixels into Blender's bgl.Buffer takes 0.63 seconds.
However, for viewport denoising two things are very important:
- The denoising has to be performed asynchronously in the background, it must never lock Blender
- My Blender addon needs the option to cancel the denoising at any time (when the user edits the viewport while the denoiser is running)
About Baikal:
Before doing any programming work, we need to check if it actually performs better than OIDN.
We need some benchmarking of denoising times, (V)RAM usage, resulting images, and ground truth images (noise-free without denoiser) to compare against.
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
It doesn't sounds like a lot of time for 1920x1032, how much faster is Optix ? Does it make a difference (i.e. it is something like 10x times faster) ?
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
@B.Y.O.B. I'm not sure how could we use Baikal separatedly, I agree, could be very interesting (and something needed) to do some proper testing before deciding anything.
BTW: I have some more information here:
https://radeon-pro.github.io/RadeonProR ... oiser.html
It seems the AI Denoiser uses not just the Albedo and the Normal pass but also the Depth pass.
BTW: I have some more information here:
https://radeon-pro.github.io/RadeonProR ... oiser.html
It seems the AI Denoiser uses not just the Albedo and the Normal pass but also the Depth pass.
Re: Do you find interesting the use of Baikal for the OpenCL denoiser?
about 3 months ago i mention in feature pull if anyone interested in AMD AI-Denoiser, and i still think its a good idea.
I think there are some limitations of using AI-Denoiser on mac os but it shouldn't be a problem, because it will run in CPU basic mode.i found AMD AI-Denoiser interesting, did anyone ever consider it. and of course there are so many other filters available with API.
https://radeon-pro.github.io/RadeonProR ... rning.html
And it's already integrated in blender and blender source code is available, so maybe that's helping too.To be run on GPU, the ML filter requires Windows or Linux OS. Otherwise, the denoiser will switch to its CPU-based mode.
Omid Ghotbi (TAO)
Last update information
viewtopic.php?p=34390#p34390
My Artstation https://www.artstation.com/omidghotbi
My Instagram https://www.instagram.com/omid.ghotbi
Last update information
viewtopic.php?p=34390#p34390
My Artstation https://www.artstation.com/omidghotbi
My Instagram https://www.instagram.com/omid.ghotbi