On Tue, Dec 9, 2008 at 3:24 AM, Ian Romanick <[EMAIL PROTECTED]> wrote: > -----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.
The slight difficulty I see with this is that at the hardware level, a single GLSL shader can produce many HW shaders as additional GL state is mixed into the compliation process. The amount of extra state consulted can vary from not much to quite a lot. The i965 driver makes this fairly explicit with the brw_vs_prog_key and brw_wm_prog_key structures. The latter is pretty large and has unfortunately grown to include the current window position, meaning that shaders will get recompiled whenever you move the window (on DRI1), apparently even if they don't reference the fragment position. (I'm sure there's a quick fix to improve this, like setting these to zero if fragpos isn't referenced). This doesn't prevent caching compilation results, it just means that in practice it'll need to be orchestrated by the driver rather than core mesa. Maybe core mesa could cache GLSL->IR and the driver could cache (IR+extra-state)->HW. Keith ------------------------------------------------------------------------------ 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
