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