Dev:Ref/Proposals/Compositor2014 p1.2 TD
目次
Compositor 2014 p1.2 Tiles technical design
IST (current situation)
Although the system is called Tiles, there is no concept of a tile in the system. When a tile (part of the final result or intermediate result) a WorkPackage is created telling the system what area on what result needs to be calculated.
The system evaluates the whole tree to determine work that needs to be done. The dependencies between the tiles is stored nowhere as data, only as code, and is re-evaluated every time the system checks for new work (several times per second).
This is implemented in ExecutionGroup, and the determine_area_of_interest methods in the NodeOperation.
Issues
The idea is that creating a dependency tree between tiles the evaluation process can be more localized and will save time during execution.
As the current system all tiles have a fixed size there are some thread locking for nodes that need access to a whole image (for example ToneMap, UV Map, Glare and others). This was done so the evaluation system could be simpler.
SOLL (target situation)
In the new situation after the compositor grouped NodeOperations (reusable logic of a node) in the ExecutionGroups (set of connected NodeOperations that can be scheduled on the same device in one run), the compositor will determine the dependency between all tiles and store it in memory.
When a tile is finished, the system can update direct linked tiles if it can be scheduled. We can use a per-tile-counter to determine how many dependent tiles still need to be calculated. When the counter is zero, the tile can be scheduled.
As this system will be more transparent about tiles the system should be able to create tiles with different sizes, this should eliminate the thread locks during calculation.
Eventually the tiles state will be stored and loaded by the P1.3 buffer intermediate results project.
Adding more counters it should be faster and more accurate to determine the amount of work that still needs to be done.
We see that the Tile class is an evolution of the WorkPackage class. As different Tile sizes should be possible we can also phase out SingleThreadedOperation class.
Biggest concern is the needed building time for the Tile dependencies. In the current situation calculations were done directly after the ExecutionGroups were created. The new level of objects will add some additional building times.
