Page 1 of 1

feature: threads for more than rendering

Posted: Thu Mar 09, 2006 10:12 pm
by dschnell289
Is it possible to make the GUI use multi processors? My p4 3 HT with 2G ram slugs down quite a bit on a relatively complex scene while doing a preview (wireframe alt-a). Task Manager shows that only 50% of the cpu is being used (I know it's misleading with HT..but nonetheless). There's gotta be a way to unleash full cpu resources.

(I'm having a hard time visualizing the timings of the animation without it...can't waste time rendering the whole thing over and over to adjust timings). (It's a short animation, aiming for about 45-60 seconds in duration.)

Posted: Fri Mar 10, 2006 5:00 pm
by an-toni
blender is event-driven, so sharing is possible, but needs some refactoring before is safe to do everywhere.

enabling this can be seen as a goal for the long-waited much-talked-about event rewrite :!: , which i guess is to be set as a target for the 2.5 series.

before that we have to finish this certain movie, and release 2.42 alphas and the rest. and many things can be done with the 2.4 base, without much thought given to the event system or parallel multiprocessing (which will require removing / protecting the global G which is used a *lot* now, so dont expect this to happen easily).

~Toni

Posted: Sat Mar 11, 2006 5:50 am
by stiv
A good way to think of Blender is as a graphic database with multiple viewers/browsers/editors accessing the data simultaneously. Each window, a Space in Blender terms, has its own view of the data. Each window is like a separate client accessing the database.

Right now, the necessary serialization and locking comes from the single-threaded nature of blender. Changing over to a threaded model will involve quite a bit of work. It will be more of a re-architecting than a code refactoring. I would not expect it to happen right away.

People tend to think of threads as some sort of magic dust you can sprinkle on an application to make it run faster. Not always so, especially on a uniprocessor machine. A task like compiling can see major speed-ups because i/o and computing can be interleaved. Compute-bound tasks will not see the same benefits.

Posted: Sun Mar 12, 2006 3:58 am
by dschnell289
Thanks for the responses. I guess I'll be saving up for more oomph!

Posted: Sun Mar 12, 2006 4:01 am
by LetterRip
you might turn off subsurf, use low proxy models for the background etc that might give you a bit more speed.

Also a version compiled especially for your computer or finding one of the optimized builds could possibly get you quite a bit added speed.

Also using linux might also give you quite a bit more speed if you are currently running on windows.

LetterRip

Posted: Sun Mar 12, 2006 5:28 am
by dschnell289
Its the 12 curve guides controlling the 8 particle emitters (one emitter has 5 curve guides and a total of 8000 particles) that's slowing me down. If I elminate them, everything is nice and speedy. I'm using the particle system to represent process flow of water, oil and bubbles in a skid package used in the oil/gas industry. Editing the curve guides is so painfully slow that I turn off the curve guide, edit the regular curve, then turn back on the guide.

Only one of my meshes is subsurf'd, and almost everything is set to autosmooth. I know the particle system has been recently redone - and it's abilities are fabulous - but they still eat up a lot of calculation cycles when associated with curve guides (non as static strands). When the animation is finished, I will (with the company's permission) post it on elysiun for critique.

Thanks again!

Posted: Sun Mar 12, 2006 6:31 am
by LetterRip
You can reduce the percentage of hair particles displayed that will likely speed things up quite a bit.

LetterRip

Posted: Sun Mar 12, 2006 6:15 pm
by dschnell289
I dropped all my emitters to 10% showing, and it still only played back at about 1 fps (better, but not good enough).
Keep your eyes open later today in the finished projects section for a link to my video (when done).