[Bf-committers] Sunday meeting minutes, 25th feb 2007
tbaldridge at gmail.com
Mon Feb 26 23:53:26 CET 2007
Interesting read. However, I seem to be missing the point of why it's
better/safter than pthreads (granted it looks better). And with OpenMP
we'd be locked into using gcc 4.2/gomp/etc.
Don't forget that we have issues here with multi-platform. Any
compiler extensions have to be supported on all OSes.
I will mention that I really like the current threading API of
blender. It's a nice wrapper for the pthreads library (and I think it
wraps the win32 APIs as well right).
I do really like the idea of at least backgrounding most of the tasks.
Something that my experience with SGI Irix workstations has thought
me, is that the interface response is 90% of the "experience", a slow
GUI will make the whole App feel slow, but a fast GUI will make even a
sluggish app seem fast.
>>So maybe we could start listing this
>>different kind of cases (up to a client "blender at home" for a huge
>>gigantic distributed blender network... :-)).
Sounds like a good idea, but let me point out that I'm not suggesting
we aim for blender at home type of clustering. On the contrary, what I'm
suggesting is networking for 1-10Gbit networking. This stuff is not
that unreachable by most users of Blender.
But you are right, there are some tasks that are suitable only for
multi threading. But could not the same API model be used for both?
Maybe not the current threading API, but a extended one perhaps. Then
it would be possible to simply have different functions/macros for
spawning pvm processes or threads.
I don't think that all of Blender can be threaded by the next version,
but I think we could get the API hammered out, and allot of the tasks
BTW, where can we start a wiki on this?
More information about the Bf-committers