Shader Language Form Discussion

Hey all,

We said we would resume the shader language "levels" discussion via email,
so here we are. (Apologies that it's so late.) I'll try to start this off
with some concrete ideas before we dive into the rabbit hole. Please add
suggestions as necessary. We'll be talking about shading languages again
this Wednesday, so I'd ask everyone to spend some time to think about the
topic before then.

The forms of language we've discussed:

* "SL". High-level, human-authored, highly-structured, imperative,
whatever-you-want-to-call-it language, like WSL, HLSL, or GLSL.
* "IR". Machine-generated, typically-SSA, lower-level, canonically-binary
representation, like SPIR-V or DXIL.

The alternatives we've discussed:

* WebGPU ingests SL only.
* WebGPU ingests both SL and IR. We bless an offline SL->IR tool.
* WebGPU ingests IR only, but we have a Web API to compile unsecured SL to
unsecured IR. We bless an offline SL->IR tool.
* WebGPU ingests IR only. We bless both online and offline SL->IR tools -
an online compiler is required for some applications.
[1] A shader compiler may, for example, be a WebAssembly module on a CDN.

In any alternative, we seem to agree to bless an SL. We bless/provide tools
for that SL, and documentation is written using that SL. The browser
compiles its ingested language to a secured shader in the native API's
ingested language.

Some trade-offs we've discussed:

* Compilation performance. SLs may be more expensive to compile. IRs may be
expensive to compile securely - we're working on this one.
* Runtime performance. Could a practical SL be more "performantly
securable" than an IR?
* View Source. Vocal web developers have complained about the View Source
story for WebAssembly. (And how well could we mitigate this if needed?)
* Compiler maintenance. SL compilers may be more prone to bugs. (Critical
for any compiler/translator that must enforce security boundaries.)
* Download/initialization time. Probably not a significant issue for either
format after compression, but we also have to consider the download and
compile time of, e.g., runtime shader compiler modules.
* Ecosystem bootstrapping. There a lot of HLSL and GLSL out there, in the
form of libraries, sample code, and existing engines (including WebGL).
* Development time for the ingested format. Probably not an issue if we
start out with HLSL or GLSL.
* Soundness/provability. We differ on whether this is important at all, and
whether it's easier for SL or IR. Probably not worth discussing right now?

Please add topics to this list. I have one more:

* Code reuse. Some engines (like Three.js) manipulate shader strings to
generate shaders at runtime; if we only ingest IR, they would have to
either use a new method or add a shader compiler. On the other hand, some
engines may(?) prefer to use concepts like SPIRV's specialization and
linking.

Relevant notes for review:

2017-09-22 (F2F):
https://docs.google.com/document/d/1VridLAmC05h80_d-FGmwyI7On0_AY5y8pVGI-TT4ysQ/edit
2017-10-11:
https://docs.google.com/document/d/1-ciiWbGletoOXOGrBBZpOhhWEWJcIqK0Bb-dtHJ8ffE/edit

-Kai