[Bf-committers] Proposal for unifying nodes

Robin Allen roblovski at gmail.com
Mon Jun 15 19:48:20 CEST 2009

2009/6/15 Keir Mierle <mierle at gmail.com>:
> 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?

> 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.

On second thoughts, I think you may be right. The unified system
probably would take longer to evaluate shaders, no matter how you cut
it. LLVM is definitely worth looking into; I'm going to have to look
at it some more before I can provide a better response.

What is unclear, though, is exactly how much of a performance hit
there would be. It's entirely possible that it wouldn't be noticeable,
if done well.


More information about the Bf-committers mailing list