| State | Parked |
| Date | 2008-03-06 |
| Proposed by | Ichthyostega |
Design the Render Nodes interface
In the current design, the low-level model is comprised of "Render Nodes";
Stean-Layer and Vault carry out some colaboration based on this node network.
Three different interfaces can be identified
* the node wiring interface
* the node invocation interface
* the processing function interface
Description
Render Nodes are created and wired by the Builder in the Steam-Layer. On the other hand, the rendering process is controlled by the vault layer, which also provides the implementation for the individual data processing tasks. To create a result, output nodes are 'pulled' via the invocation interface, resulting in the affected nodes to recursively pull their predecessor(s). In the course of this call sequence, the nodes activate their processing function to work on a given set of buffers. Moreover, we plan to use the render network also for gathering statistics.
''Note': Render Node is an internal interface used by Steam-Layer and activated by the Vault. Plugins are planned to be added via Adapter nodes. Thus the Render Node interface needs ''not' to be exported.
the wiring interface
This part of the design defines how nodes can be combined and wired up by the builder to form a network usable for rendering. For this purpose, the ProcNode is used as a shell / container, which is then configured by a const WiringDescriptor. Thus, the node gets to know its predecessor(s) and is preselected to use a combination of specific working modes:
-
participate in caching
-
calculate in-place
-
source reading
-
(planned) use hardware acceleration
-
(planned) remote dispatched calculation
Most nodes will just have a single predecessor, but we can’t limit nodes to a single input, because there are some calculation algorithms which natively need to work on several data streams simultaneously. This means, a single node can be involved into the calculations for multiple streams (several pull calls on the same frame number but for different channel, and in each case maybe a different output node). I decided to rely solely on the cache for avoiding duplicate calculations caused by this complication, because I deem it to be an corner case.
the invocation interface
this is intended to be a rather simple "call-style" interface, without much possibilites to influence the way things are happening. You pull a node and will find the results in a provided buffer or the cache, but you can’t even change the frame data type type of the result. Besides the node invocation, functions for collecting statistics will be accessible here too (Probably these functions will be 'implemented' in a classic-OO fashion by virtual functions, but that’s another story)
the processing interface
the individual nodes are configured to call a plain-C {{{process()}}} function and provide an array of buffer pointers to be used within this function. For the purpose of invoking actual data processing, it is irrelevant if this function is implemented somewhere in the vault layer or provided by a plugin. At this point, no type- and other meta-information is passed, rather the processing function is supposed to do The Right Thing TM
Tasks
-
What services do we expect from Render Nodes. What do we plan to do with a render node?
-
What different kinds (if any) of Render Nodes can be foreseen?
-
order the required functionality by Steam / Vault. Find out specific implementation constraints.
-
work out a design based on this informations
Rationale
The purpose of this Design Entry is to give a summary; the questions and the
details of carrying out the operations are much more involved.
Please see the
Development internal doc (TiddlyWiki)
and the
Source Code
for details
(and/or contact Ichthyo for in-depth discussion of those technical details)
Comments
Parked
We park this until we have time to revisit the details. It is accepted that we need to design this interfaces.
Do 14 Apr 2011 03:06:42 CEST Christian ThaeterBack to Lumiera Design Process overview