[Bf-committers] Blender 2.70a OpenMP issues

[Sergey Sharybin]

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