Re: Shaderc as a JS library

> On Oct 25, 2017, at 6:12 PM, Kai Ninomiya <kainino@google.com> wrote:
> 
> 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.

I guess how relevant this is depends on how long the rest of the pipeline takes. We'd be comparing:

*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

If the rest of the path is on the order of multiple seconds, then clearly this time cost doesn't matter. If around 50 ms or less, then this would be a huge impact.

As it is, I think the only part of the path we can measure is the native API compile time.

 

> 
> On Wed, Oct 25, 2017 at 5:57 PM Kai Ninomiya <kainino@google.com <mailto: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 <mailto:mjs@apple.com>> wrote:
>> On Oct 25, 2017, at 5:26 PM, Kai Ninomiya <kainino@google.com <mailto: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 <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 <https://kripken.github.io/emscripten-site/docs/tools_reference/emcc.html#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?
>