Re: Shader Language Form Discussion

Gregg: Thanks for the compile time motivation and points on async shader
compilation. It's been a big source of feedback in WebGL dev, so it's
really an important topic that we need to solve with WebGPU.

On Thu, Oct 26, 2017 at 12:06 PM Kai Ninomiya <kainino@google.com> wrote:

> Corentin:
>
> Oops, some of the </> messed up the rendering.
>
> boids (in case there were issues on any other browser):
>
> https://cdn.rawgit.com/kainino0x/7df254f5d3a2343fd1cab5f9c09e3354/raw/eeb59e11d743fc80cc8c316c3398371057e83d18/boids.comp.opt.spv.html
>
> shadertoy:
>
> https://cdn.rawgit.com/kainino0x/2504dc196b04c8db6487b2d9050329fd/raw/7b0788a8e8d5ec7a55737de4dfbaee3a7dfb84a8/shadertoy-Xds3zN.opt.html
>
> I'll reply to the other part in the other thread.
>
> On Wed, Oct 25, 2017 at 9:17 PM Gregg Tavares <w3c@greggman.com> wrote:
>
>> I don't know if this is relevant or not and how the various pipelines and
>> graphics APIs would handle this but  ....
>>
>> One problem on WebGL on ANGLE under DirectX is extremely long compile
>> times. Here's a couple of shaders that used to crash chrome on Windows for
>> me because they take too long to compile yet they run on Mac and iOS
>> (though still take 1-2 seconds to compile)
>>
>>     https://www.vertexshaderart.com/art/DWwhcFd3xWKC5yjiW
>>
>>     https://www.vertexshaderart.com/art/fRmvmXuk82tiLXCRX
>>
>> Of course they're extreme and silly shaders. I'd guess there's more like
>> that on shadertoy maybe.
>>
>> It would be nice if shader compilation was async in WebGPU and if some
>> how magically that worked without blocking on all platforms.
>>
>> AFAIK at the moment, even though like in Chrome you can kind of be async
>> by not checking for compile/link status it's really not async behind the
>> scenes.. There's one GPU process running one thread and a long compile
>> blocks that thread.
>>
>>
>>
>>
>>
>> On Thu, Oct 26, 2017 at 12:39 PM, Corentin Wallez <cwallez@google.com>
>> wrote:
>>
>>> Thanks for the data Kai.
>>>
>>> In the original shadertoy example I don't see the map function defined
>>> anywhere (it is interesting because it gets compiled to a giant mess in).
>>> Also are the 32-37ms numbers after an initial compile to gets the compiler
>>> warmed up? Such a small difference between a trivial shader and a shadertoy
>>> is surprising.
>>>
>> On Wed, Oct 25, 2017 at 9:12 PM, Kai Ninomiya <kainino@google.com> wrote:
>>>
>> With dev tools open I actually get much less variance in my results
>>>> (maybe performance.now behaves differently).
>>>>
>>>> Now I'm getting 32-37 ms for "void main() {}" and 46-49 ms to compile
>>>> the big shadertoy from earlier.
>>>>
>>> On Wed, Oct 25, 2017 at 4:13 PM Kai Ninomiya <kainino@google.com> wrote:
>>>>
>>> On Wed, Oct 25, 2017 at 11:39 AM Maciej Stachowiak <mjs@apple.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Oct 25, 2017, at 10:49 AM, Corentin Wallez <cwallez@google.com>
>>>>>> wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> I know you said "it might", but I'm not sure this is true. There are
>>>>>> many human-readable languages normally have high interoperability, arguably
>>>>>> higher than SPIR-V does. The main factor affecting interop is precision of
>>>>>> the spec, not whether the formal is text or binary.
>>>>>>
>>>>>>
>>>>>>    - Browser engineering. How much do the compiler add to the
>>>>>>    browser attack surface and binary size.
>>>>>>
>>>>>> Note that whether we use an "IR" or "SL" format, we need to include
>>>>>> in this complexity all the required validation and translation logic. I
>>>>>> mention this because human-readable text formats are often easier to
>>>>>> validate than SSA-level formats, since the parser proves many of the
>>>>>> desired well-formedness constraints automatically.
>>>>>>
>>>>>>
>>>>>>    - 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.
>>>>>>>
>>>>>>
>>>>>> It seems like the second and third options are nearly equivalent in
>>>>>> capability. The third makes it less convenient and potentially less
>>>>>> efficient to use the SL form. But both expose the additional
>>>>>> interoperability considerations and security attack surface inherent in
>>>>>> consuming two different formats to about the same degree.
>>>>>>
>>>>>> [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?)
>>>>>>>
>>>>>> Apologies for not doing this before our meeting today, but here are
>>>>> some shaders compiled from GLSL to SPIRV, optimized, and decompiled. I hope
>>>>> these help everyone understand the level of abstraction that is provided by
>>>>> SPIR-V (and as a bonus, the quality of a potential "decompiling View
>>>>> Source" dev tool). They are quite educational for me as well.
>>>>>
>>>>> An example of a small but not-quite-trivial shader we used in the very
>>>>> first NXT demo. I inserted extra line breaks to make the rows line up.
>>>>>
>>>>> https://cdn.rawgit.com/kainino0x/7df254f5d3a2343fd1cab5f9c09e3354/raw/fbcb4815877c6344d587106879be6b10aa10155c/boids.comp.opt.spv.html
>>>>>
>>>>> Here is a much larger example, iq's famous "Raymarching - Primitives"
>>>>> resource for the ShaderToy community. (I grabbed it from Dev Tools by
>>>>> breaking at gl.shaderSource, and modified it slightly to compile with
>>>>> shaderc.) The code got reordered, so I didn't pretty it up.
>>>>>
>>>>> https://cdn.rawgit.com/kainino0x/2504dc196b04c8db6487b2d9050329fd/raw/483e7ae1d8383aa8c61ac751fbe45c0f5931e5f4/shadertoy-Xds3zN.opt.html
>>>>>
>>>>> * 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
>>>>>>> <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
>>>>>>>
>>>>>>