Missing node types

[dragostis]

Some node types are missing from the Node enum like bitwise operators. Maybe we can make a check list with them in this issue.

[leops]

I went through the SPIR-V specification and the GLSL 450 instruction set, and this is the list of node I came up with:

• Input
• Uniform
• Output
• Constant
• Construct
• Set
• Extract
• Normalize
• Add
• Subtract
• Multiply
• Divide
• Modulus
• Clamp
• Dot
• Cross
• Floor
• Ceil
• Round
• Sin
• Cos
• Tan
• Pow
• Min
• Max
• Length
• Distance
• Reflect
• Refract
• Mix
• Sample
• Transpose
• Negate
• OuterProduct
• ShiftRight
• ShiftLeft
• BitOr
• BitXor
• BitAnd
• BitNot
• Select
• Not
• Or
• And
• Any
• All
• IsNan
• IsInf
• Equal
• NotEqual
• Greater
• GreaterEqual
• Less
• LessEqual
• Abs
• Sign
• Frac
• Asin
• Acos
• Atan
• Sinh
• Cosh
• Tanh
• Asinh
• Acosh
• Atanh
• Atan2
• Exp
• Log
• Exp2
• Log2
• Sqrt
• InvSqrt
• Inverse
• Determinant
• Modf
• Step
• SmoothStep
• FaceForward

Most of these are simple operations and map more or less to a single corresponding SPIR-V instruction, however there's still a bunch of functionalities I want to eventually include in Rasen but isn't in the list because I haven't really figured out a nice way to represent it (stuff like functions, atomics, loops ...)

[dragostis]

Purely functional functions can be wrapped in a macro that will execute the function and wrap it in a function AST node. Loops could either be unrolled or crated from an Iterator with a specialized collect method. I've thought quite a bit about the problem and I think I have a decent design, very similar to what you did with Rasen. Maybe there is a prospect for collaboration if you're interested?

[leops]

I would indeed be interested by design ideas since you seem to be referring to the DSL, and I haven't really got there yet, the representation I was talking about being the lower-level data flow graph. I think I have a viable approach for functions (a Module struct holding multiple Graph instances referencing each other with Call nodes), but loops are a bit more of an head scratcher (the most promising design I have is having a set of Generator, Map and Reduce nodes, but that might be too complex for any practical use), and atomics are just awkward (they are both an Input and an Output at the same time, and graph operations have no guaranteed order of execution)