Re: [Public WebGL] Support precompiled shaders as extensions

[John Kessenich <cepheus@frii.com>]

SPIR-V is higher level to avoid platform-specific optimizations that are sometimes in DX bytecode, and is also more portable than GLSL.  However, SPIR-V could be offline optimized (as tools become more available) if the ISV was sure it was the right thing to do for the target set of platforms.

Do we have data that the size problem is real? The discussion seemed concerned with compile-time performance (while staying secure) up to this point, which should only be improved by SPIR-V.  We are looking at improving tools to that fix the size of SPIR-V, so data there will be useful.  SPIR-V itself could be smaller, but it was decided that portability and simplicity were more important design goals.  Data to revisit that is also interesting, as SPIR-V has room for a different schema that would be smaller (only makes sense for non-compression tool chains).

Thanks,
JohnK

On 11/14/2016 12:21 PM, Corentin Wallez wrote:

SPIRV would be nice as a universal IL, however it doesn't solve your problem: it doesn't compress as well as GLSL and would just remove the cost of parsing GLSL in ANGLE, which is nothing compared to the driver's compilation cost.

On Mon, Nov 14, 2016 at 2:14 PM, Mr F <arthur@playcanvas.com> wrote:

SPIR-V can be a good idea indeed as something more lightweight and low-level than GLSL.

On 14 November 2016 at 21:02, Neil Trevett <ntrevett@nvidia.com> wrote:

Is SPIR-V as a ‘shader lingua franca’ a possible path forward?  Can be natively ingested in many places already, and is specifically designed to enable easy, efficient mapping to other IRs.

 

From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Frank Olivier
Sent: Monday, November 14, 2016 9:38 AM
To: Florian Bösch; Maksims Mihejevs
Cc: Mr F; public
Subject: RE: [Public WebGL] Support precompiled shaders as extensions

 

“At one point Microsoft was noncommittal what GLSL format to support and also wanted to left the language wholly undefined. This would've harmed the web platform a lot.”

 

I’m surprised by this statement. Our goals for WebGL have always been to have interoperable and well-defined implementations and specifications.

 

 

 

 

From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Florian Bösch
Sent: Monday, November 14, 2016 7:04 AM
To: Maksims Mihejevs <max@playcanvas.com>
Cc: Mr F <arthur@playcanvas.com>; public <public_webgl@khronos.org>
Subject: Re: [Public WebGL] Support precompiled shaders as extensions

 

On Mon, Nov 14, 2016 at 3:11 PM, Maksims Mihejevs <max@playcanvas.com> wrote:

It does not feel that binary shaders is a complex feature. All background workings of WebGL already has functionality to deal with it I'm sure. It is only about exposing such functionality using extensions notation based on platforms.

 

Precompiled shaders are quite a huge problem. There's two main scenarios to consider:

 

D3D bytecode shaders

 

Supplying your shaders are precompiled D3D bytecode has a number of problems, these are:

1. Depends on the D3D version (DX9 binaries are different than DX11 binaries)
2. You need the D3D compiler to sign your binaries (DX will refuse to run unsigned binaries)
3. It only works on windows

This presents a substantial problem for the web, we don't want to make "Windows only WebGL". We've fought long and hard to not end up exactly there. At one point Microsoft was noncomittal what GLSL format to support and also wanted to left the language wholly undefined. This would've harmed the web platform a lot.

 

Besides the above issues are also a considerable maintenance nightmare, as you now need to be aware against which backend you run your code, and which version of which backend, and cross-compile shaders for those, and supply those shaders, and so forth. Dragons live there.

 

OpenGL shader binary

 

The unsurmountable problem with this format is that it's GPU, driver and OS specific. You'd have to precompile your shaders for every conceivable combination of those. It's not intended to be used as a transport format, but rather a format to cache shaders on the local machine that that machine has compiled.

 

 

-----

 

Since both these options are extremely bad, that's why I said precompiled shaders (short of WebVulkan) are a complete nogo, for any developer, in any scenario, in WebGL.