Re: Shader Language Form Discussion

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