Do you find interesting the use of Baikal for the OpenCL denoiser?

Discussion related to the Engine functionality, implementations and API.
Post Reply
juangea
Donor
Posts: 83
Joined: Thu Jan 02, 2020 6:23 pm

Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by juangea » 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.

User avatar
Dade
Developer
Posts: 3741
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by Dade » Tue Jan 28, 2020 9:30 am

juangea 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.
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 they :?:

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.
Support LuxCoreRender project with salts and bounties

juangea
Donor
Posts: 83
Joined: Thu Jan 02, 2020 6:23 pm

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by juangea » 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) :)

User avatar
Dade
Developer
Posts: 3741
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by Dade » Tue Jan 28, 2020 11:18 am

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) :)
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. :?:

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 ?
Support LuxCoreRender project with salts and bounties

juangea
Donor
Posts: 83
Joined: Thu Jan 02, 2020 6:23 pm

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by juangea » Tue Jan 28, 2020 11:28 am

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 :)

User avatar
B.Y.O.B.
Developer
Posts: 3185
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by B.Y.O.B. » Tue Jan 28, 2020 2:13 pm

Dade wrote:
Tue Jan 28, 2020 11:18 am
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. :?:
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
You can see the following times:
  1. Writing 3 PFM files for combined, normals and albedo takes 0.04 seconds
  2. OIDN takes 1.433 seconds to denoise
  3. Loading the resulting PFM file takes 0.019 seconds
  4. Transferring the loaded array of pixels into Blender's bgl.Buffer takes 0.63 seconds.
The last step (transferring data into bgl.Buffer) is something that could be accelerated by using C++ (this code already exists in pyluxcore).

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)
I am currently not using the OIDN imagepipeline plugin because of the second point. The imagepipeline can be run asynchronously, but it cannot be interrupted. A viewport denoising solution in LuxCore would need to make this possible somehow.

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.

User avatar
Dade
Developer
Posts: 3741
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by Dade » Tue Jan 28, 2020 3:11 pm

B.Y.O.B. wrote:
Tue Jan 28, 2020 2:13 pm
[*]OIDN takes 1.433 seconds to denoise
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) ?
Support LuxCoreRender project with salts and bounties

juangea
Donor
Posts: 83
Joined: Thu Jan 02, 2020 6:23 pm

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by juangea » Tue Jan 28, 2020 5:53 pm

@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.

User avatar
TAO
Developer
Posts: 90
Joined: Sun Mar 24, 2019 4:49 pm
Contact:

Re: Do you find interesting the use of Baikal for the OpenCL denoiser?

Post by TAO » Fri Jan 31, 2020 1:25 pm

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 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
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.
To be run on GPU, the ML filter requires Windows or Linux OS. Otherwise, the denoiser will switch to its CPU-based mode.
And it's already integrated in blender and blender source code is available, so maybe that's helping too.
Omid Ghotbi (TAO)

Post Reply