Blenderstorm Polls and Ideas:
show ideas | about |
Log in

idea #102: multi-thread everything



bug  This idea was marked as needing a more complete Feature Request on 11.04.2008. (What is a Feature Request?)
up
115
(+122,-7)
down
Written by wayneberry the 3 Jan 09 at 21:28. Category: Hardware support. Status: Needs clarification
Description
multi-threaded fluid simulation
multi-threaded cloth simulation
multi-threaded preview render
multi-threaded playblast render

another nice update for the preview renderer would be (as seen in modo) to render like a progressive jpeg. so the longer you wait the clearer the render gets. this lets you have preview open all the time on a seperate view and constantly see your changes


Attachments
No attachments.


Duplicates


Comments
giorgiomartini wrote on the 10 Apr 08 at 17:46
yeaaaaaaaaaaaaahhhhhhhhh ! that would be hot.

AdminAdmin Handydan (Blenderstorm admin) wrote on the 10 Apr 08 at 23:58
Fluid has already been multi threaded with openMP and I'm not sure but I think cloth has as well.

AdminAdmin ideasman42 (Blenderstorm admin) wrote on the 11 Apr 08 at 14:48
Ofcourse multithreading is good, but saying multithreaded everything is like saying - "Lets make blender faster"

I think this needs to be more specific.

rexmortis wrote on the 11 Apr 08 at 20:38
My spoon is too big!

wayneberry wrote on the 12 Apr 08 at 03:49
@handydan

i have found a multi-threaded fluid/cloth build at graphicall but in 2.46rc1 they aren't multi-threaded


@ideasman42
as in the post the specifics i'm talking about are fluid, cloth, preview render and playblast render


i've also just thought now, when you bake ambient occlusion / normal maps etc is that multi-threaded?

AdminAdmin vilda (Blenderstorm admin) wrote on the 12 Apr 08 at 04:21
Actually almost all developers know multithreading is a priority and there have already been many efforts done in this direction.

AdminAdmin ideasman42 (Blenderstorm admin) wrote on the 12 Apr 08 at 06:33
Vilda is correct, multithreading is something thats being worked on.
Since 2.45
- Making shadowbuffers is multithreaded
- Baking is multithreaded (more then 2)
- Areas of particles code is multithreaded
- Cloth has been added and is multithreaded also.

However with windows MSVC OpenMP is only enabled for the really expensive pro version of their compiler, and none of the blender devs have it. so this may be why cloth was not multithreaded for you.

Its tempting to mark this as an invalid request.

For example - you could request multithreading the modifier stack for multiple objects and that would be quantifiable - it either works or it dosnt.
- Asking for everything to be multithreaded is not useful.

delic wrote on the 12 Apr 08 at 07:04
sequencer and composite should also be full multi-thread !

But I read anywhere that it is now, but only two cores .

wayneberry wrote on the 12 Apr 08 at 14:33
@ideasman42
making the title of this request was over-generalising, i agree. that's why i listed what i think needs to be multi-threaded

it's great to hear that work has gone into multi-threading so much of blender already, i look forward to using it.

I am using windows so maybe that's the problem... in regards to openMP. but i'm sure someone will find a way around that :)

leojS wrote on the 14 Apr 08 at 07:06
Having the preview render like a progressive jpeg would be a nice feature to have.

As for making everything multithreaded, cloth and fluid already are...

AdminAdmin ideasman42 (Blenderstorm admin) wrote on the 15 Apr 08 at 01:21
leojS, for a scanline renderer, progressive display wouldnt help rendertimes.

Once a thread is accessing a bunch of faces, its fastest to do all calculations on those faces, without having to go and do more calculations on them later, some data is generated and thrown away (like dupli's and particles) and the CPU's cache will be less effective too.

Prodeous wrote on the 21 Apr 08 at 06:37
Another element for multi-threading is when Blender prepares a scene to render. This is more visible when rendering an animation. Every frame, during preprocessing, single thread is executed.

FishB8 wrote on the 31 May 08 at 20:35
While we're doing overly general "let's make blender faster" suggestions, I think more important that multi-threading, would be reviewing general areas of repetitive CPU intensive code and restructuring it when possible to allow for better vectorization for compilers.


digmedia wrote on the 25 Jul 08 at 20:10
Sorry my bad english.

To convert "mesh to curve" would be interesting also, because it takes longer in medium and big mesh. :(

The blender really need it urgently.

[]

dino wrote on the 14 Oct 08 at 19:06
Multithreading something does not necessarly mean it runs faster. So multithreading everything might not be the actual goal but "making blender faster" which is not really an idea as said befor.


Post your comment