Topology override evaluator for fine grain evaluation graphs.
Evaluation graph is representing evaluation requirements and dependencies between them. We coupled granularity of evaluation graph to granularity of dependency graph by making smallest execution equal to single dependency node. In many cases this causes no trouble and we can use custom evaluators to group bunch of nodes together and reduce the number of execution. But there are real cases where being able to express single dependency node as multiple executions (= multiple evaluation nodes) can give us better control about how things are evaluated and unlock even more performance. Some of this was possible as part of cluster evaluation, but evaluating a single node and scheduling evaluation of cluster evaluation was non-trivial and in many cases would just create instabilities.
New concept was created which allows topology override of evaluation graph. This makes possible to have total control over granularity, leverage already existing scheduling constraints and scheduling graph. Supports partial evaluation for minimal evaluation of cluster content. Finally, allows better resource utilization since execution of cluster content doesn't have to wait for entire upstream to start and downstream can start as soon as dependencies are ready (sort of transparent clusters, but much more configurable and with no constraints on granularity).
Note
This type of evaluator is claiming nodes in the same way as any other evaluator (i.e. marking if supported). Evaluation is completely done by subgraph nodes, meaning none of evaluation methods will be called on this evaluator and this is why they are final.
This call marks node as supported by the evaluator. It is safe to cause evaluation in this call, but this evaluation cost will increase partitioning time and won't reduce the next evaluation time. It is up to the developer to decide whether evaluation is required or the already-evaluated data in the datablock can be used. Call .outputValue/.outputArrayValue in the first case and .inputValue/.inputArrayValue in the second (the first is preferred).
Zero, one or more nodes can be marked by this call, since the dependency node design can involve multiple nodes being joined in a single setup (e.g. IK chains).