Ichthyostega
7d237647d4
In the past we allowed a lot of leeway when referring to our web-interface to the Lumiera Git repositories (git.lumiera.org/gitweb) Unfortunately this caused the AI scraper bots »out there« to capture millions of URLs for all the different flavours of spelling them out. And now they haunt our website and try to scrap that content again and again; even while we effectively prevent that kind of abuse, rejecting those ongoing attempts at content-scraping causes a dangerously high amount of traffic. With this changeset, all cross references in the documentation section are rewritten to the only remaining valid form of that Gitweb URL.
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/gitweb?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]
|