[Bf-committers] Cycles Progressive Refinement Checkbox Tooltip *somewhat* ambiguous

[Sergey Sharybin]

Brecht, it's multiple factors being involved here, starting from CPU cache
coherence issues (which we can't easily predict) ending with less efficient
buffers update (we might be saving all the passes after each of the samples
in case of progressive refine, which we can fix).

But yeah, should have asked for a demo file in the original file :) So do
you guys have a demo .blend file which demonstrates such a major slowdown?

Brecht, we can (and actually should) do several samples per tile, but i'd
prefer log(). not sqrt() perhaps. Other idea to improve cache coherence
would be to use left-to-right, bottom-to-top tile scheduling. That gives
few %% of speedup, and AFAIR we don't fallback to such a scheduling in
progressive refine.

And even after the tweaks, we should probably replace "somewhat" to
something more deterministic in the tooltip.

On Thu, Nov 13, 2014 at 10:58 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> If it is really 100% or 300% slower then that sounds like a fixable issue.
>
> I'm not sure why it would be this slow, it would be good to find out why,
> but one thing that would speed it up is to render more samples at a the
> time and redraw less often as the current sample increases. Due to the way
> Monte Carlo integration works, one sample barely makes any visible
> difference in noise after a while anyway.
>
> Maybe something like:
> num_samples_at_once = sqrt(max(current_sample - 4, 1))
> On Nov 13, 2014 10:13 AM, "Greg Zaal" <gregzzmail at gmail.com> wrote:
>
> Just by the way, it's even more noticeable with GPU rendering - I've seen
> it roughly 300% slower often.
>
> "could lead to significant slowdown" sounds good to me.
>
> On 13 November 2014 11:06, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>
> > The issue here is that basically slowdown depends on particular hardware
> > configuration, tile settings and device used to render (GPU/CPU).
> Meaning,
> > on modern CPU i've noticed around 20% slowdown peak, which is not that
> bad
> > as 100%. So what i'm trying to say here, is that if we'll provide
> > information "up to 100% slower" it might just scary artists and they
> > wouldn't use the option at all, even though for their configuration
> > slowdown wouldn't be so bad.
> >
> > What about more neutral (in my opinion): "could lead to significant
> > slowdown"?
> >
> > On Thu, Nov 13, 2014 at 12:22 AM, Simon Repp <simon at fdpl.foundation>
> > wrote:
> >
> > > Dear Renderistas,
> > >
> > > I only recently found out that progressive refinement in Cycles
> > > rendering (which the corresponding checkbox's tooltip describes to be
> > > "somewhat slower" than bucket rendering) in fact can impose performance
> > > penalties of over 100% (aka the same amount of samples takes more than
> > > twice as long to render).
> > >
> > > Now I don't know if this is just a personal flawed interpretation of
> the
> > > english language on my part, but when reading "somewhat slower" I
> didn't
> > > realize what I was really in for, and in retrospect I'd rather not
> > > reconstruct how many days my poor laptop spent in excess to render some
> > > projects I did in the past.
> > >
> > > I'd hereby like to propose a change of this tooltip to something less
> > > ambiguous, lest anyone else falls into that same trap that I have - My
> > > proposal for this would be to include actual figures describing the
> > > possible speed penalty that progressive refinement can impose, that is,
> > > something along the lines of "renders [a]% to [b]% slower depending on
> > > the scene", where figures [a] and [b] are ideally derived from real
> > > world data we gather (or already have?) about how much speed penalty
> > > progressive refinement can impose in different scenes. Alternatively,
> > > only stating "up to [x]% slower" would work as well I guess, as the
> main
> > > point is to make people aware that it _can_ possibly affect render
> times
> > > _significantly_.
> > >
> > > If the proposal to include figures is not agreeable for some reason, I
> > > would at least ask for a more indicative wording than "somewhat
> slower",
> > > which even after consulting multiple dictionaries I'm not sure if there
> > > is an official interpretation for. (One dictionary suggests "quite" as
> a
> > > synoym, another "slightly" ...) I'd still prefer the figures though, no
> > > one looks up terms in the dictionary while using Blender and I am
> > > probably not the worst offender at massacring and misunderstanding the
> > > english language in the Blender community, and it doesn't get less
> > > ambiguous than numbers anyway, so I say we use them here? :)
> > >
> > > Best,
> > > Simon
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin