Hi all, Happy New Year! I was wondering if anyone had thoughts/suggestions on areas/workflows of Blender that are slow and could be improved with multi-threading. An example would be something like the object sync portion of the rendering process in Cycles. That used to be single threaded and was later multi-threaded. I’m curious if anyone can think of other areas in (any part of) Blender that could be similarly improved.
Thanks in advance.
In fact I was just looking into profiling one area: Blender VSE rendering.
Currently, rendering a timeline from the VSE to a file only uses 1 CPU, but multi-threaded rendering would be a huge improvement.
Blender VSE in general is very slow - I suspect that there’s some redundant work when seeking in a clip and also some additional opportunities to cache work as well.
Hi there, thanks for the suggestion! My apologies, but what is the “VSE”?
EDIT: Ah, video editor! Do you have a workflow you can share?
Shader evaluation (just try some of those nodevember node trees).
Hi.
*Decimate modifier.
*Freestyle
*Rigid Body simulation
*Also the process for assigning Rigid Body from active to many converted particles/objects. When you select the converted particles/objects, then you assign Rigid Body to the active one, and then with all selected you select “Object > Rigid Body > Copy from active” (Probably copying any attribute from active to many objects is single thread process)
Hi @easythrees,
Would you be interested in contributing to Blender development, or is this a question you’re asking as a user?
Edit Mode in general, I’m not sure if it’s multithreaded at all, high count meshes are impossible to deal with in Edit mode
Also, multithreading code isn’t that simple or easy. We tend to look at that as an easy solution that fits all purposes and fixes everything. I know I used to.
Thing is that multithreading adds overhead, splitting tasks into threads and then sending those to the cores has a lot of overhead, there isn’t an automatic way to do it, the coder must deal with that. When tasks are very easy to parallelize and take a lot of time (example, rendering tiles) then the overhead is negligible and the benefits of multithreading are very obvious.
But when tasks are smaller, faster and you must work around them to parallelize… the overhead eats up any benefits and multithreading becomes a burden.
If it was that easy, everybody would do it everywhere, and truth is it doesn’t happen that much. Games have just started parallelizing stuff since those now use multiple passes for rendering frames after geometry is processed, and you can parallelize those passes, but without those… you’d be stuck on single threads as it’s always been the case.
Hi @MetinSeven, I’ve actually made a contribution to Blender, I’m looking to make more. I work at AMD and my group works with software vendors to help improve their software’s performance, hence the question.
I would add two things:
PS:
.blend file compression is in development already:
That’s great, didn’t know that! Keep up the good work!
I would say modifiers, there are some benchmarks out there that compare several DCCs, Blender included and one of the tests is using a bend modifier on a 3M poly dragon scan model and Blender is terribly slow, around a couple FPS where Maya and Max are more than 10x faster.
The use case of a 3M poly model is obviously to make the differences more obvious, lower density models also show a big difference.
Not sure if its a multithreaded issue or just lack of plain optimizations, but im sure if it gets multithreads on the modifiers, even gpu acceleration, it would make a major difference
BMesh needs updating to multi-threading, particularly to speed up Sculpt Mode’s Dyntopo mode, but the original BMesh developer is already taking care of this:
There are a couple slow things in the VSE you can easily try, all starting from “File > New > Video Editing”.
Drag a 1080p H.264 video clip onto the timeline and try to play it. Even though your computer can probably play the file fine, performance in the VSE tends to be much slower. Add a transform or effect and it can often drop into single-digit FPS. The “Prefetch frames” feature that generates cached previews could probably be parallelized.
Put some video clips on the timeline and export. You will see that the CPU usage (as measured by top) doesn’t go over approximately 120%, but the VSE could probably render multiple frames in parallel. I’m guessing this is not a trivial modification because some things work best sequentially (decoding source video, encoding output video).
multithreaded bmesh would increase perf for many popular addons as well
I don’t know if this is a multithreading thing but polypainting on heavyer meshes seems to be pretty slow for me.
There’s a lot of great suggestions here, I’ll start a google doc so that we can also record details. Keep the suggestions coming please 
Polypainting is to be redone. There’s in the works a patch that increases performance a huge lot, but was pulled off the master branch due to some problems that need solving, but was indeed a lot faster, I am sure we’ll have news about it sooner than we expect.
Editing high poly meshes in general is very slow. It was on the roadmap for 2020 but seems to have stalled a bit.
Multi-Thread bmesh to mesh conversion is one of the big targets for Milestone 1 I believe:
Other than that, making the modifiers (like decimate and remesh) faster would also be really nice, especially relevant now with the geometry nodes projects.
Awesome! Good to know. 
I have no problem switching to ZBrush for that but if I have the option to do it in Blender and just as good: Rock and roll! 