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

[Greg Zaal]

Here's a blend which renders (coincidentally) 2.7x slower when using
progressive refine: http://gregzaal.com/ss/progressive_refine_speed.blend
(44 MB)

Rendering on GPU - 2x gtx 570, win7 64 bit, blender 2.72.2 (5cce2e1)
Progressive refine off: 139 seconds
Progressive refine on: 377 seconds
Render res: 1200x1400 (tile size: 240x234, top to bottom)

Cheers,
Greg

On 13 November 2014 12:49, Sergey Sharybin <sergey.vfx at gmail.com> wrote:

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>