Commit Graph

16 Commits

Author SHA1 Message Date
fcc844f8fb BLI: use explicit task isolation, no longer part of parallel operations
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.

There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.

Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading

Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.

Patch implemented by Sergey and me.

Differential Revision: https://developer.blender.org/D11603
2021-06-15 17:28:44 +02:00
ed1fc9d96b BLI: support disabling task isolation in task pool
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.

Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.

This fixes T88598.

Differential Revision: https://developer.blender.org/D11415
2021-06-08 10:39:33 +02:00
9adfd278f7 Compositor: Full-frame base system
This patch adds the base code needed to make the full-frame system work for both current tiled/per-pixel implementation of operations and full-frame.

Two execution models:
- Tiled: Current implementation. Renders execution groups in tiles from outputs to input. Not all operations are buffered. Runs the tiled/per-pixel implementation.
- FullFrame: All operations are buffered. Fully renders operations from inputs to outputs. Runs full-frame implementation of operations if available otherwise the current tiled/per-pixel. Creates output buffers on first read and free them as soon as all its readers have finished, reducing peak memory usage of complex/long trees. Operations are multi-threaded but do not run in parallel as Tiled (will be done in another patch).

This should allow us to convert operations to full-frame in small steps with the system already working and solve the problem of high memory usage.

FullFrame breaking changes respect Tiled system, mainly:
- Translate, Rotate, Scale, and Transform take effect immediately instead of next buffered operation.
- Any sampling is always done over inputs instead of last buffered operation.

Reviewed By: jbakker

Differential Revision: https://developer.blender.org/D11113
2021-06-01 10:51:53 +02:00
1b4f0bf32a Fix T87989: Crash using OpenCL in compositor
Initial report was mentioning the Classroom demo scene, but this is
probably because the scene was pre-configured to be used with OpenCL.
Would expect any OpenCL compositing to be failing prior to this fix.

The reason why crash was happening is due to OpenCL queue being
released from OpenCLDevice destructor. Is not that obvious, but
when Vector (including std::vector) is holding elements by value
a destructor will be called on "old" memory when vector capacitance
changes.

Solved by making forbidding copy semantic for compositor devices and
forcing move semantic to be used.

Also use emplace semantic in the devices vector initialization.
2021-05-03 15:07:14 +02:00
Manuel Castilla
05b1f966fd Fix Compositor: WorkScheduler task model deletes works
WorkScheduler task model deletes work packages after executing them. The other models don't do so. All models should handle packages the same way.

Reviewed By: #compositing, jbakker

Differential Revision: https://developer.blender.org/D11102
2021-04-28 08:36:13 +02:00
36427a8d03 Cleanup: remove loading blender namespace from Vector. 2021-04-02 16:13:27 +02:00
1a7b94236e Compositor: Keep WorkPackages and Data Around.
WorkPackages struct was created when scheduled. This patch keeps the
WorkPackages around and stores additional data with the workpackages.

The speedup is to small to notice, but it is needed as preparation
to introduce a faster scheduling method.
2021-03-31 14:43:14 +02:00
fe60062a99 Cleanup: Use Bitflags For Booleans. 2021-03-29 17:10:01 +02:00
25c02ea703 Cleanup: Add namespace to compositor. 2021-03-29 08:18:33 +02:00
0d5cef9898 Cleanup: removed unnecessary allocations. 2021-03-24 14:30:22 +01:00
26b45448ab Fix: Memory Leak When Using Compositor.
When using the compositor inlined static vectors could allocate
memory. This memory wasn't freed. This patch would make them inline
again.
2021-03-24 11:57:04 +01:00
7046e37ede Cleanup: WorkScheduler.
- Use constexpr for better readability.
- Split in functions per backend.
- Split work scheduler global struct in smaller structs.
- Replaced std::vector with blender::Vector.
- Removed threading defines in COM_defines.h
2021-03-23 16:14:11 +01:00
19da44f869 Cleanup: remove internal functions from interface. 2021-03-23 12:05:37 +01:00
bb6765f28f Cleanup: spelling 2021-03-18 09:36:44 +11:00
7388f9df71 Cleanup: Compiler warnings with COM_TM_NOTHREAD active. 2021-03-12 13:36:49 +01:00
1775ea74c1 Cleanup: Change extension .cpp to .cc 2021-03-08 13:41:52 +01:00