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