WIP: Improved parallelization of subdivision #113382

Eugene-Kuznetsov · 2023-10-07T06:38:37+02:00

Eugene-Kuznetsov commented

2023-10-07 06:38:37 +02:00

Although subdivision is already parallelized, it is designed in such a way that single-threaded tasks may take up over half of total time. This PR parallelizes three of these tasks. I observe a significant speedup, particularly in situations where subdivision is a bottleneck (e.g. large mesh parented to an armature with keypoints, viewport in solid shading mode).

It also switches the default CPU subdivision evaluator to the threaded (TBB) implementation. The effect is not large (because Blender does nearly everything by hand, only calling the evaluator for individual vertexes and faces) but TBB does seem to help.

Although subdivision is already parallelized, it is designed in such a way that single-threaded tasks may take up over half of total time. This PR parallelizes three of these tasks. I observe a significant speedup, particularly in situations where subdivision is a bottleneck (e.g. large mesh parented to an armature with keypoints, viewport in solid shading mode). It also switches the default CPU subdivision evaluator to the threaded (TBB) implementation. The effect is not large (because Blender does nearly everything by hand, only calling the evaluator for individual vertexes and faces) but TBB does seem to help.

👍 3 👀 1 ❤️ 1 🎉 1 🚀 2

Eugene-Kuznetsov added 1 commit 2023-10-07 06:38:53 +02:00

Switch to TBB OSD evaluator f9b74313f0

Parallelize bottlenecked subdivision jobs

himisa commented

2023-10-07 09:51:33 +02:00

Just for curiosity, is now subdivision performed once per frame (per subdivision modifier) when playing animation?

Is it possible that the mesh topology of subdivision can be cached and reused when animation/edit does not change the topology? When deforming, the deformed result vertex position can be interpolated as weighed average of source vertices, where weights can be loaded form cached subdivision topology?

Just for curiosity, is now subdivision performed once per frame (per subdivision modifier) when playing animation? Is it possible that the mesh topology of subdivision can be cached and reused when animation/edit does not change the topology? When deforming, the deformed result vertex position can be interpolated as weighed average of source vertices, where weights can be loaded form cached subdivision topology?

Eugene-Kuznetsov commented

2023-10-07 12:54:18 +02:00

Subdivision is performed once per frame if there's any possibility that the mesh might change over time. As I mentioned, it will happen if it has an armature modifier and there is at least one keyframe on the armature. Or if it has shape keys and there is at least one keyframe on any shape key. It will be recomputed even if the mesh does not actually change.

There's a similar performance impact relating to regeneration of tangent spaces (I have a PR to optimize that process too).

In addition to playback, it''s also a problem when you are trying to edit or pose a rigged mesh and the viewport is updated at 3 fps in response to your inputs.

Caching and reusing both subdivision and tangent spaces is probably a good idea.

Subdivision is performed once per frame if there's any possibility that the mesh might change over time. As I mentioned, it will happen if it has an armature modifier and there is at least one keyframe on the armature. Or if it has shape keys and there is at least one keyframe on any shape key. It will be recomputed even if the mesh does not actually change. There's a similar performance impact relating to regeneration of tangent spaces (I have a PR to optimize that process too). In addition to playback, it''s also a problem when you are trying to edit or pose a rigged mesh and the viewport is updated at 3 fps in response to your inputs. Caching and reusing both subdivision and tangent spaces is probably a good idea.

Iliya Katushenock commented

2023-10-07 12:58:35 +02:00

Why that is not C++ tbb api?

Iliya Katushenock added this to the Modeling project 2023-10-07 12:59:03 +02:00

Eugene-Kuznetsov commented

2023-10-07 20:54:21 +02:00

Why that is not C++ tbb api?

It matches the way the rest of subdivision code is parallelized.

> Why that is not C++ tbb api? It matches the way the rest of subdivision code is parallelized.

Hans Goudey commented

2023-10-07 23:47:21 +02:00

Thanks for the PR! Three requests here:

Could you separate the tbbEvaluator change into a separate PR? It's nice to make this sort of change smaller and it's easier to consider one at a time.
Could you include some performance test numbers in the PR description?
It would be nice for the PR to include some guess/investigation of why these are single threaded loops currently. Without looking into it myself, I'd expect that to be because the contents aren't thread-safe.

Thanks for the PR! Three requests here: 1. Could you separate the `tbbEvaluator` change into a separate PR? It's nice to make this sort of change smaller and it's easier to consider one at a time. 2. Could you include some performance test numbers in the PR description? 3. It would be nice for the PR to include some guess/investigation of why these are single threaded loops currently. Without looking into it myself, I'd expect that to be because the contents aren't thread-safe.

Eugene-Kuznetsov changed title from ~~Improved parallelization of subdivision~~ to WIP: Improved parallelization of subdivision

2023-10-08 22:35:26 +02:00

Eugene-Kuznetsov closed this pull request

2023-12-23 07:49:37 +01:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: Improved parallelization of subdivision #113382

Pull request closed