[Bf-committers] Blender 2.70a OpenMP issues

[Bassam Kurdali]

It might be nice to be able to seperately turn off scene/depsgraph
multithreading and keep rendertime threads; avoiding multithread bugs
during render (and depsgraph update is just a small fraction of
rendertime)

On Thu, 2014-04-10 at 00:26 +0300, Antony Riakiotakis wrote:
> I don't disagree with anything, only thing I can say is that from current
> information, it seems like different parts of blender are influenced
> differently from different openmp number of threads, hence the separate
> setting here.
> I agree this is impossible to track on every system configuration though,
> and it is quite hacky to plug custom code to every case.
> 
> Sculpting, as far as I know currently restores the behaviour after a stroke
> is finished. Having the setting per scene was supposed to follow the per
> render thread settings.
> 
> That said, I think we can remove the option since it looks like for
> sculpting automatic detection gives the optimum, but I can't tell about
> other parts. I seem to remember gcc did not work as well everywhere either,
> but jens can give more information here.
> 
> 
> On 9 April 2014 20:42, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> 
> > Hello everyone,
> >
> > Just wanted to outline some issues which i want to be solved before 2.70a
> > release.
> >
> > There are couple of issues with the current approach i didn't like at all:
> >
> > - We never should expose programmer slang to the interface. How normal
> > human being would know what "OpenMP" is, what it affects n and so on.
> > - Adding this new field breaks translations which is not good at all for
> > 'a' release.
> > - Workaround for this two issues might be using "Threads" instead, which is
> > more clear for artists and have a translation already. BUT!
> > - Why on earth OpenMP threads is a per-scene setting? Why would one want to
> > use N threads in scene A and K threads in scene B? Further, OpenMP is NOT
> > only sed by sculpt brushes, it's also used by multires, simulations, some
> > bmesh core, custom data (afair), libmv, ceres.. This makes the option from
> > sculpt mode's toolshelf affect on loads of areas, which is REALLY bad and
> > unpredictable.
> > - As a workaround for this issue, the openmp setting is to be moved to the
> > user preferences instead.
> >
> > I call it workaround because it's really ugly hack to expose such settings
> > to user hoping it will solve anything. The thing here is -- as far as i
> > understand the root of the issue goes to the fact that new clang on osx
> > have performance issues for SOME configurations. I don't see the reason why
> > would windows or linux artists change this settings. Actually, i'm not even
> > sure why one would think of changing the setting if he thinks performance
> > is not good enough.
> >
> > We really need to address the root of the issue rather than adding obscure
> > settings for artists. And if it's not doable with clang on osx -- i'd
> > suggest roll back to gcc which is proven to work. Don't see reason to push
> > using clang here.
> >
> > --
> > 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