[Bf-committers] Proposal for unifying nodes

Keir Mierle mierle at gmail.com
Mon Jun 15 18:55:57 CEST 2009


On Mon, Jun 15, 2009 at 9:44 AM, Robin Allen <roblovski at gmail.com> wrote:

> Hi Keir
>
> 2009/6/15 Keir Mierle <mierle at gmail.com>:
> > If I recall correctly, the reason for the separation of node tree
> > types was that material nodes need to be high performance. Making nodes
> general
> > would impose high performance penalties on shader nodes, which
> > evaluate their trees millions of times.
>
> Under the new system, shader nodes would not evaluate their trees
> millions of times. The tree would be evaluated once and return a
> Shader object, which itself would be evaluated millions of times. The
> shader object is not general in the sense that the node system is, it
> is optimized for being evaluated millions of times. So no performance
> penalty.


I'm not sure I follow. If the node system is used to construct a shader,
then the shader is as general as anything you can express in the node
system. So how would evaluating a shader object differ from evaluating a
node tree? Why would it be faster? What is inside the Shader object?


> > (... LLVM stuff ...)
>
> The good thing about the unified node system is that you can layer
> whatever you like on top of it, including, if necessary, some form of
> JIT compiler. If this would benefit the shader system, simply evaluate
> the nodetree as normal to return a Shader (once!) then define a
> CompiledShader* compile(Shader*) function to be called on that shader.
> At this point the node system no longer has anything to do with it --
> it can't restrict you in any way.


I don't see the difference between a node tree and a shader (both of which
express dataflow computations). Whether it's called a node tree or a shader,
they do the same thing. If you have a different way of expressing dataflow
computations for shaders and for node trees, then we're back to square one.

By JIT compiling the computation expressed by the node trees, then
everything becomes both general and fast. There is no need for separate tree
types.

Keir


More information about the Bf-committers mailing list