It doesn’t, that’s why I thought it wouldn’t matter
I think the VRAM does not really matter, it seems to be just a render device thing. If I uncheck my CPU in the settings, the peak goes up to 600 MB, but render time is the same
If OIDN makes good job it is reason to remove alternative option?.really strange conclusion
No, because NLM does a very bad job, look at my image:
Now we have something better than that, nobody should use it anymore
EDIT:
This is what my above scene would look like with NLM denoise:
NLM is so bad, it should not be used anymore
1 Like
As a side note, you can’t really make performance comparisons between scenes that render differently between Cycles-X and master. This is because if they render differently, then the scene is technically not the same and thus the comparison is unfair.
As for Cycles-X not being as fast as expected, part of that may be down to the official release on the https://builder.blender.org/download/branches/ website. The initial release of Cycles-X there makes use of CUDA 11(.1?) where Cycles-X can see some extra benefit from running with CUDA 11.3. Standard Cycles should also see speedups from CUDA 11.3, but I’m not sure if it’s the same sort of speedup Cycles-X sees, I haven’t tested it.
The builds on https://builder.blender.org/download/branches/ should now include CUDA 11.3, so re-downloading may result in a better comparison.
Another thing to remember is that there’s all sorts of factors that play into whether or not Cycles-X is faster. GPU drivers. The modernness of your GPU. Other programs running in the background. Or simply, some scenes are going to be slower in Cycles-X than standard Cycles.
One thing to note. Cycle-X sees the biggest speed up in scenes that experience a lot of bounces and have complex geometry. This can come about from increasing light path bounces, samples, and resolution. In the test scene you’ve provided, enough of these variables are low enough to reduce the impact the optimizations made in Cycles-X has.
So, it’s possible Cycles-X is slower on your computer because of a combination of the factors listed above. Or it could be a limitation of Cycles-X. I can’t tell you which. But as a starter you could try looking at your system and seeing what’s the potential cause for the slowness. And if you’re ruled out everything and still have slow renders, then it’s possibly just Cycles-X being slow?
As a side note: The easiest way to rule out a bunch of factors would be to boot your computer into a clean operating system with clean GPU drivers and a clean installation of Blender. The easiest way of doing this would probably be to install Linux on a USB storage device and booting your computer off that.
I did, and all images I posted were already from the redownloaded version
Too much for me, sorry 
Not sure what you mean by this. My test scene is lit mostly by bouce light, I have several remeshed SSS monkeys, and a mirror for reflection. It should be enough for meeting the criteria of “a lot of bounces and have complex geometry”
I’m not going to argue if NLM should be kept or not. But I’d like to point out some advantages NLM has over AI denoisers:
-
NLM doesn’t have as strict of hardware requirements. OptiX AI denoising is limited to Nvidia GPUs of the Maxwell generation or higher and OIDN is limited to CPUs with SSE 4.1 functionality (On ARM CPUs this requirement is different as the code is different).
-
NLM is the only denoiser in Cycles to contain a temporal denoising function. It’s hidden away behind a python console command, but the fact NLM has it while OptiX and OIDN does not is a nice to have for some people. OptiX did just recently get temporal denoising, but as pointed out above, OptiX is limited to a selection of Nvidia GPUs, not everyone is going to have. OIDN is probably going to get temporal denoising at some point and when that happens, the “advantage of NLM having temporal denoising” is null unless you can’t use OIDN or OptiX (basically the point above).
I know the both of these points are very niche. SSE 4.1 has been in x86 CPUs for about a decade now and so OIDN is accessible to most Blender users. But here’s just a few things to keep in mind.
What I meant was that the maximum light bounces is set to 3, the sample count is low (32 with adaptive sampling) and the resolution is “low”. The geometry in the scene isn’t too complex (36,000 triangles), but it should be complex enough to have an impact?
And as another note, the render time reported by Blender is rendering+compositing. Because I believe the speed of OIDN is basically the same between Cycles-X and master, it can end up hiding some of the advantages of Cycles-X on scenes that render quickly (like the test scene provided)
On my computer I can personally replicate 2x performance boost in most situations with Cycles-X (For reference I used a RTX 3070 with OptiX for testing). However in the scene you’re using for testing render times are basically the same between Cycles-X and master suggesting that a lot of stuff in the scene isn’t optimized to take advantage of Cycles-X. The main factor for the slow down in my case is probably the fact compositing was used.
No, my initial test was not denoised at all, I added denoising afterwards just for visuals
Higher samples and more triangles would take more time to render and that is kind of a pain for me and my lower end computer, I have a habit of testing things in low samples and low resolutions
I’m sorry, I’m just taking guesses here at what might be causing the lower than expected performance and providing you with information I observed from the file you provided and the performance numbers I see on my personal system. I’m probably going my to end contribution to this specific part of the discussion here.
Basically, something is causing the slow down. Your setup, the scene tested, or something in the Cycles-X code. I can’t tell you which, you will need to do some tests or maybe a combination of data from various people in the community can help figure out the cause.
Also, it’s possible Cycle-X may get faster or more consistent (or slower) as it’s further developed. So even though performance may not as great as expected now, it may get better in the future.
I mentioned before that I asked my friends and each give me different answers. Besides, Voidium tried my scene and in that case Cycles X is faster on their computer. it seems Cycles X itself has inconsistent performance in different hardwares
I hope so
Just as a side note for people who didnt see speedups, searching for the reason of it. My cycles X is 4 times faster on my other laptop having same NVIDIA GTX 960m where i didnt update drivers (I didnt use any denoisers too). So Cycles X was not dependent on updating drivers if original cycles is working fine, in my case.
@MetinSeven Is there an official feature list where we can see what is currently implemented or missed in Cycles-X that will be always updated by the dev team?
This would help avoid unnecessary discussions about bugs that are actually just features that aren’t implemented yet.
EDIT: I think this links will help users a lot to see what is the current development status before posting known problems:
https://developer.blender.org/T87839
https://developer.blender.org/T87837
https://developer.blender.org/T87836
2 Likes
Yes, those links are useful to track Cycles-X developments, including the updates and comments that are added to the pages.
1 Like
One more thing to check for comparisons: as far as I know the only SSS model in Cycles X is Random-Walk.
Edit: just checked, no looks like C/Burley is still there…
Edit2: as Brecht stated as of now (may 5) only random walk works, even if you set Burley
NLM is the best denoiser of the blender to preserve details of clothes and hair, your comparison is sucks, The NLM is very important for those who make animations with characters!
Edit: i used blender 2.93
A few points:
- OpenImageDenoise 1.3 in Blender 2.93 better preserves sharp details, and that’s what we should be comparing against, not sure if that’s what everyone is using. There may also be improvements to the albedo and normal pass that we can still do to improve the results. However if we find that NLM is still significantly better in important use cases, we will restore it.
- Renders using Burley SSS are currently rendered using Random Walk, and the result looks quite different, so render times are not comparable.
- It’s unclear to me how Auto Tile Size can affect render time, but if that’s the case we’ll investigate it. Possibly it’s related to how we display renders in the image editor, which with current progressive rendering is somewhat slower. Our idea is to use the 3D viewport display code to make that fast.
9 Likes
I also compared NLM to OIDN 1.3 and while being better, it’s still not usable for high resolution renderings with fine details. Great to hear that it’s at least considered that NLM stays in. It would be annoying to have to stay with 2.9x just for that reason.
1 Like
A rule of thumb, when you are testing a denoiser, make sure to use a super super noisy scene other wise the result is not going to be obvious. You scene was rendered with 2000+ samples and I am not sure what you are trying to compare. My tested scene is mostly lit by bounce lignt and it has only 32 samples to make the effect pop.
I noticed it so I manually switched both to random walk to make it a fair comparison, so it should not be the case for me
I am not sure about that anymore, I was only able to reproduce it once, and now if I try again, “auto tile size” doesn’t seem to matter now