Dev:Ref/Release Notes/2.70/Threaded Dependency Graph
Blender 2.70: Threaded Dependency Graph
The Threaded Dependency Graph solves threading issues and creates support for objects to be updated from multiple processor threads. Full re-implementation of the Threaded Dependency Graph will happen gradually. Threaded Object Update is implemented in this release only.
Threaded Object Update
This is one of the most substantial improvements in Blender at this point. Objects now update from the multiple threads of a processor. This improves both playback and scene refreshing speeds.
Internally, this is implemented as a task-based objects update system. The system now uses the Threaded Dependency Graph to determine when an object is ready to be updated (all it's dependencies are up-to-date) and as soon as it is ready, the object is scheduled for a new update. This is called dynamic load balance, which allows for a much more efficient use of the CPU.
This approach allows independent objects, like separate rigs, to be updated in separate threads. Also, objects which belong to the same rig are updated in multiple threads. (This is great for when a rig contains a large amount objects.)
Ideally, all the processor cores should be used during playback (giving a factor of N speedup, where N is the number of CPU threads), but unfortunately, this is not always the case. The reason is because the viewport drawing is not threaded at all and drawing code in Blender is not, relatively, very fast.
Curve Texture Space
Changes were made to how bounding box and texture space are calculated for curve objects to make curve object updates compatible for threading. Now bounding box and texture space is approximated with points, positions and curve radii.
This is an easy and predictable way to calculate the data. However, in some cases it might still be useful to have the texture space exactly match a tessellated curve. An operator was added to match texture space to the original tessellated curve. This operator can be found in the Texture Space panel in the Curve buttons.
New Guarded Allocator
A new guarded allocator has been added. There were issues with the old guarded allocator that Blender had been using for ages:
- It required thread lock when allocating/freeing memory block. This became a real bottleneck when multiple threads were allocating the memory.
- It used rather huge MemHead which is not efficient use of CPU cache.
Some tweaks had been done to the existing guarded allocator, which improved it's behavior but didn't fully solve the issues mentioned above. So a new guarded allocator was effectuated, which replaces the old one by default. This new allocator doesn't have any thread locks and uses really small memory overhead. This makes it good for threading.
A downside to the new allocator is that it is not able to give a list of non-freed datablocks, it only is able to detect memory leaks. If a message occurs, stating that there is unfreed memory, then run Blender with the --debug or --debug-memory command line argument, which will switch Blender back to old guarded allocator that keeps track of allocated blocks.
An option to lock the interface during rendering was added. The Lock Interface option is a protection against threading conflicts between render and viewport processing threads. When this option is enabled, only the Image Editors will be re-drawn and only image navigation operators (panning, zooming) will be allowed. The rest of the interface's buttons are disabled and the interface redraw is discontinued outside of image editors until the rendering is complete.
It probably will be eliminated once a prober solution is implemented (such as Copy-On-Write). Also, this option will free all data which is needed for the viewport to function. This option is helpful if Blender is having 'running out of memory' issues during renders.
One downside of the Locked Interface option is, it removes the functionality of render cancellation by clicking on [x] button in the job slider. Rendering can still be cancelled by hitting Esc. This functionality is disabled because it is not possible to predict which buttons are safe to be clicked from the WindowManager.
This is just a summary of the changes made that directly affect Blender artists. To learn more about the technical details of the project, please read GSoC project page.