Sergey Sharybin
9522f8acf0
This feature was adding extra complexity to task scheduling which required yet extra variables to be worried about to be modified in atomic manner, which resulted in following issues: - More complex code to maintain, which increases risks of something going wrong when we modify the code. - Extra barriers and/or locks during task scheduling, which causes extra threading overhead. - Unable to use some other implementation (such as TBB) even for the comparison tests. Notes about other changes. There are two places where we really had to use that limit. One of them is the single threaded dependency graph. This will now construct a single-threaded scheduler at evaluation time. This shouldn't be a problem because it only happens when using debugging command line arguments and the code simply don't run in regular Blender operation. The code seems a bit duplicated here across old and new depsgraph, but think it's OK since the old depsgraph is already gone in 2.8 branch and i don't see where else we might want to use such a single-threaded scheduler. When/if we'll want to do so, we can move it to a centralized single-threaded scheduler in threads.c. OpenGL render was a bit more tricky to port, but basically we are using conditional variables to wait background thread to do all the job.
34 KiB
34 KiB