[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Support precompiled shaders as extensions



>Depends on the D3D version (DX9 binaries are different than DX11 binaries)
These can be just 2 different extensions.

>You need the D3D compiler to sign your binaries (DX will refuse to run unsigned binaries)
So, developer can use D3D compiler to produce binaries. There are 2 dev pipelines I see:
- Write GLSL, use WEBGL_debug_shaders to get HLSL, compile on your own (I do it myself to check shader asm in weird cases).
- Write HLSL, compile, use something like https://github.com/aras-p/hlsl2glslfork to also generate GLSL for other platforms.

>It only works on windows
Yes, that's why it can be an extension. Windows isn't a small percent.

>we don't want to make "Windows only WebGL". We've fought long and hard to not end up exactly there
I certainly don't want "Windows only WebGL" as much, as you do. However, platforms differ, and we must take their differences into account if we want WebGL to evolve. Currently it's quite possible to have all your textures in, say, PVRTC format. Does it create an "iOS-only WebGL"? Maybe, but nobody does that, every sane developer will supply standard jpgs/pngs, if the compressed format is not supported.

> cross-compile shaders for those, and supply those shaders, and so forth. Dragons live there.
We already do this for textures. It's not that scary, and it frees a lot of VRAM ;)

>OpenGL shader binary
I admit, I'm not that familiar with desktop GL (my experience is only D3D and WebGL). It's a pity if it's that bad.

I still believe that using precompiled shaders is a very good idea for DX9/DX11 platforms. It's better to be faster on Windows, than being slow everywhere.

On 14 November 2016 at 18:03, Florian Bösch <pyalot@gmail.com> wrote:
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.