Re: [public-gpu] <none>

Hey Kirill,

Thanks for your thoughts. Shaders will be one of the biggest obstacles for
applications to adopt WebGPU, and we should take it into consideration in
the shading language discussions. This is related to a comment Chas made
last meeting that if we only specifying an IL, we will foster innovation in
the high-level shading language space. We should be cognizant of this and
decide wether we want to allow innovation, or try to push the developers
towards one blessed high level language.

As for performance of shader code ingestion, I'm sure we'll find a way to
make it either asynchronous or parallelizable.

Cheers,

Corentin

On Fri, Aug 25, 2017 at 8:09 AM, Kirill Dmitrenko <dmikis@yandex-team.ru>
wrote:

> Hi all!
>
> I want to add a couple of things to think about in designing shader
> languages/IRs in WebGPU.
>
> The first one is compatibility with existing shader authoring systems. If
> we'll come up with something significantly semantically different from
> HLSL/GLSL, it may complicate adoption of WebGPU by engines/apps that use
> those authoring systems.
>
> The second one is performance of shader code ingestion (whether source
> code or IR). Right now WebGL apps with complex shaders experience problems
> with that. That problem may be somewhat mitigated by ability to compile
> shaders on a separate thread/worker.
>
> Both those concerns aren't as important as security and portability, but,
> I think, are something to keep in mind.
>
> --
> Kirill Dmitrenko
> Yandex Maps Team
>
>