[Bf-committers] Sunday meeting minutes, 25th feb 2007

[Nils Thuerey]

Hello,

I think this is an interesting discussion about parallelization - the 
fluid solver uses threads right now, but only one for displaying, the 
other one for simulation. The simulation itself could be nicely 
parallelized with OpenMP to make use of multiple cores. I did a parallel 
implementation of it with the Intel compiler a while ago, but was never 
able to test with gcc/gomp or MSVC8. Overall, I think having OpenMP 
enabled for the Blender compilation could be really useful. Once gcc 4.2 
is out it would hopefully be possible to enable OpenMP for Mac, Linux 
and Windows.

Regards,
-> Nils


Toni Alatalo wrote:
> Timothy Baldridge kirjoitti:
>>>> the parallelization of certain tasks|modules (either trough pthread or
>> I agree with this idea. However there is a issue here. Simply going
> 
> +1 for background / parallel operation support from me too - I tend to 
> often have multiple Blenders open, like yesterday when was running big 
> exports (to ogre), while tweaking some other models too. although for 
> such cases it is not much of a problem to do it like that, by just 
> having multiple separate Blenders, which has benefits too (they can't 
> interfere with each other, crashing being the worst case..). but 
> managing it somehow nicely from inside Blender would be cool - a simply 
> crude solution would be even by launching 'sub-blenders' to their own 
> processes (hm that would be actually fun to test with a little script 
> :), but for many of the cases mentioned (at least physics sims?) i guess 
> having memory sharing threads are needed too.
> 
>> functions are extremely fast. This means that the whole .blend file
>> could be created, and streamed across the network to the other
>> clients. Basically we already have a built-in serializer/pickler!
> 
> yah that is cool indeed. at least if the big data (textures, in some 
> cases i guess geometry too) is already synchronized / accessible for the 
> computers, scene & node etc. configs go quickly with blends.
> 
>> I've done some work with this in the past, and am in the process of
>> developing a full PVM style Clustering module in pure python. If
>> anyone is willing to work on me with this, I'd be willing to dive into
>> writing up a few design docs in the concept and possibly contributing
>> a bit of code. I don't have loads of time, but then again, no one
>> does.  :-)
> 
> You might benefit from looking at the work done in and around the next 
> gen. IPython project, as they are targeting parallel / cluster / remote 
> operations, and have it already running and in use. I think they also 
> have quite a lot of time to develop it, 'cause they are using it in 
> their jobs (mostly some sort of scientific simulations). 
> http://ipython.scipy.org/moin/Parallel_Computing "Interactive Parallel 
> Computing"
> 
> Although Blender is not Python, the approach there might be relevant for 
> Blender itself too, because it targets utilizing parallel / remote 
> computations for *interactive* use, not (only) for long-running 
> noninteractive tasks like I guess many farm things etc.
> 
>> Timothy
> 
> ~Toni
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 

-- 

   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  .                                                         .
  .          Nils Thuerey                                   .
  .          Computer Graphics Lab - ETH Zurich             .
  .          http://graphics.ethz.ch                        .
  .          More Pictures & Animations:                    .
  .          http://www.ntoken.com                          .
  .                                                         .
   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .