Name ARB_robustness Name Strings GL_ARB_robustness Contributors Acorn Pooley, NVIDIA Anton Staaf, Google Barthold Lichtenbelt, NVIDIA Bruce Merry, ARM Chris Marrin, Apple Greg Roth, NVIDIA Jeff Bolz, NVIDIA Jon Leech Kenneth Russell, Google Kent Miller, Apple Piers Daniell, NVIDIA Vladimir Vukicevic, Mozilla Contact Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) Notice Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Specification Update Policy Khronos-approved extension specifications are updated in response to issues and bugs prioritized by the Khronos OpenGL Working Group. For extensions which have been promoted to a core Specification, fixes will first appear in the latest version of that core Specification, and will eventually be backported to the extension document. This policy is described in more detail at https://www.khronos.org/registry/OpenGL/docs/update_policy.php Status Complete. Approved by the ARB on June 9, 2010. Approved by the Khronos Board of Promoters on July 23, 2010. Version Last Modified Date: June 25, 2014 Version: 18 Number ARB Extension #105 Dependencies This extension is written against the OpenGL 3.2 Compatibility Profile Specification but can apply to OpenGL 1.1 and up. This specification interacts with the ARB_imaging subset of the OpenGL 3.2 Compatibility Profile. This specification interacts with the OpenGL 3.2 Core Profile. This specification interacts with EXT_direct_state_access. GLX_ARB_create_context_robustness and WGL_ARB_create_context_robustness are used to determine if a context implementing this extension supports robust buffer access, and if it supports reset notification. Equivalent platform-dependent mechanisms in other window-system integration layers such as EGL and AGL may exist for those platforms. Overview Several recent trends in how OpenGL integrates into modern computer systems have created new requirements for robustness and security for OpenGL rendering contexts. Additionally GPU architectures now support hardware fault detection; for example, video memory supporting ECC (error correcting codes) and error detection. OpenGL contexts should be capable of recovering from hardware faults such as uncorrectable memory errors. Along with recovery from such hardware faults, the recovery mechanism can also allow recovery from video memory access exceptions and system software failures. System software failures can be due to device changes or driver failures. Demands for increased software robustness and concerns about malware exploiting buffer overflows have lead API designers to provide additional "safe" APIs that bound the amount of data returned by an API query. For example, the safer "snprintf" or "_snprintf" routines are prefered over "sprintf". The OpenGL API has many such robustness perils. OpenGL queries return (write) some number of bytes to a buffer indicated by a pointer parameter. The exact number of bytes written by existing OpenGL queries is not expressed directly by any specific parameter; instead the number of bytes returned is a complex function of one or more query arguments, sometimes context state such as pixel store modes or the active texture selector, and the current state of an object (such as a texture level's number of total texels). By the standards of modern API design, such queries are not "safe". Making these queries safer involves introducing a new query API with an additional parameter that specifies the number of bytes in the buffer and never writing bytes beyond that limit. Multi-threaded use of OpenGL contexts in a "share group" allow sharing of objects such as textures and programs. Such sharing in conjunction with concurrent OpenGL commands stream execution by two or more contexts introduces hazards whereby one context can change objects in ways that can cause buffer overflows for another context's OpenGL queries. The original ARB_vertex_buffer_object extension includes an issue that explicitly states program termination is allowed when out-of-bounds vertex buffer object fetches occur. Modern GPUs capable of DirectX 10 enforce the well-defined behavior of always returning zero values for indices or non-fixed components in this case. Older GPUs may require extra checks to enforce well-defined (and termination free) behavior, but this expense is warranted when processing potentially untrusted content. The intent of this extension is to address some specific robustness goals: * For all existing OpenGL queries, provide additional "safe" APIs that limit data written to user pointers to a buffer size in bytes that is an explicit additional parameter of the query. * Provide a mechanism for an OpenGL application to learn about graphics resets that affect the context. When a graphics reset occurs, the OpenGL context becomes unusable and the application must create a new context to continue operation. Detecting a graphics reset happens through an inexpensive query. * Provide an enable to guarantee that out-of-bounds buffer object accesses by the GPU will have deterministic behavior and preclude application instability or termination due to an incorrect buffer access. Such accesses include vertex buffer fetches of attributes and indices, and indexed reads of uniforms or parameters from buffers. In one anticipated usage model, WebGL contexts may make use of these robust features to grant greater stability when using untrusted code. WebGL contexts cannot call OpenGL commands directly but rather must route all OpenGL API calls through the web browser. It is then the web browser that configures the context, using the commands in this extension, to enforce safe behavior. In this scenario, the WebGL content cannot specify or change the use of this extension's features itself; the web browser enforces this policy. There are other well-known robustness issues with the OpenGL API which this extension does not address. For example, selector-based OpenGL commands are a well-known source of programming errors. Code to manipulate texture state may assume the active texture selector is set appropriately when an intervening function call obscures a change to the active texture state resulting in incorrectly updated or queried state. The EXT_direct_state_access extension introduces selector-free OpenGL commands and queries to address that particular issue so this extension does not. The intent of this extension is NOT to deprecate any existing API and thereby introduce compatibility issues and coding burdens on existing code, but rather to provide new APIs to ensure a level of robustness commensurate with the expectations of modern applications of OpenGL. IP Status No known IP claims. New Procedures and Functions GRAPHICS RESET DETECTION AND RECOVERY enum GetGraphicsResetStatusARB(); SIZED BUFFER QUERIES OpenGL 1.0 sized buffer queries void GetnMapdvARB(enum target, enum query, sizei bufSize, double *v); void GetnMapfvARB(enum target, enum query, sizei bufSize, float *v); void GetnMapivARB(enum target, enum query, sizei bufSize, int *v); void GetnPixelMapfvARB(enum map, sizei bufSize, float *values); void GetnPixelMapuivARB(enum map, sizei bufSize, uint *values); void GetnPixelMapusvARB(enum map, sizei bufSize, ushort *values); void GetnPolygonStippleARB(sizei bufSize, ubyte *pattern); void GetnTexImageARB(enum target, int level, enum format, enum type, sizei bufSize, void *img); void ReadnPixelsARB(int x, int y, sizei width, sizei height, enum format, enum type, sizei bufSize, void *data); ARB_imaging sized buffer queries void GetnColorTableARB(enum target, enum format, enum type, sizei bufSize, void *table); void GetnConvolutionFilterARB(enum target, enum format, enum type, sizei bufSize, void *image); void GetnSeparableFilterARB(enum target, enum format, enum type, sizei rowBufSize, void *row, sizei columnBufSize, void *column, void *span); void GetnHistogramARB(enum target, boolean reset, enum format, enum type, sizei bufSize, void *values); void GetnMinmaxARB(enum target, boolean reset, enum format, enum type, sizei bufSize, void *values); OpenGL 1.3 sized buffer queries void GetnCompressedTexImageARB(enum target, int lod, sizei bufSize, void *img); OpenGL 2.0 sized buffer queries void GetnUniformfvARB(uint program, int location, sizei bufSize, float *params); void GetnUniformivARB(uint program, int location, sizei bufSize, int *params); void GetnUniformuivARB(uint program, int location, sizei bufSize, uint *params); void GetnUniformdvARB(uint program, int location, sizei bufSize, double *params); New Tokens Returned by GetGraphicsResetStatusARB: NO_ERROR 0x0000 GUILTY_CONTEXT_RESET_ARB 0x8253 INNOCENT_CONTEXT_RESET_ARB 0x8254 UNKNOWN_CONTEXT_RESET_ARB 0x8255 Accepted by the parameter of GetBooleanv, GetIntegerv, GetInteger64v, GetFloatv, and GetDoublev: RESET_NOTIFICATION_STRATEGY_ARB 0x8256 Returned by GetIntegerv and related simple queries when is RESET_NOTIFICATION_STRATEGY_ARB: LOSE_CONTEXT_ON_RESET_ARB 0x8252 NO_RESET_NOTIFICATION_ARB 0x8261 Returned by GetIntegerv when is CONTEXT_FLAGS: CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB 0x00000004 Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification (OpenGL Operation) Add a new subsection after 2.5 "GL Errors" and renumber subsequent sections accordingly 2.6 "Graphics Reset Recovery" Certain events can result in a reset of the GL context. Such a reset causes all context state to be lost. Recovery from such events requires recreation of all objects in the affected context. The current status of the graphics reset state is returned by enum GetGraphicsResetStatusARB(); The symbolic constant returned indicates if the GL context has been in a reset state at any point since the last call to GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context has not been in a reset state since the last call. GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected that is attributable to the current GL context. INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that is not attributable to the current GL context. UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose cause is unknown. If a reset status other than NO_ERROR is returned and subsequent calls return NO_ERROR, the context reset was encountered and completed. If a reset status is repeatedly returned, the context may be in the process of resetting. Reset notification behavior is determined at context creation time, and may be queried by calling GetIntegerv with the symbolic constant RESET_NOTIFICATION_STRATEGY_ARB. If the reset notification behavior is NO_RESET_NOTIFICATION_ARB, then the implementation will never deliver notification of reset events, and GetGraphicsResetStatusARB will always return NO_ERROR[fn1]. [fn1: In this case it is recommended that implementations should not allow loss of context state no matter what events occur. However, this is only a recommendation, and cannot be relied upon by applications.] If the behavior is LOSE_CONTEXT_ON_RESET_ARB, a graphics reset will result in the loss of all context state, requiring the recreation of all associated objects. In this case GetGraphicsResetStatusARB. may return any of the values described above. If a graphics reset notification occurs in a context, a notification must also occur in all other contexts which share objects with that context[fn2]. [fn2: The values returned by GetGraphicsResetStatusARB in the different contexts may differ.] Add to Section 2.8 "Vertex Arrays" before 2.8.1 "Drawing Commands" Robust buffer access is enabled by creating a context with robust access enabled through the window system binding APIs. When enabled, indices within the vertex array that lie outside the arrays defined for enabled attributes result in undefined values for the corresponding attributes, but cannot result in application failure. Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization) None Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification (Per-Fragment Operations and the Frame Buffer) Modify section 4.3.2 "Reading Pixels" Pixels are read using void ReadPixels(int x, int y, sizei width, sizei height, enum format, enum type, void *data); void ReadnPixelsARB(int x, int y, sizei width, sizei height, enum format, enum type, sizei bufSize, void *data); The arguments after and to ReadPixels are described in section 3.7.4. The pixel storage modes that apply to ReadPixels and other commands that query images (see section 6.1) are summarized in table 4.7. ReadnPixelsARB behaves identically to ReadPixels except that it does not write more than bytes into . Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification (Special Functions) None Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification (State and State Requests) Modify Section 6.1.3 "Enumerated Queries" void GetPixelMap{ui us f}v(enum map, T data); void GetnPixelMap{ui us f}vARB(enum map, sizei bufSize, T data); return all values in the pixel map in . must be a map name from table 3.3. GetPixelMapuiv, GetnPixelMapuivARB, GetPixelMapusv, and GetnPixelMapusvARB convert floating point pixel map values to integers according to the UNSIGNED_INT and UNSIGNED_SHORT entries, respectively, of table 4.9. GetnPixelMap{ui us f}vARB does not write more than bytes into . If a pixel pack buffer ... ... an INVALID_OPERATIONS_ERROR results. When calling GetnPixelMap{ui us f}vARB, if a pixel pack buffer object is bound and is greater than , but + does not exceed the size of the buffer, no error results. ... void GetMap{ifd}v(enum map, enum value, T data); void GetnMap{ifd}vARB(enum map, enum value, sizei bufSize, T data); places information about for in . must be one of the map types described in section 5.1, and must be one of ORDER, COEFF, or DOMAIN. GetnMap{ifd}vARB does not write more than bytes into . Section 6.1.4 "Texture Queries" Modify the description of GetTexImage: "The commands void GetTexImage(enum tex, int lod, enum format, enum type, void *img ); void GetnTexImageARB(enum tex, int lod, enum format, enum type, sizei bufSize, void *img ); are used to obtain texture images. ... ... is a pixel type from table 3.5. GetnTexImageARB does not write more than bytes into ." Add to the end of the sixth paragraph: "When calling GetnTextureImageARB, if a pixel pack buffer object is bound and packing a texture image into buffer memory would exceed but not the size of the buffer, no error results." Modify the description of GetCompressedTexImage: "The commands void GetCompressedTexImage(enum target, int lod, void *img); void GetnCompressedTexImageARB(enum target, int lod, sizei bufSize, void *img ); are used to obtain texture images stored in compressed form. The parameters , , and are interpreted in the same manner as in GetTexImage and GetnTexImageARB respectively. When called, GetCompressedTexImage and GetnCompressedTexImageARB write MIN(n,bufSize) ubytes of compressed image data ... ... If a pixel pack buffer object is bound and img + n is greater than the size of the buffer, an INVALID_OPERATION error results. When calling GetnCompressedTextureImageARB, if a pixel pack buffer object is bound and is greater than but + does not exceed the size of the buffer, no error results." Modify Section 6.1.5 "Stipple Query" The commands void GetPolygonStipple(void *pattern); void GetnPolygonStippleARB(sizei bufSize, void *pattern); obtain the polygon stipple. The pattern is packed into pixel pack buffer or client memory according to the procedure given in section 4.3.2 for ReadPixels; it is as if the and passed to that command were both equal to 32, the type were BITMAP, and the format were COLOR_INDEX. GetnPolygonStippleARB does not write more than bytes into . Modify Section 6.1.7 "Color Table Query" The current contents of a color table are queried using void GetColorTable(enum target, enum format, enum type, void *table ); void GetnColorTableARB(enum target, enum format, enum type, sizei bufSize, void *table); must be one of the regular color table names listed in table 3.4. ... ... to the components requested by format are described in table 6.1. GetnColorTableARB does not write more than bytes into . Modify Section 6.1.8 "Convolution Query" The current contents of a convolution filter image are queried with the command void GetConvolutionFilter(enum target, enum format, enum type, void *image ); void GetnConvolutionFilterARB(enum target, enum format, enum type, sizei bufSize, void *image); must be CONVOLUTION_1D or CONVOLUTION_2D. ... ... Pixel processing and component mapping are identical to those of GetTexImage. GetnConvolutionFilterARB does not write more than bytes into . ... The current contents of a separable filter image are queried using void GetSeparableFilter(enum target, enum format, enum type, void *row, void *column, void *span ); void GetnSeparableFilterARB(enum target, enum format, enum type, sizei rowBufSize, void *row, sizei columnBufSize, void *column, void *span); ... The row and column images are returned to pixel pack buffer or client memory starting at row and column respectively. GetnSeparableFilterARB does not write more than bytes into and no more than bytes into . is currently unused. ... Modify Section 6.1.9 "Histogram Query" The current contents of the histogram table are queried using void GetHistogram(enum target, boolean reset, enum format, enum type, void* values ); void GetnHistogramARB(enum target, boolean reset, enum format, enum type, sizei bufSize, void* values); ... component values are simply clamped to the range of the target data type. GetnHistogramARB does not write more than bytes into . Modify Section 6.1.10 "Minmax Query" The current contents of the minmax table are queried using void GetMinmax(enum target, boolean reset, enum format, enum type, void* values ); void GetnMinmaxARB(enum target, boolean reset, enum format, enum type, sizei bufSize, void* values); ... A one-dimensional image of width 2 is returned to pixel pack buffer or client memory starting at . GetnMinmaxARB does not write more than bytes into . Modify Section 6.1.11 "Pointer and String Queries" Add to the paragraph describing the context profile mask and flags (preceding the description of GetStringi) on page 379: "If CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB is set in CONTEXT_FLAGS, then robust buffer access will be enabled for drawing commands using vertex arrays, as described in section 2.8." Modify Section 6.1.16 "Shader and Program Queries" The commands void GetUniformfv(uint program, int location, float *params); void GetnUniformfvARB(uint program, int location, sizei bufSize, float *params); void GetUniformiv(uint program, int location, int *params); void GetnUniformivARB(uint program, int location, sizei bufSize, int *params); void GetUniformuiv(uint program, int location, uint *params); void GetnUniformuivARB(uint program, int location, sizei bufSize, uint *params); void GetUniformdv(uint program, int location, double *params); void GetnUniformdvARB(uint program, int location, sizei bufSize, double *params); return the value or values of the uniform at location location of the default uniform block for program object program in the array params. GetnUniformfvARB, GetnUniformivARB, GetnUniformuivARB and GetnUniformdvARB do not write any data to if is less than the size of the requested data. ... Additions to the AGL/GLX/WGL Specifications None Additions to The OpenGL Shading Language Specification, Version 1.50.11 Change the first paragraph of section 4.1.9 "Arrays" ... Undefined behavior results from indexing an array with a non-constant expression that's greater than or equal to the array's size or less than 0. If robust buffer access is enabled via the OpenGL API, such indexing must not result in abnormal program termination. The results are still undefined, but implementations are encouraged to produce zero values for such accesses. Only one-dimensional arrays may be declared. ... GLX Protocol XXX Interactions with GLX_ARB_create_context_robustness If the GLX window-system binding API is used to create a context, the GLX_ARB_create_context_robustness extension is supported, and the bit GLX_CONTEXT_ROBUST_ACCESS_BIT_ARB is set in GLX_CONTEXT_FLAGS when glXCreateContextAttribsARB is called, the resulting context will perform robust buffer access as described above in section 2.8, and the CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB bit will be set in CONTEXT_FLAGS as described above in section 6.1.11. If the GLX window-system binding API is used to create a context and the GLX_ARB_create_context_robustness extension is supported, then the value of attribute GLX_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB determines the reset notification behavior and the value of RESET_NOTIFICATION_STRATEGY_ARB, as described in section 2.6. Interactions with WGL_ARB_create_context_robustness If the WGL window-system binding API is used to create a context, the WGL_ARB_create_context_robustness extension is supported, and the bit WGL_CONTEXT_ROBUST_ACCESS_BIT_ARB is set in WGL_CONTEXT_FLAGS when wglCreateContextAttribsARB is called, the resulting context will perform robust buffer access as described above in section 2.8, and the CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB bit will be set in CONTEXT_FLAGS as described above in section 6.1.11. If the WGL window-system binding API is used to create a context and the WGL_ARB_create_context_robustness extension is supported, then the value of attribute WGL_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB determines the reset notification behavior and the value of RESET_NOTIFICATION_STRATEGY_ARB, as described in section 2.6. Errors GetnMapdvARB, GetnMapfvARB, GetnMapivARB, GetnPixelMapfvARB, GetnPixelMapuivARB, GetnPixelMapusvARB, GetnPolygonStippleARB, GetnTexImageARB, ReadnPixelsARB, GetnColorTableARB, GetnConvolutionFilterARB, GetnSeparableFilterARB, GetnHistogramARB, GetnMinmaxARB, GetnCompressedTexImageARB, GetnUniformfvARB, GetnUniformivARB, GetnUniformuivARB and GetnUniformdvARB share all the errors of their unsized buffer query counterparts with the addition that INVALID_OPERATION is generated if the buffer size required to fill all the requested data is greater than . New State Get Value Type Get Command Value Description Sec Attribute -------------------------- ---- ----------- ------------ --------------------------- ------ --------- RESET_NOTIFICATION_STRATEGY_ARB Z_2 GetIntegerv See sec. 2.6 Reset notification behavior 2.6 - New Implementation Dependent State None Dependencies on the ARB_imaging subset If the ARB_imaging subset of the OpenGL 3.2 Compatibility Profile is not supported, the commands GetnColorTableARB, GetnConvolutionFilterARB, GetnHistogramARB, GetnMap*ARB, GetnMinmaxARB, GetnPixelMap*ARB, and GetnSeparableFilterARB defined by this extension are not supported, and all references to them should be ignored. Dependencies on OpenGL 3.2 (Core Profile) If only the core profile of OpenGL 3.2 is supported, the commands GetnColorTableARB, GetnConvolutionFilterARB, GetnHistogramARB, GetnMap*ARB, GetnMinmaxARB, GetnPixelMap*ARB, GetnPolygonStippleARB, and GetnSeparableFilterARB defined by this extension are not supported, and all references to them should be ignored. Issues 1. Does robust buffer access affect vertex pulling from vertex buffer objects, client vertex arrays, or both? RESOLVED: Only vertex buffer objects. DirectX 10-era GPUs are guaranteed to provide guarantees consistent with those required by robust buffer access. Client memory vertex arrays should not be expected to be used directly in situations requiring robust operation. Historically the original EXT_vertex_array extension provided a "GLsizei count" parameter to indicate how long vertex arrays should be. This proved to be unworkable in practice because applications typically found it too difficult to properly compute the count; instead a very large integer was passed, obviating any practical use for the parameter. When vertex arrays were added to core OpenGL in version 1.1, the "GLsizei count" parameter was eliminated for this reason. There are other problems too. Clever applications using client memory vertex arrays can specify the base pointer to be NULL (address 0) and then use indices that essentially correspond to pointers divided by the stride. There's also no guarantee a pointer itself has a contiguous range of memory allocate within a given range. Moreover client memory vertex arrays are no longer a performance path so they simply are not particularly interesting to address. The result is there's really no practical way to bound client vertex array access in a way that's likely to be practically useful. Vertex buffer objects do not have this same problem because buffer objects have a bounded index-able range. Robust applications should simply use vertex buffer objects for robust vertex pulling (ignoring client memory vertex arrays for an rendering that must be done robustly). 2. If robust buffer access is supported and a vertex index is large enough to fetch beyond the size of an enabled vertex buffer object, what happens? RESOLVED: Undefined values are read for the varying (non-fixed) components. A fixed-component would be a component such as the W component when only a 2- or 3-component position is fetched. In this case, the W component is fixed as 1.0 and that will be the case still if the index would have resulted in an out-of-bounds fetch. Undefined results are required for implementations that can't guarantee any particular value. It make testing this behavior difficult, but it's required for certain implementations. 3. If robust buffer access is supported and an element array buffer is accessed beyond the size of the element array buffer so there's not a valide index, what happens? RESOLVED: The value of the index is undefined. Undefined results are required for implementations that can't guarantee any particular value. It make testing this behavior difficult, but it's required for certain implementations. 4. What query commands actually need a new "GLsizei bufSize" parameter? RESOLVED: If the number of bytes returned by the query is not *completely* determined by the parameters to the function (in the absence of errors) and not already bounded by an existing GLsizei buffer size parameter, a new query is needed. This means commands such as glGetClipPlane, glGetIntegerv, etc. do NOT need new versions. This means queries that depend on pixel store pack state need new queries. Examples: glReadPixels, glGetPolygonStipple, glGetTexImage, glGetConvolutionFilter, etc. This means queries that query an object's state which can vary in size need new queries. Examples: glGetTexImage, glGetCompressedTexImage, glGetUniformfv, glGetUniformuiv, etc. This means queries that query context state which can vary depending on other context state variables need new queries. Examples: glGetHistogram, glGetPixelMapfv, glGetColorTable, etc. If the command already has a parameter that limits the amount of data returned through a pointer, no new command is needed. Examples: glGetActiveAttrib, glGetActiveUniform, glGetInfoLog, glGetAttachedShaders, glGetAttachedObjects, glGetShaderSource, glGetActiveAttrib, glGetBufferSubData, glGen*, etc. 5. If a new query with an explicit buffer size is called and the buffer size is not sufficient to return the data, what happens? RESOLVED: Return an INVALID_OPERATION error and ignore the query. Some consideration was given to clearing the entire buffer range. This might arguably avoid applications subsequently reading from uninitialized buffers. This was rejected for several reasons: 1) Doing something when there's an error is inconsistent with the rest of OpenGL's operation. 2) If the buffer is left untouched, the application can initialize the buffer to some bogus value (NaN or an invalid negative value) and notice that the buffer was left unmodified after the query without the expense of checking for OpenGL errors. 3) Many commands return information through packing pixels based on the pixel store state. The pixel store state allows skipping over some data (GL_SKIP_PIXELS, GL_SKIP_ROWS, etc.) so zero'ing memory for the entire buffer isn't a good idea. 6. Can you explain why various glGet queries do NOT have new "sized" versions? RESOLVED: Queries always returning a constant number of bytes: OpenGL 1.0 glGetClipPlane - always 4*sizeof(GLdouble) OpenGL 2.0 glGetVertexAttribdv - always 4*sizeof(GLdouble) glGetVertexAttribfv - always 4*sizeof(GLfloat) glGetVertexAttribiv - always 4*sizeof(GLint) Queries with an effective buffer size parameter already: OpenGL 1.5 glGetBufferSubData - returns size (parameter) bytes Queries with an effective buffer bound (no more bytes than) parameter already: OpenGL 2.0 glGetAttachedShaders - returns no more than sizeof(GLuint)*maxCount to count and no more than sizeof(GLuint)*maxCount to shaders glGetShaderInfoLog glGetProgramInfoLog glGetShaderSource glGetActiveAttrib glGetActiveUniform - returns no more than bufSize bytes OpenGL 3.0 glGetTransformFeedbackVarying - returns no more than bufSize bytes OpenGL 3.2 glGetUniformIndices - returns sizeof(GLuint)*uniformCount bytes glGetActiveUniformName glGetActiveUniformBlockName - returns no more than bufSize bytes Query's some function of enumeration parameters fully determine the number bytes returned: OpenGL 1.0 glGetIntegerv glGetFloatv glGetDoublev glGetBooleanv glGetLightiv glGetLightfv glGetMaterialfv glGetMaterialiv glGetTexEnvfv glGetTexEnviv glGetTexGendv glGetTexGenfv glGetTexGeniv glGetTexParameterfv glGetTexParameteriv glGetTexLevelParameterfv glGetTexLevelParameteriv - fully determined by pname parameter OpenGL 1.1 glGetPointerv - fully determined by pname parameter glGenTextures - sizeof(GLuint)*n ARB_imaging glGetColorTableParameterfv glGetColorTableParameteriv glGetConvolutionParameterfv glGetConvolutionParameteriv glGetHistogramParameterfv glGetHistogramParameteriv glGetMinmaxParameterfv glGetMinmaxParameteriv - fully determined by pname parameter OpenGL 1.5 glGenBuffers glGenQueries - sizeof(GLuint)*n glGetBufferParameteriv glGetQueryObjectiv glGetQueryObjectfv glGetQueryiv - fully determined by pname parameter OpenGL 2.0 glGetVertexAttribPointerv glGetShaderiv glGetProgramiv - fully determined by pname parameter OpenGL 3.0 glGenRenderbuffers glGenFramebuffers glGenVertexArrays - sizeof(GLuint)*n OpenGL 3.2 glGetActiveUniformBlockiv - function of pname and uniformCount glGetActiveUniformsiv - function of pname NV_vertex_program glGenProgramsNV - sizeof(GLuint)*n ARB_vertex_program glGenProgramsARB - sizeof(GLuint)*n 7. What can cause a graphics reset? Either user or implementor errors may result in a graphics reset. If the application attempts to perform a rendering that takes too long whether due to an infinite loop in a shader or even just a rendering operation that takes too long on the given hardware. Implementation errors may produce badly formed hardware commands. Memory access errors may result from user or implementor mistakes. Any of these events may result in a graphics reset event that will be detectable by the mechanism described in this extension. 8. How should the application react to a reset context event? RESOLVED: For this extension, the application is expected to query the reset status until NO_ERROR is returned. If a reset is encountered, at least one *RESET* status will be returned. Once NO_ERROR is encountered, the application can safely destroy the old context and create a new one. After a reset event, apps should not use a context for any purpose other than determining its reset status, and then destroying it. If a context receives a reset event, all other contexts in its share group will also receive reset events, and should be destroyed and recreated. Apps should be cautious in interpreting the GUILTY and INNOCENT reset statuses. These are guidelines to the immediate cause of a reset, but not guarantees of the ultimate cause. 9. If a graphics reset occurs in a shared context, what happens in shared contexts? RESOLVED: A reset in one context will result in a reset in all other contexts in its share group. This is mandated, not recommended behavior as of revision 14. 10. How can an application query for robust buffer access support, since this is now determined at context creation time? RESOLVED. The application can query the CONTEXT_FLAGS bitfield using GetIntegerv and check for the presence of CONTEXT_FLAG_- ROBUST_ACCESS_BIT_ARB. 11. How is the reset notification behavior controlled? RESOLVED: Reset notification behavior is determined at context creation time using GLX/WGL/etc. mechanisms. In order that shared objects be handled predictably, a context cannot share with another context unless both have the same reset notification behavior. Revision History Rev. Date Author Changes ---- ------------ --------- -------------------------------------------- 18 25 Jun 2014 Jon Leech Fix type of in Get*Uniformdv. 17 17 Sep 2012 Jon Leech Clarify that GetnUniform* does not write any data if bufSize is less than required (Bug 8739). 16 25 Jun 2012 Jon Leech Add interactions with ARB_imaging and core profile. 15 10 Apr 2012 Jon Leech Fix description of INVALID_OPERATION error to be when required data size is *greater* than bufSize, not *less*. 14 22 Jul 2010 Jon Leech Require resets to be delivered to all contexts which share objects. Expand on recommended recovery behavior in Issues 8 and 9. Assign enum for new token. 13 21 Jul 2010 Jon Leech Remove RequestGraphicsResetNotificationARB and determine graphics reset notification behavior at context creation time in separate GLX/WGL extensions. 12 19 Jul 2010 pdaniell Added missing GetnUniformdARB. Add additional language to the "Graphics Reset Recovery" section to clarify objects of shared contexts. Revert revision #7 changes to restore the old "bufSize" behavior and remove the new "length" parameter, both of which proved problematic with implementation. Truncating the output buffer data written to "bufSize" length is hard to implement efficiently in software and impossible with some hardware paths. Also the additional "length" parameter caused PBO based async calls to become sync, which is undesirable. 11 07 Jun 2010 groth Clarify PBO errors/sized queries interaction Make consistent the app response to a reset Resolve issue 10 per revision 10 changes. 10 07 Jun 2010 Jon Leech Add a bit to the context flags query indicating whether or not robust buffer access was enabled at context creation. 9 06 Jun 2010 Jon Leech Note interactions with context creation extensions enabling robust buffer access, and add issue 10 regarding queries for robust buffer access. Remove dangling references to old ROBUST_BUFFER_ACCESS token. 8 21 May 2010 groth bmerry comment response Restore ARB suffixes in light of rejection from core 7 20 May 2010 groth Allow bounds checking using context creation flag Fix issues. Revise bounded queries to take and return lengths. Add query for current reset strategy. 72 column resizing. 6 06 May 2010 groth ARBify, catch a few sized gets that hadn't been named correctly. 5 05 May 2010 groth Add clarification regarding recovered reset detection. 4 02 May 2010 groth Remove references to deleted functionality. Add issue addressing differences with 3 15 Apr 2010 groth Describe GLSL array behavior when using robust arrays. Add issue explaining graphics reset causes. 2 22 Mar 2010 groth Flesh out missing secions. Remove vestiges of specified limits API. Rename sized queries. Various grammar corrections and clarifications. 1 19 Jan 2010 mjk Initial version