[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] async shader compiliation
Shader compilation performance is something that comes up often when working with game developers who use Emscripten and asm.js to port their engines. Firefox has an about:config flag to enable or disable the use of ANGLE at runtime on Windows. Disabling ANGLE speeds up shader compilation by a factor of 3x-10x.
Doing async/background thread compilation of shaders would be cool, but it's not an ultimate solution since it is only a latency hiding technique which won't reduce power consumption for mobile and low end desktop. Here's some other suggestions (not mutually exclusive):
1. Microsoft has recently open sourced their HLSL shader compiler codebase, which is available at https://github.com/Microsoft/DirectXShaderCompiler
. One effect of getting open sourced is that a few months back I noticed I started getting .pdb files of shader compiler served when doing geckoprofiler/CodeXL/VTune profiles of WebAssembly applications, which gives visibility to the hotspots in d3dcompiler_xx.dll. This compiler was not originally intended to be an online compiler, so it's uncertain how much of it has been optimized for speed. Perhaps the problem could be tackled directly at the source and D3Dcompiler optimized to improve compilation times? I don't think this has ever been looked at from an online compiler perspective, so perhaps there are some low hanging fruit. Any % of benefits here would be direct wins on top of whatever other techniques are used.
2. Let's enable binary compiled shaders on the web by leveraging https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_get_program_binary.txt
, which is in core OpenGL 4.1 and OpenGL ES 3.0. Allow one to pull out an opaque blob (nontransferrable between PCs, invalidatable by browser between page visits) of compiled shader programs and stick those to IndexedDB. This way at least warm page visits will be fast. On cold page visits one might be able to rearchitect shaders to be compiled parallel to downloading other page assets (textures, geometry, WebAssembly code) to hide most of the impact.
3. Let's do binary SPIR-V shaders on the web. Can SPIR-V binary shaders be standardized to WebGL? There exists an extension to consume SPIR-V in desktop OpenGL at https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt
. Can Khronos work to standardize this on OpenGL ES as well so that it could then be translated over to WebGL? This would allow compiling all needed shaders fully offline.
4. Cache compiled shaders in browsers internally for warm page loads to be fast. Not as ideal as 2. or 3. but could work.
To me it feels that #1 and #2 could be the best near term prospects for WebGL.