[Bf-committers] Blender 2.70a OpenMP issues

[Antony Riakiotakis]

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
>