metropolis CPUvsOpencl

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

metropolis CPUvsOpencl

Post by lacilaci »

What's up with that?

I've noticed few times already that using same settings on opencl gives me all kinds of fireflies. As if it's ignoring clamping, or some other setting or I don't know...
Attachments
metropolisCPU.JPG
metropolisOpenCL.JPG
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: metropolis CPUvsOpencl

Post by lacilaci »

Also, can someone explain what is the max consecutive rejects value doing(in human language)?

I'm comparing some final renderings using sobol and opencl with metropolis and very low mcr values and while this low value lowers some highlights it puts rendering speed on steroids.... I love it

ps: only on cpu, seems like this value is ignored by opencl?
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: metropolis CPUvsOpencl

Post by Dade »

Metropolis on GPUs is "problematic": there is a sampler for each rendering thread, the problem is that, for instance, you have 12 threads on a 6 core+hyper-threading CPU while you have 512,000 threads on a GPU (it is not a typo, it is 0.5M threads).
The end result is that the convergence speed of each Metropolis sampler on GPU is a LOT slower (i.e. 512,000 / 12) that CPU version.

In general, the two best solutions in LuxCore are brute force on GPUs (PATHOCL+SOBOL) and being smart on CPUs (BIDIRCPU+METROPOLIS).
Support LuxCoreRender project with salts and bounties
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: metropolis CPUvsOpencl

Post by Dade »

P.S. Random and Sobol sampler don't suffer of this problem, CPU and GPU versions are about the same.
Support LuxCoreRender project with salts and bounties
kintuX
Posts: 810
Joined: Wed Jan 10, 2018 2:37 am

Re: metropolis CPUvsOpencl

Post by kintuX »

Metropolis

The metropolis sampler is an "intelligent" sampler that uses the Metropolis-Hastings algorithm and implements Metropolis Light Transport (MLT). The metropolis sampler tries to "seek the light". This makes it a good choice in almost all situations. It does this by making small random changes to an initial reference sample and looks to see if the new sample is more interesting, I.E. provides more light. If it is not, then the sample is discarded and a new sample is taken. If the new sample is a nice bright sample, metropolis will adopt the sample as the new reference sample. Then it explores the surrounding area using very small path mutations. This process of changing a sample is called a small mutation. This behavior can also lead to fireflies (overly bright spots in the image).

This process of mutation allows the metropolis to efficiently locate and explore paths which are important. However in order to avoid the sampler getting stuck on some small but very bright area it will once in a while generate a completely random sample and force this to become the new reference sample. This is called a "large mutation".

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The "maxconsecrejects" (Maximum Consecutive Rejects) parameter controls when to generate a path mutation. The default value is 512, so if 512 samples are discarded it generates a new path mutation (time to look somewhere else). Then the "lmprob" (Large Mutation Probability) parameter is used to determine the chances of generating a large path mutation (new completely random sample from somewhere else in the image) or a small path mutation (something nearby). Before a sample is added to the film, the metropolis sampler decides if the sample should be accepted as the new base for mutations or rejected (the previous sample is then used instead). Lowering the maxconsecrejects parameter introduces bias and mutes light sources and caustics. For caustics higher values are better. Raising the lmprob value also introduces bias, setting it to 1 turns metropolis into a dumb random sampler. Lower values are less biased and will produce a more realistic result. Be careful not to bring this too low or it may introduce undesirable effects.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

LuxRender's metropolis sampler is based on Kelemen's paper "A Simple and Robust Mutation Strategy for the Metropolis Light Transport".
source: LuxRender Render settings (old wiki)

&

Optimum Max Consecutive Rejects... (@ old LuxRender forums)
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: metropolis CPUvsOpencl

Post by lacilaci »

Thanks guys, so maybe it would be good in blendluxcore disable the ability to run metropolis on both cpu+gpu? I know there is a warning that it can cause trouble but still...

So lowering max con rejects mutes high power samples right? But it's different from variance clamping right? If so, can we have a similar feature for path+sobol on ocl? I'm super hyped now that i see what low mcr values do to metropolis on cpu in terms of performance?
I don't care about bias, as long as it's not obviously wrong.

edit: ok so I was afraid to use variance clamping in night shots cause of how drasticaly it could change sun and sky look... but it seems it's doing really good magic without much of an impact in low light.. I wish this was more intuitive to use.
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: metropolis CPUvsOpencl

Post by lacilaci »

Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.

So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: metropolis CPUvsOpencl

Post by Dade »

lacilaci wrote: Sat Oct 27, 2018 12:59 pm Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.

So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
It may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.
Support LuxCoreRender project with salts and bounties
User avatar
lacilaci
Donor
Donor
Posts: 1969
Joined: Fri May 04, 2018 5:16 am

Re: metropolis CPUvsOpencl

Post by lacilaci »

Dade wrote: Sat Oct 27, 2018 2:27 pm
lacilaci wrote: Sat Oct 27, 2018 12:59 pm Ok, so this is the big issue with variance clamping. Low values can have little visual impact on indirect lighting, but will heavily impact direct lighting.

So can we please split direct and indirect light clamping? Or if you are against another editable parameter then maybe just disable direct light clamping...?
Right now it is a super usefull feature that can easily ruin the picture if it kills direct sunlight for example.
It may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.
I see, well you rarely(or never) need to clamp direct lighting cause it is usualy not the source of noise and resolves quickly.
This is why corona for example only lets you tweak max indirect intensity and cycles has both direct and indirect, but it just doesn't make sense clamping direct lighting.
The bad effect of clamped direct light is however very prominent and immediately ruins contrast of the image.
User avatar
Sharlybg
Donor
Donor
Posts: 3101
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: metropolis CPUvsOpencl

Post by Sharlybg »

It may be possible but it could mess (a LOT) the MIS so I'm not sure if the outcome would work.
I think all the frustration around all that biased vs unbiased and tricky features request will mostly be cooled down by LC2 (indirect light acceleration feature). I'm myself facing all the same limitation each time i work on a new project ( mostly interior archviz) , it's so hard to wait and work on path tracing for indirect dominant 3D scene now that we know LC2 is planned.
I'm myself working currently on a very serious interior project all Image have to be rendered in 2k (The printer ask for 4K but can't afford this). Compared to old Lux 1.X series it is day and night ( impressive speed and quality at the same time ;) ) adaptive sampling and Visibility map feature help a lot ( Thank Dade and BYOB for that).

Lacilaci i can really understand you sometimes i wake up by night on my bed and just wonder how beautifull thing could be if LC2 was already implemented inside the engine. My heart and my brain are litterally screaming for this feature all the time ( WTF 4X to 8X speed up in interior rendering compared to current already good version is total insanity). The first opensource renderer to support LC2 even on GPUs (opencl) This is terrorism Dade should go to the jail for only mentionning this feature :lol: .

This is my confession even if i can look super self controlled sometimes i'm completely burning inside while waiting for this to happen :lol:

Now i'm Out :arrow:
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA
Post Reply