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

Re: [Public WebGL] Caching shader compile assembly

On Wed, May 2, 2012 at 4:50 PM, Conor Dickinson <conor@cloudpartyinc.com> wrote:
Not sure if this email should go to this mailing list or not, so if there is a better place for this please let me know.

I have found that calls to linkProgram for our shaders take between 300 ms and 800 ms on Windows in Firefox and Chrome, but on Mac they take less than 10 ms.  My guess is that the extra time comes from the GLSL -> HLSL -> assembly conversion that doesn't happen on Mac (I know that HLSL -> assembly is extremely slow because of all the optimizations that D3D runs on the shaders).

For us this is taking about 6 to 8 seconds of our load time even if all of our assets are in the browser cache.  Is there any way that the browser can cache the results of the shader compiling so that subsequent visits to our app do not take so long to load?  I can definitely understand not wanting to give us back the assembled shaders to cache ourselves (for privacy reasons), but it seems reasonable for the browser to cache the results based on the shader string, GPU, and driver version.

You could do this in a safe way, by encrypting the data with a key stored on the user's system; all the web app would see is an opaque, random-looking blob.  This would be perfectly safe.  (It would also include a hash of the shader source; if it doesn't match, or doesn't decrypt, or if the browser version, etc. have changed incompatibly, it would simply be ignored and compile the shader from scratch.)

I don't think it's possible to implement this for GLES-based implementations, but if it's possible on D3D-based implementations, it could probably be done.  On systems not supporting it, it would simply always return the empty string, so it always recompiles.

Glenn Maynard