-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp Klaus Krause wrote: > - From time to time people say that they want support for precompiled > shaders in the OpenGL API. The main point for this they bring forth is > reducing loading times for their applications. > > I think this advantage of precompiled shaders can be had without support > for it in the API: It can be inmplemented transparently in the driver. > > When the application passes a shader source to be compiled to the driver > the driver calculates a cryptographic hash of the source and relevant > settings such a some hints. The driver then looks into it's cache of > compiled shaders for one with the same hash value. If there is one, use > it - no need to compile the source again. If there is none, compile it, > store it in the cache along with the hash value.
So...ccache for GLSL? I like it. The problem is that a lot of GLSL code is dynamically generated. This means that applications that primarily used dynamically generated shaders would always take a performance hit. If the application has to implement the shader cache on its own, it would know to not bother trying to cache dynamic shaders. > There is no additional work for the application programmers to do. They > will automatically receive the benefit of faster application startup. > The driver knows best when it has to recompile (e.g. after a driver > update). The cache size is expected to be rather small, and today's > hard-disks are large. > > The cryptographic hash ensures that no application will intentionally or > accidently use shaders from another application. > > How much work would it be to implement this in Mesa? Should the shader > cache be made global or per-user? Like ccache, I think we'd want it to be per-user. I don't think making it global would save that much, and it would open the door for potential security problems. It shouldn't be too much work. The main problem is that we don't have any infrastructure to dump out the compiled code. Implementing that would be 95% of the work. Note that the exact same infrastructure would be needed to implement GL_OES_get_program_binary. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkk95QAACgkQX1gOwKyEAw9XegCgmLlZe9d+s7soe/cV6QzzMj26 /BoAn35ulLbYD4puwQ2jAx7eM7fYUsbc =q+zz -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
