Developer Guide Release

Binary Shader Program Management
Application Management of Binary Programs
Automatic Shader Cache
Comparison and Combination
Pre-built binary shader programs eliminate compilation time for individual shaders. If all programs are pre-built, the driver may avoid consuming additional time and resources by not loading the compiler libraries at all. Program binaries can be compiled and linked by an application calling the OpenGL ES API directly at runtime or prebuilt with the glslc offline shader compiler.
The NVIDIA® SDK no longer supports the GL_NV_platform_binary extension for use with the OpenGL ES 2.0 glShaderBinary function. Program binaries can be saved and loaded either by an application calling the OpenGL ES API directly, or using the automatic shader cache.
Application Management of Binary Programs
Applications can control binary program management directly. With the glGetProgramBinary function added in OpenGL ES 3.0, applications can read back the binaries for any compiled and linked programs, and store them for later use. The glProgramBinary function loads these saved binaries. Unlike the glShaderBinary function in OpenGL ES 2.0, this operates on a linked program instead of individual vertex and fragment shaders, so there is no additional link step required after loading the binary.
Automatic Shader Cache
When the proprietary NVIDIA shader cache support in the driver is enabled, the OpenGL ES 3.0 driver maintains a shader cache file for each program. When an application specifies a shader source, the driver first searches the cache to see if it has already compiled this source with the current version of the compiler. If not, it compiles the program and then saves a copy in the cache. If the shader has been previously compiled, the driver loads the pre-built binary from the cache. The cache persists between application runs, so that with a thorough initial test run, compilation need only occur the first time a new driver is installed.
The shader cache is enabled on read/write file systems by default. Assign the __GL_SHADER_DISK_CACHE environment variable a value of 0 to disable the cache.
The cache is disabled by default on read-only file systems because new entries cannot be added to the cache. This behavior can be overridden by setting the __GL_SHADER_DISK_CACHE_READ_ONLY environment variable. Use a value of 1 to enable the cache on read-only file systems. In read-only mode, the driver makes use of any existing binaries in the cache, but does not attempt to add new entries.
By default, the cache is placed in an .nv directory in the user's home directory, which is created if it does not already exist. If desired, override the default location by specifying a valid alternate path with the __GL_SHADER_DISK_CACHE_PATH environment variable. Unlike the .nv directory, the driver does not create this non-default directory if it does not already exist. If this variable specifies a directory that does not already exist, the cache is disabled.
The cache appears in the specified location as a subdirectory named GLCache containing a set of directories and files with hashed names. These files encode the driver version, GPU, and application. Whenever you install a new version of the driver, the hashed names change. Users may therefore wish to clean out the old directory before running any applications.
To use a read-only cache
1. Run the application on a test/development system that has a file system with write access.
2. Copy the cache directory to the desired location in the target image.
3. Set the environment variables described above to enable the cache and indicate its location.
Comparison and Combination
The main advantage offered by the shader cache is that it is handled automatically, without any application intervention. In addition, the driver sometimes needs to generate shaders internally for certain clear and copy operations. If the cache is enabled, these too will only be generated once, rather than every time the application is run.
Although the cache eliminates the need to recompile shaders, there is search and maintenance overhead. Applications can avoid this overhead by saving and loading programs directly. Furthermore, the cache files become invalid every time a new driver is installed. Saved binaries, on the other hand, only need to be replaced when the compiler portion of the driver is updated.
The shader cache and the functions to read and load binaries are not mutually exclusive. An application can make use of both. For instance, the most critical shader programs which must be available as soon as possible after startup could be manually saved, while less frequently used shaders rely on the cache.