Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
126 lines
4.6 KiB
Text
126 lines
4.6 KiB
Text
[options="autowidth"]
|
|
|====================================
|
|
|*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'';
|
|
Steam-Layer and Vault carry out some collaboration 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 Adaptor 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
|
|
Connectivity descriptor. 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
|
|
possibilities 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 and to spur the discussion
|
|
regarding the responsibilities of Steam vs Vault; the questions and the
|
|
details of carrying out the operations are much more involved.
|
|
|
|
Please see the
|
|
link/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)]
|
|
and the
|
|
https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/proc/engine/procnode.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=f9452f654cf39a4abbbeecfd81bef51aa347b321[Draft: ProcNode (src)]
|
|
for details
|
|
(and/or contact Ichthyo for in-depth discussion of those technical details)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Parked
|
|
~~~~~~
|
|
We park this until we have time to revisit the details. It is accepted that we
|
|
need to design this interfaces.
|
|
|
|
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|