US20140043333A1

US20140043333A1 - Application load times by caching shader binaries in a persistent storage

Info

Publication number: US20140043333A1
Application number: US13/731,785
Authority: US
Inventors: Swaminathan Narayanan; Nicholas Haemel; Jeffrey A. Bolz
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2012-01-11
Filing date: 2012-12-31
Publication date: 2014-02-13
Also published as: US9773344B2; US20130179711A1

Abstract

A method for compiling a shader for execution by a graphics processor. The method comprises selecting a shader for execution. A key is computed for the selected shader. A memory is searched for a copy of the computed key. A shader binary stored in the memory is passed to the graphics processor for execution if the copy of the computed key is located in the memory. Otherwise, the shader is compiled to produce the shader binary for execution by the graphics processor and storing the shader binary in the memory. The shader binary is associated with the computed key and the copy of the computed key.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of Provisional Application No. 61/585,620, filed on Jan. 11, 2012, titled “GRAPHICS PROCESSOR CLOCK SCALING, APPLICATION LOAD TIME IMPROVEMENTS, AND DYNAMICALLY ADJUSTING RESOLUTION OF RENDER BUFFER TO IMPROVE AND STABILIZE FRAME TIMES OF A GRAPHICS PROCESSOR,” by Swaminathan Narayanan, et al., which is herein incorporated by reference.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to the field of graphics processing and more specifically to the field of improved shader binary caching and execution for efficient graphics processing.

BACKGROUND

High level graphics languages (e.g., OpenGL and DirectX) allow applications to specify the execution of particular shaders. Shaders are instruction sets that define how certain pieces of geometry or fragments are processed by a graphics processor. These shader instruction sets can be quite long and detailed in what they do, and often execute millions of times. In order to enable execution of these shaders on graphics processors, a compiler is employed. An exemplary compiler takes an instruction set written with a programming language (e.g., C programming language and other similar programming languages) and compiles the instruction set into a shader binary code or microcode that can be executed on the graphics processor.
One or more of these shader instruction sets may be compiled together to form an entire execution pipeline or program object. An exemplary process by which an application selects shaders and compiles the selected shader sources into binaries and links them together into a program object may require an unbounded amount of time. An exemplary compiler may require an extensive amount of optimization time while compiling and linking intermediate results and/or a final output.
Shader compilation times on mobile hardware can take a significant portion of frame render time. For example, on an application, such as a video game, running at 60 Hz, the frame render time is roughly 16 ms. When the application compiles a handful of shaders, which take on average 3-5 ms to compile on current mobile hardware, the shader compilation time can easily exceed the frame time and unfortunately cause visible stuttering on the screen.
An application attempting to compile shaders during runtime risks frame hitches or a gap of time when rendering stops or slows as shaders are compiled and programs linked together. Such visible stuttering or frame rate hitches are undesirable. Applications may attempt to get around this by compiling in-between runtimes, such that the results of the compile or link are not required for immediate execution. Despite such timing efforts, there are states or contexts that may change in 3D graphics, requiring one or more shaders to be recompiled during runtime. So even if an application attempts to compile and link all required shaders ahead of time (such as in-between levels of a video game) it is still possible for the application to require shader recompiling during runtime.
It would also be difficult for an application vendor to supply a shader binary library that contains all of the possible binaries that would need to be stored so as to avoid compiling. Such an exemplary effort may result in a binary library containing hundreds of thousands of possible shader binaries to supply shader binaries for every possible configuration and shader combination possible. Even so, should unexpected changes occur, the stored binaries would then be out of date. Shader binaries will need to be recreated whenever the graphics hardware, application, or graphics drivers change so that the recompiled shader binaries are updated. In other words, a large binary library will not provide the required flexibility to update the executable shader binaries to reflect any changes to hardware and software.

SUMMARY OF THE INVENTION

Embodiments of this present invention provide solutions to the challenges inherent in efficiently compiling shaders during runtime. According to one embodiment of the present invention, a method for compiling a shader for execution by a graphics processor is disclosed. The method comprises selecting a shader for execution. A key is computed for the selected shader. A memory is searched for a copy of the computed key. A shader binary stored in the memory is passed to the graphics processor for execution if the copy of the computed key is located in the memory. Otherwise, the shader is compiled to produce the shader binary for execution by the graphics processor and storing the shader binary in the memory. The shader binary is associated with the computed key and the copy of the computed key.
In a computer system according to one embodiment of the present invention, the computer system comprises a processor, a graphics processor, and a memory. The memory is operable to store instructions, that when executed performs a method for compiling a shader for execution by a graphics processor. The method comprises selecting a shader for execution. A key is computed for the selected shader. A memory is searched for a copy of the computed key. A shader binary stored in the memory is passed to the graphics processor for execution if the copy of the computed key is located in the memory. Otherwise, the shader is compiled to produce the shader binary for execution by the graphics processor and storing the shader binary in the memory. The shader binary is associated with the computed key and the copy of the computed key.
In a computer system according to one embodiment of the present invention, the computer system comprises a compiler, a memory, a graphics driver module, and a graphics processor. The compiler is operable to compile and link shader source code to create a shader binary. The memory is operable to store a plurality of shader binaries. Each shader binary is paired with an associated key. The graphics driver module is operable to select one or more shaders for execution by the graphics processor and to compute a key for a selected shader, and is further operable to search the memory for a copy of the computed key. A shader binary is passed from the memory for execution by the graphics processor if the copy of the computed key is located in the memory. Otherwise, the compiler is operable to compile and link the shader to create a shader binary for execution by the graphics processor and storing the shader binary in the memory. The shader binary is associated with the computed key and the copy of the computed key.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be better understood from the following detailed description, taken in conjunction with the accompanying drawing figures in which like reference characters designate like elements and in which:

FIG. 1 illustrates an exemplary schematic block diagram of a graphics rendering system with a persistent cache for persistent storage of shader binaries in accordance with an embodiment of the present invention;

FIG. 2 illustrates an exemplary schematic block diagram of a graphics rendering system with a persistent cache for persistent storage of shader binaries and corresponding keys in accordance with an embodiment of the present invention;

FIG. 3A illustrates an exemplary schematic block diagram of a graphics rendering system with a persistent cache for persistent storage of ARB assemblies and shader microcode in accordance with an embodiment of the present invention;

FIG. 3B illustrates an exemplary functional block diagram of a graphics rendering system with a persistent cache for persistent storage of ARB assemblies and shader microcode in accordance with an embodiment of the present invention; and

FIG. 4 illustrates an exemplary flow diagram illustrating steps of a computer implemented method for compiling a shader for execution by a graphics processor in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments of the present invention. The drawings showing embodiments of the invention are semi-diagrammatic and not to scale and, particularly, some of the dimensions are for the clarity of presentation and are shown exaggerated in the drawing Figures. Similarly, although the views in the drawings for the ease of description generally show similar orientations, this depiction in the Figures is arbitrary for the most part. Generally, the invention can be operated in any orientation.

Notation and Nomenclature:

Some portions of the detailed descriptions, which follow, are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer executed step, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “processing” or “accessing” or “executing” or “storing” or “rendering” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories and other computer readable media into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. When a component appears in several embodiments, the use of the same reference numeral signifies that the component is the same component as illustrated in the original embodiment.
This present invention provides a solution to the increasing challenges inherent in compiling and linking shader source code to produce shader binaries at runtime. Various embodiments of the present disclosure provide an exemplary persistent cache memory that stores shader binaries and associated keys. As discussed in detail below, when a graphics driver selects a shader instruction set for execution by a graphics processor, a cache is searched for a key associated with a shader binary for the selected shader instruction set. If the key is found in the memory, then the corresponding shader binary is sent to the graphics processor for execution, otherwise, the shader instruction set is sent to a compiler for compiling and linking to create a shader binary for execution by the graphics processor and storage in the memory.

Improving Application Load Times by Caching Shader Binaries in a Persistent Store:

FIG. 1 illustrates an exemplary graphics rendering system comprising a shader instruction set 102 (hereafter referred to as a shader), a graphics driver module 104, a compiler 106, a cache 108, and a graphics processor 110. As discussed herein, an exemplary shader 102 may comprise shader source code written with a high-level programming language, such as C programming language or other similar languages. In another embodiment, a plurality of shaders 102 (e.g., a program object) may be compiled, linked and stored in the cache 108. In one exemplary embodiment, the cache 108 is a persistent memory that retains stored shader binaries and associated keys between runtime sessions so that previously compiled and linked shaders are immediately available (in the cache) the next time they need to be executed. In one embodiment, an exemplary cache 108 for a mobile computing system may be approximately 2-8 Mbytes in size, while an exemplary cache 108 for a desktop computing system may be approximately 64 Mbytes. Other cache sizes are also possible and are within the scope of this disclosure.
As discussed herein, some mobile applications, such as a WebGL compatible browser, may compile a significant number of shaders during a single runtime of the application. In one embodiment, each shader binary for a mobile computing system may be 1-2 Kbytes in size. This may cause the persistent cache 108 to fill up. One solution is to track the usage of shader binaries and to delete any old entries based on a least recently used (LRU) cache storage algorithm. Another solution may be to use a coarse ring buffer scheme using a pair of persistent files. For example, when one of the persistent files is filled up, the other persistent file may be truncated and new entries appended to that persistent file.
In one embodiment, shader binaries stored in a persistent cache may be compressed (e.g., RLE compression) beforehand. In one embodiment, the shader binary is compressed immediately before placement into the cache and decompressed immediately after removal from the cache.
As illustrated in FIG. 1, a selected shader (or a plurality of shaders) 102 is received by the graphics driver 104. After receiving the shader 102, the graphics driver 104 searches the cache 108 for a shader binary that is a compiled and linked version of the selected shader 102, ready to be executed by the graphics processor. As illustrated in FIG. 1, if there is not a matching shader binary in the cache 108, the graphic driver 104 forwards the shader 102 to the compiler 106 for compiling and linking to produce the desired shader binary. This shader binary is forwarded to the graphics driver 104, where it is then forwarded to both the graphics processor 110 for execution and to the cache 108 for persistent storage. In one exemplary embodiment, the cache 108 may be searched for a desired shader binary by searching the cache 108 for a key that is associated with the desired shader binary. As discussed in detail below, a shader binary paired with an associated key is stored in the cache 108. As also discussed herein, when a shader is selected for execution, a key is computed that is associated with the desired shader binary and is used to search for a matching key stored in the cache 108. In other words, the computed key is used to search the cache 108 for a matching key paired with the desired shader binary.
FIG. 2 illustrates an exemplary functional block diagram of a graphics rendering system operable to produce a shader binary for execution by a graphics processor and the computation of a key associated with the shader binary. As illustrated in FIG. 2, an exemplary graphics driver 202 provides shader arguments to a complier 204 and a compute key block 206. The compiler 204 receives the shader arguments and shader text that are used by the compiler 204 to compile and link the shader to produce a shader binary. As also illustrated in FIG. 2, the compute key function block 206 receives the shader arguments and shader text along with a graphics driver version, graphics processor type/version, and a compiler driver version to produce a key that is associated with the produced shader binary. In other words, a shader binary is based upon the corresponding shader arguments and shader text that are also dependent upon the current graphics driver version, compiler version, and graphics processor type/version.
In one embodiment, a cache stores shader binaries and associates each shader binary with a key. In one embodiment a key size and hash function may be used to produce a key that may be chosen such that a probability of collisions is kept extremely low. In one embodiment, a 64 bit key may suffice as a number of possible shaders that a typical application may compile for execution number at the most in the tens of thousands. In one embodiment, an exemplary key is computed using a hash function on a source shader string and the shader arguments that are also passed to the shader compiler. These arguments are computed internally by the graphics driver using the graphics driver's current state. The same shader instruction set may be compiled using different compiler arguments, resulting in multiple key/value pairs being added to the cache as graphic driver states change.
In one embodiment, as discussed herein, the cache 210 may also contain a global key that is computed at runtime based on a current graphics driver version, current compiler version, and other hardware related states. The global key may be computed at graphics driver startup and compared to a global key previously stored in the cache 210. If there is a mismatch between the previously stored global key and the new global key, the cache 210 is out of date and all stored shader binaries are invalidated. When stored shader binaries are invalidated, a shader selected for execution will need to be compiled, even if a copy of the shader binary is stored in the cache 210 (in other words, the stored shader binary is invalid). Such global keys may be used to ensure that only the latest updated shader binaries are used by the application.
As illustrated in FIG. 2, the shader binary and associated key are forwarded together to the cache 210 for storage. In one embodiment, the cache 210 is a persistent memory that retains its saved contents from previous runtime sessions. As illustrated in FIG. 1, the shader binary may be forwarded to a graphics processor 110 for execution. To ensure that the shader binary has not been corrupted, a compute checksum function block 208 computes a checksum that is also stored in the cache 210 along with the shader binary and key.
In one embodiment, a checksum may be used to ensure that a shader binary stored in a persistent cache 210 is uncorrupted. As noted herein, comparing a computed key to a key stored in the cache 210 may be used to ensure that the previously stored shader binary associated with the stored key is still valid (that there have not been software or hardware changes) while a checksum is used to ensure that a stored shader binary has not been corrupted due to copy errors, etc. In other words, a key is used to ensure that a desired shader binary selected is the correct one and is up to date, while the checksum is used to ensure that there are no errors in the cached shader binary.
FIG. 3A illustrates an exemplary graphics rendering system 300. The graphics rendering system 300 illustrated in FIG. 3 comprises a shader 302, a graphics driver 304, a compiler 306, a cache 308, and a graphics processor 310. In one embodiment, a shader 302 is selected by a graphics driver 304 for execution by the graphics processor 310. As noted herein, before the shader is executed, the shader must be compiled and linked by the compiler to produce a shader binary. In one embodiment, rather than compiling and linking the shader to produce the required shader binary, the desired shader binary may be retrieved from the cache 308 and passed to the graphics processor 310 for execution. As discussed herein, when the compiler 306 compiles and links a shader to produce a shader binary, the paired shader binary and corresponding key are stored in the cache 308 for later retrieval.
In one embodiment, GLSL shaders used in applications are compiled to produce an intermediate compilation using ARB assembly code, which is compiled itself to produce an executable using shader microcode or binary. In one embodiment, the ARB assembly and the shader microcode or binary are stored in the cache 308. In one exemplary environment, an OpenGL graphics rendering API supports user-supplied ARB assembly programs and fixed-function shading, and these are all cached in the cache 308 for later retrieval.
In one embodiment, the desired shader binary (e.g., an ARB assembly and shader binary used to produce the desired executable) retrieved during a current runtime session was stored in the cache 308 during a previous runtime session. As illustrated in FIGS. 3A and 3B, a shader is passed to the compiler 306 and an ARB assembly is returned to the graphics driver 304, after which, the graphics driver 304 passes an ARB ASM to the compiler 306 to produce a shader microcode which is executed by the graphics processor 310. In one embodiment, the ARB assembly and shader binaries are compressed to minimize a required footprint in the cache 308 and to possibly further reduce load times. In one embodiment, RLE compression is used. As discussed herein, a checksum may also be used to evaluate cached shader binaries to prevent execution problems should the stored shader binary be corrupted (e.g., due to abnormal process termination or due to improper file locking).
FIG. 3B illustrates an exemplary functional block diagram of the graphics rendering system 300 illustrated in FIG. 3A. In FIG. 3B, a shader 302 is selected by a graphics driver 304 for execution by a graphics processor 310. As illustrated in FIG. 3B, the shader 302 is selected by the graphics driver 304 during a first phase 304-A. During the first phase 304-A, the shader 302 is passed to a frontend compiler 306-A for compiling. The frontend compiler 306-A returns an ARB assembly to the graphics driver 304 during the first phase 304-A. The ARB assembly is passed from the first phase 304-A to the second phase 304-B and forwarded to the backend compiler 306-B for further compiling. As illustrated in FIG. 3B, the backend compiler 306-B returns a shader microcode for execution by the graphics processor 310. In one embodiment, the backend compiler 306-B may produce a shader microcode or binary.
In one embodiment, as illustrated in FIGS. 3A and 3B, the first and second graphics driver phases 304-A, 304-B are performed by the graphics driver 304. In one embodiment, the frontend compiler functionality (306-A) and the backend compiler functionality (306-B) are implemented with a single compiler 306. As further illustrated in FIG. 3B, when the ARB assembly and the shader microcode are produced, the ARB assembly and shader microcode and associated keys may be stored in the cache 308 for persistent storage. In other words, separate unique keys for the ARB assembly code portion and for the shader microcode are created and stored.
FIG. 4 illustrates an exemplary flow diagram illustrating a process for compiling a shader 102 for execution by a graphics processor 110 in accordance with an embodiment of the present invention. In step 402 of FIG. 4, a shader 102 is selected for execution by a graphics processor 110. In one embodiment, a single shader is selected for execution. In another embodiment a plurality of shaders are selected for execution together as a program object.
In step 404 of FIG. 4, a key is computed for the selected shader. In one embodiment, as discussed herein, a key is computed based upon shader arguments, shader text, current graphics driver version, and a current compiler driver version. The computed key is therefore associated with the desired shader binary. In step 406 of FIG. 4, the computed key is compared with keys stored in a cache 108. As discussed herein, during step 406, the computed key is compared to the stored keys to determine if a key associated with the desired shader binary is stored in the cache 108. If the desired shader binary is in the cache 108, the associated key will match the computed key.
In step 408 of FIG. 4, a determination is made as to whether or not the desired key is found in the cache 108. In other words, is there a match between the computed key (that is based upon the desired shader binary) and a key previously stored in the cache 108? If a key in the cache 108 matches the computed key, the process continues to step 410 of FIG. 4. However, if the desired key is not found in the cache 108, the process continues to step 416 of FIG. 4.
In step 410 of FIG. 4, a shader binary associated with the stored key that matches the computed key is retrieved from the cache 108 and a checksum is performed on the retrieved shader binary. In step 412 of FIG. 4, a determination is made as to whether the checksum passes. If the checksum passes, the process continues to step 414 of FIG. 4. If the checksum does not pass, the process continues to step 416 of FIG. 4. In step 414 of FIG. 4, the shader binary is passed to the graphics processor 110 for execution.
In step 416 of FIG. 4, the selected shader or plurality of shaders is compiled and linked to produce a shader binary. In step 418 of FIG. 4, the shader binary is passed to the graphics processor 110 for execution. Lastly, in step 420 of FIG. 4, the shader binary and associated key and checksum are stored in the cache 108. As discussed herein, after the shader binary and the associated key and checksum are stored in the cache 108, the shader binary will be available for execution by the graphics processor 110 during future runtime sessions without having to compile and link the shader again.
Although certain preferred embodiments and methods have been disclosed herein, it will be apparent from the foregoing disclosure to those skilled in the art that variations and modifications of such embodiments and methods may be made without departing from the spirit and scope of the invention. It is intended that the invention shall be limited only to the extent required by the appended claims and the rules and principles of applicable law.

Claims

What is claimed is:

1. A method for compiling a shader for execution by a graphics processor, the method comprising:

selecting a shader for execution;

computing a computed key for the selected shader;

searching a memory for a copy of the computed key; and

passing a shader binary stored in the memory to the graphics processor for execution if the copy of the computed key is located in the memory, otherwise compiling the shader to produce a shader binary for execution by the graphics processor and storing the shader binary in the memory, wherein the shader binary is associated with the computed key and the copy of the computed key.

2. The method of claim 1, wherein compiling the shader to produce a shader binary comprises computing an associated key to be stored with the shader binary in the memory.

3. The method of claim 1 further comprising:

verifying a checksum associated with the shader binary before execution by the graphics processor; and

recompiling the shader to produce a replacement shader binary for execution by the graphics processor and storing the shader binary in the memory if the verification fails.

4. The method of claim 1 further comprising:

generating a first global key;

comparing the first global key to a second global key previously stored in the memory; and

invalidating all binaries stored in the memory if the first global key mismatches the second global key.

5. The method of claim 2, wherein a key is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.

6. The method of claim 1, wherein a shader binary is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.

7. The method of claim 1, wherein the storing the shader binary in the memory comprises storing an associated key and an associated checksum with the shader binary in the memory.

8. A computer system comprising:

a processor;

a graphics processor;

and a memory, wherein the memory is operable to store instructions, that when executed by the processor perform a method for compiling a shader for execution by a graphics processor, the method comprising:

selecting a shader for execution;

computing a computed key for the selected shader;

searching a memory for a copy of the computed key; and

9. The computer system of claim 8, wherein compiling the shader to produce a shader binary comprises computing an associated key to be stored with the shader binary in the memory.

10. The computer system of claim 8, wherein the method further comprises:

11. The computer system of claim 8, wherein the method further comprises:

generating a first global key;

12. The computer system of claim 9, wherein a key is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.

13. The computer system of claim 8, wherein a shader binary is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.

14. The computer system of claim 8, wherein the storing the shader binary in the memory comprises storing an associated key and an associated checksum with the shader binary in the memory.

15. A computer system comprising:

a compiler operable to compile and link shader source code to create a shader binary;

a memory operable to store a plurality of shader binaries, wherein each shader binary is paired with an associated key; and

a graphics driver module operable to select one or more shaders for execution by a graphics processor and to compute a computed key for a selected shader, and is further operable to search the memory for a copy of the computed key and pass a shader binary from the memory for execution by the graphics processor if the copy of the computed key is located in the memory, otherwise the compiler is operable to compile and link the shader to create a shader binary for execution by the graphics processor and storing the shader binary in the memory, wherein the shader binary is associated with the computed key and the copy of the computed key.

16. The computer system of claim 15, wherein the computed key associated with the shader binary is also stored in the memory.

17. The computer system of claim 15, wherein the graphics driver is further operable to:

verify a checksum associated with the shader binary before execution by the graphics processor; and

recompile the shader source code to produce a replacement shader binary for execution by the graphics processor and storage in the memory if the verification fails.

18. The computer system of claim 15, wherein the graphics driver is further operable to compute a first global key, compare the first global key to a second global key previously stored in the memory, and invalidate all shader binaries stored in the memory if the first global key mismatches the second global key.

19. The computer system of claim 16, wherein a key is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.

20. The computer system of claim 15, wherein a shader binary is based on at least one of:

shader arguments;

shader text;

graphics driver version;

graphics processor type/version; and

compiler version.