Falcor: design for exposing "modules" to user code

[tangent-vector]

We need a POR for how a conceptual module like Material will be exposed to user code in both HLSL and GLSL in a way that works with:

• The limitations of both languages and the compilers that will be used for each (e.g., the non-overlapping bugs in both fxc and dxc)

• The constraints of what we are willing to let the "rewriter" mode in Slang do (e.g., we currently don't let it rewrite anything in function bodies)

Of course we also want a model that is as usable and natural for users as possible.

Going back to the "rosetta stone" sketch that outlined the "rewriter" architecture, there are two key challenges;

1. What to do when a module conceptually contains both "ordinary" uniform parameters (e.g., a float3) and "resource" parameters (a `Texture2D). The various langauges/compilers we need to work with have varying levels of support for types that mix up resource and ordinary parameters.

2. What to do when there is a single conceptual type Material, but there might be specialized versions of it used in specific cases (but not all)?

and the POR for how to solve them is something like:

1. This is officially Falcor's problem, not Slang's, since a complete solution to the mixed-type-struct problem is out of scope for what the "rewriter" is supposed to do. That said, I expect that if we can find a way to sole the problem using Slang, nobody is actually going to complain.

2. The intention is to expose a syntax that the user sees as a macro invocation, e.g., PARAMETER(Material, m);, but that is actually custom syntax that can expanded to a different type based on how a parameter will be specialized.

Item (2) obviously requires a complete design and has API implications, so it is the important bit to focus on first. Item (1) is actually conceptually straightforward, even if there is a lot of detailed work in implementing it.

[tangent-vector-personal]

This feature request has been implemented as “parameter blocks,” more or less.