Falcor: design and implement approach for specialization

[tangent-vector]

This is strongly related to #16.

Given a shader with some set of "top-level" parameters, such as a Material, we need a way to inform the compiler that for a given variant to be generated, the implementation of that parameter's type should be specialized in a particular way (based on an actual run-time C++ object of type Falcor::Material in the Falcor case).

The ideal API interface is then relatively simple:

• A shader entry point may include parameters (possibly declared at global scope) that belong to a high-level "module" type like Material or Light

• When low-level code generation is requested for an entry point, we can specify a concrete type to substitute in for the parameter (any parameter where we don't specify this will ideally be left as a "generalized" parameter.

This seems to require a few things not present in the code today:

• We need to flesh out the system for interface declarations (currently using the __trait keyword), and allow interface implementations and interface-typed parameters.

• We need to split the code-generation API up (or at least support splitting it) into two phases:

  1. An AST generation and checking phase, that produces a representation suitable for reflection
  2. A low-level code generation phase, where the user requests compilation of one or more entry points into low-level code.

  Actually, there might be a step (1.5) in that flow, which is where one creates target-specific "layout" objects from the raw AST objects to represent how parameters would be bound for a target.

[tangent-vector-personal]

Generics support and specialization in the API is working well. There is no reason to keep this issue open.