Re: Shaderc as a JS library

Maciej:
> I guess how relevant this is depends on how long the rest of the pipeline
takes.

Yeah, it's quite hard to make these comparisons, especially with just this
one bit standing alone.

> *SPIR-V ingestion path*: (30-50ms for software conversion) + validate
well-formedness constraints and safety restrictions + emit native shader
with required runtime checks + native API compile time
> vs
> *Secure HLSL ingestion path*: parse + typecheck and do any other required
compile-time checks + emit native shader with required runtime checks +
native API compile time

Thanks for this comparison, it's useful to look at the complete code paths
from above to understand better how the two options compare. I agree with
these summaries. Of course, the parenthesized bit is optional and we would
hope that most high-performance applications won't have to use it.

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

> Corentin (from other thread):
> > 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.
>
> These are both at page startup, I don't think anything should still be
> warm from the last page load, by that point.
>
> On Thu, Oct 26, 2017 at 10:57 AM Kirill Dmitrenko <dmikis@yandex-team.ru>
> wrote:
>
>> Thanks!
>>
>> 26.10.2017, 20:49, "Kai Ninomiya" <kainino@google.com>:
>> > Good idea. Here:
>> > http://kai.graphics/shaderc-demo/
>> >
>> > On Thu, Oct 26, 2017, 5:20 AM Kirill Dmitrenko <dmikis@yandex-team.ru>
>> wrote:
>> >> Can you create a static page somewhere (e.g., on GH itself) to test
>> the library?
>> >>
>> >> 26.10.2017, 04:13, "Kai Ninomiya" <kainino@google.com>:
>> >>> oops. wrong thread. reposting in the correct thread.
>> >>>
>> >>> 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 5:57 PM Kai Ninomiya <kainino@google.com>
>> wrote:
>> >>>> Maciej,
>> >>>> Absolutely. These are on my to-do list, but they're harder to check
>> and compare with native.
>> >>>>
>> >>>> I quickly measured the compile time itself (excluding loading, I
>> don't know offhand how to measure that), and got about 85-140 ms for this
>> tiny "main(){}" shader. I don't know how this compares with native.
>> >>>>
>> >>>> -Kai
>> >>>>
>> >>>> On Wed, Oct 25, 2017 at 5:34 PM Maciej Stachowiak <mjs@apple.com>
>> wrote:
>> >>>>>> On Oct 25, 2017, at 5:26 PM, Kai Ninomiya <kainino@google.com>
>> wrote:
>> >>>>>> Hey all,
>> >>>>>>
>> >>>>>> Yesterday I compiled shaderc into a JS library with the minimal
>> entry points needed to compile GLSL to SPIRV inside a web application.
>> >>>>>>
>> >>>>>> <Screenshot from 2017-10-24 17-17-52.png>
>> >>>>>>
>> >>>>>> Source (But don't try to build this yet, it won't work - needs
>> manual intervention during build).
>> >>>>>>
>> https://github.com/kainino0x/shaderc/commit/1035e488ac3dcf759d6017328abf20d1d39b672f
>> >>>>>>
>> >>>>>> kainino@kainino> du -b shaderc.*
>> >>>>>> 176816  shaderc.js
>> >>>>>> 45094   shaderc.js.gz
>> >>>>>> 2007815 shaderc.wasm
>> >>>>>> 589023  shaderc.wasm.gz
>> >>>>>> So a total of 634,117 bytes between shaderc.js.gz and
>> shaderc.wasm.gz.
>> >>>>>>
>> >>>>>> (built with emcc -Oz; js files are the wasm wrappers, not asm.js)
>> >>>>>>
>> >>>>>
>> >>>>> Other interesting performance questions:
>> >>>>>
>> >>>>> - What's the runtime memory cost of loading or using these
>> libraries?
>> >>>>> - How long does it take to transpile a typical shader?
>> >>
>> >> --
>> >> Kirill Dmitrenko
>> >> Yandex Maps Team
>>
>>
>> --
>> Kirill Dmitrenko
>> Yandex Maps Team
>>
>