Re: Shader Language Form Discussion

Thanks Kai for putting this together, a couple more trade-offs would be the
following:

   - Interoperability. It might be more difficult to have to have multiple
   implementations be interoperable with a SL.
   - Browser engineering. How much do the compiler add to the browser
   attack surface and binary size.
   - Governance. How do we make changes to the SL / IR, who's involved.
   - Portability to MSL, HLSL and SPIR-V. This so important that we forgot
   it ^^.


On Tue, Oct 24, 2017 at 2:21 AM, Kai Ninomiya <kainino@google.com> wrote:

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