Name

    KHR_robustness

Name Strings

    GL_KHR_robustness

Contributors

    Daniel Koch, NVIDIA
    Nicolas Capens, TransGaming
    Contributors to ARB_robustness

Contact

    Jon Leech (oddhack 'at' sonic.net) 
    Greg Roth, NVIDIA (groth 'at' nvidia.com)

Notice

    Copyright (c) 2012-2014 The Khronos Group Inc. Copyright terms at
        http://www.khronos.org/registry/speccopyright.html

Status

    Complete. 
    Approved by the OpenGL ES Working Group on June 25, 2014.
    Approved by the ARB on June 26, 2014.
    Ratified by the Khronos Board of Promoters on August 7, 2014.

Version

    Version 11, August 21, 2014

Number

    ARB Extension #170
    OpenGL ES Extension #190

Dependencies

    OpenGL ES 2.0 or OpenGL 3.2 are required. Some features of this
    extension are supported by OpenGL ES only if OpenGL ES 3.0 or later is
    supported.

    EGL_EXT_create_context_robustness is used to determine if a context
    implementing this extension supports robust buffer access, and if it
    supports reset notification.

    This extension is written against the OpenGL ES 3.1 Specification
    (version of June 4, 2014) and the OpenGL ES 3.10.3 Shading Language
    Specification (version of June 6, 2014).

Overview

    Several recent trends in how OpenGL ES integrates into modern computer
    systems have created new requirements for robustness and security for GL
    rendering contexts.
    
    Additionally GPU architectures now support hardware fault detection;
    for example, video memory supporting ECC (error correcting codes)
    and error detection.  GL 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.

    GL queries that return (write) some number of bytes to a
    buffer indicated by a pointer parameter introduce risk of buffer
    overflows that might be exploitable by malware. To address this,
    queries with return value sizes that are not expressed directly by
    the parameters to the query itself are given additional API
    functions with an additional parameter that specifies the number of
    bytes in the buffer and never writing bytes beyond that limit. This
    is particularly useful for multi-threaded usage of GL contexts
    in a "share group" where one context can change objects in ways that
    can cause buffer overflows for another context's GL 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 graphics
    hardware is capable of well-defined behavior in the case of out-of-
    bounds vertex buffer object fetches. Older hardware 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 GL 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 a GL application to learn about
        graphics resets that affect the context.  When a graphics reset
        occurs, the GL context becomes unusable and the application
        must create a new context to continue operation. Detecting a
        graphics reset happens through an inexpensive query.

    *   Define behavior of OpenGL calls made after a graphics reset.

    *   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.

New Procedures and Functions

    NOTE: when implemented in an OpenGL ES context, all entry points defined
    by this extension must have a "KHR" suffix. When implemented in an
    OpenGL context, all entry points must have NO suffix, as shown below.

    enum GetGraphicsResetStatus();

    void ReadnPixels(int x, int y, sizei width, sizei height,
                        enum format, enum type, sizei bufSize,
                        void *data);

    void GetnUniformfv(uint program, int location, sizei bufSize,
                          float *params);
    void GetnUniformiv(uint program, int location, sizei bufSize,
                          int *params);
    void GetnUniformuiv(uint program, int location, sizei bufSize,
                           uint *params);


New Tokens

    NOTE: when implemented in an OpenGL ES context, all tokens defined by
    this extension must have a "_KHR" suffix. When implemented in an OpenGL
    context, all tokens must have NO suffix, as described below.

    Returned by GetGraphicsResetStatus:

        NO_ERROR                                        0x0000
        GUILTY_CONTEXT_RESET                            0x8253
        INNOCENT_CONTEXT_RESET                          0x8254
        UNKNOWN_CONTEXT_RESET                           0x8255

    Accepted by the <value> parameter of GetBooleanv, GetIntegerv,
    and GetFloatv:

        CONTEXT_ROBUST_ACCESS                           0x90F3
        RESET_NOTIFICATION_STRATEGY                     0x8256

    Returned by GetIntegerv and related simple queries when <value> is
    RESET_NOTIFICATION_STRATEGY :

        LOSE_CONTEXT_ON_RESET                           0x8252
        NO_RESET_NOTIFICATION                           0x8261

    Returned by GetError:

        CONTEXT_LOST                                    0x0507


Additions to the OpenGL ES 3.1 Specification

    Add to section 2.3.1 "Errors" in the bullet list of implicit errors for
    GL commands on p. 14, and modify the following paragraph:

     * If the GL context has been reset as a result of a previous GL
       command, or if the context is reset as a side effect of execution of
       a command, a CONTEXT_LOST error is generated.

    The Specification attempts to explicitly describe these implicit error
    conditions (with the exception of OUT_OF_MEMORY [fn2] and CONTEXT_LOST
    [fn3]) wherever they apply. However ...

    [fn3] CONTEXT_LOST is not described because it occurs for reasons not
    directly related to the affected commands, and applies to almost all GL
    commands.


    Add to table 2.3 "Summary of GL errors" on p. 15:
    
    Error          Description               Offending command ignored?
    ------------   -----------------------   --------------------------
    CONTEXT_LOST   Context has been lost     Except as noted for
                   and reset by the driver   specific commands
    
    
    Add a new subsection 2.3.1rob after 2.3.1 "GL Errors", and renumber
    subsequent sections accordingly:

    2.3.1rob "Graphics Reset Recovery"

    Certain events can result in a reset of the GL context. After such an
    event, it is referred to as a <lost context> and is unusable for almost
    all purposes. Recovery requires creating a new context and recreating
    all relevant state from the lost context. The current status of the
    graphics reset state is returned by

        enum GetGraphicsResetStatus();

    The value returned indicates if the GL context has been in a reset state
    at any point since the last call to GetGraphicsResetStatus:

      * NO_ERROR indicates that the GL context has not been in a reset state
        since the last call.
      * GUILTY_CONTEXT_RESET indicates that a reset has been detected
        that is attributable to the current GL context.
      * INNOCENT_CONTEXT_RESET indicates a reset has been detected that
        is not attributable to the current GL context.
      * UNKNOWN_CONTEXT_RESET 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.

    If the reset notification behavior is NO_RESET_NOTIFICATION, then
    the implementation will never deliver notification of reset events, and
    GetGraphicsResetStatus 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, a graphics reset will
    result in a lost context and require creating a new context as described
    above. In this case GetGraphicsResetStatus will return an appropriate
    value from those 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 GetGraphicsResetStatus in the
        different contexts may differ.]

    After a graphics reset has occurred on a context, subsequent GL commands
    on that context (or any context which shares with that context) will
    generate a CONTEXT_LOST error. Such commands will not have side effects
    (in particular, they will not modify memory passed by pointer for query
    results), and may not block indefinitely or cause termination of the
    application. Exceptions to this behavior include:

      * GetError and GetGraphicsResetStatus behave normally following a
        graphics reset, so that the application can determine a reset has
        occurred, and when it is safe to destroy and recreate the context.
      * Any commands which might cause a polling application to block
        indefinitely will generate a CONTEXT_LOST error, but will also
        return a value indicating completion to the application. Such
        commands include:

        + GetSynciv with <pname> SYNC_STATUS ignores the other parameters
          and returns SIGNALED in <values>.
        + GetQueryObjectuiv with <pname> QUERY_RESULT_AVAILABLE ignores the
          other parameters and returns TRUE in <params>.


    Modify section 7.12 "Shader, Program, and Program Pipeline Queries"
    on p. 125 to add the GetnUniform* commands:

    The commands

            [enumerate existing GetUniform*v commands, then add]

        void GetnUniformfv(uint program, int location, sizei bufSize,
                              float *params);
        void GetnUniformiv(uint program, int location, sizei bufSize,
                              int *params);
        void GetnUniformuiv(uint program, int location, sizei bufSize,
                               uint *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>. The type of the uniform at <location> determines the number of
    values returned. Calling GetnUniform*v ensures that no more than
    <bufSize> bytes are written into <params>.

    Add to the Errors section for Get*Uniform* on p. 126:

    An INVALID_OPERATION error is generated by GetnUniform* if the buffer
    size required to store the requested data is greater than <bufSize>


    Add subsection 10.3.1.1rob prior to section 10.3.2 "Vertex Attribute
    Divisors" on p. 241:

    10.3.1.1rob Robust Buffer Access Behavior

    Robust buffer access is enabled by creating a context with robust access
    enabled through the window system binding APIs. When enabled, indices
    within the element array that reference vertex data that lies outside
    the enabled attribute's vertex buffer object 
        [for OpenGL ES] result in undefined values
        [for OpenGL] result in reading zero
    for the corresponding attributes, but cannot result in application
    failure. 

    Robust buffer access behavior may be queried by calling
    GetIntegerv with the symbolic constant CONTEXT_ROBUST_ACCESS.


    Modify section 16.1.2 "ReadPixels" on p. 332 to add the ReadnPixels
    command:

    Pixels are read using

        void ReadPixels(int x, int y, sizei width, sizei height,
                        enum format, enum type, void *data);
        void ReadnPixels(int x, int y, sizei width, sizei height,
                            enum format, enum type, sizei bufSize,
                            void *data);

    The arguments after <x> and <y> to ReadPixels ... are summarized in
    table 16.1. ReadnPixels behaves identically to ReadPixels except that
    it does not write more than <bufSize> bytes into <data>.


    Add to the Errors section for ReadPixels and ReadnPixels:

    An INVALID_OPERATION error is generated by ReadnPixels if the buffer
    size required to store the requested data is greater than <bufSize>.


Additions to The OpenGL ES Shading Language Specification, Version 3.10

    Modify the first paragraph of section 4.1.9 "Arrays" on p. 30:

    Variables of the same type ... Undefined behavior results from indexing
    an array with a non-constant expression that is greater than or equal to
    the array size or less than 0. If robust buffer access is enabled (see
    section 10.3.1.1rob of the OpenGL ES 3.1 API Specification), 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. Arrays only have a single dimension ...

Dependencies on OpenGL ES

    For implementations against OpenGL ES, if OpenGL ES 3.0 or a later
    version is not supported, remove all references to GetnUniformuiv and
    remove the exceptional behavior of GetSynciv and GetQueryObjectuiv for
    lost contexts.

Interactions with EGL_EXT_create_context_robustness

    If the EGL window-system binding API is used to create a context, the
    EGL_EXT_create_context_robustness extension is supported, and the
    attribute EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT is set to EGL_TRUE when
    eglCreateContext is called, the resulting context will perform robust
    buffer access as described above in section 10.3.1.1rob, and the
    CONTEXT_ROBUST_ACCESS query will return GL_TRUE.

    If the EGL window-system binding API is used to create a context and the
    EGL_EXT_create_context_robustness extension is supported, then the value
    of attribute EGL_CONTEXT_RESET_NOTIFICATION_STRATEGY_EXT determines the
    reset notification behavior and the value of
    RESET_NOTIFICATION_STRATEGY, as described in section 2.3.1rob.

New Implementation Dependent State

    Get Value                   Type  Get Command Minimum Value     Description                 Sec.        Attribute
    --------------------------- ----  ----------- ----------------- --------------------------- ----------- ---------
    CONTEXT_ROBUST_ACCESS       B     GetIntegerv -                 Robust access enabled       10.3.1.1rob -
    RESET_NOTIFICATION_STRATEGY Z_2   GetIntegerv See sec. 2.3.1rob Reset notification behavior 2.3.1rob    -

Issues

    (Issues 2-8 are identical to those in the base EXT_robustness
    extension).

    1. What should this extension be called?

       RESOLVED: KHR_robustness

       This is just the OpenGL ES EXT_robustness extension (itself based on
       ARB_robustness) promoted to KHR status, with consistency with OpenGL
       4.5 behavior and phrasing included.

    2. How does this extension differ from Desktop GL's ARB_robustness?

       RESOLVED: Because EGL_EXT_create_context_robustness uses a separate
       attribute to enable robust buffer access, a corresponding query is
       added here.

       Also see issue 12.

    3. Should we provide a context creation mechanism to enable this
       extension?

       RESOLVED. Yes.

       Currently, EGL_EXT_create_context_robustness provides this mechanism
       via two unique attributes. These attributes differ from those
       specified by KHR_create_context to allow for differences in what
       functionality those attributes define.
        
    4. 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. On some systems,
       power management events such as system sleep, screen saver
       activation, or pre-emption may also context resets to occur. Any of
       these events may result in a graphics reset event that will be
       detectable by the mechanism described in this extension.

    5. 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 again 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 (using either GetError to
       identify a CONTEXT_LOST error, or GetGraphicsResetStatus()), 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.

    6. 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.

    7. 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 value of
       CONTEXT_ROBUST_ACCESS using GetIntegerv. If true, this
       functionality is enabled.

    8. How is the reset notification behavior controlled?

       RESOLVED: Reset notification behavior is determined at context
       creation time using EGL/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.

    9. How does this extension differ from EXT_robustness?

       RESOLVED: By adding the new CONTEXT_LOST error, removing support for
       ES 1.1 (for logistical reasons), and changing suffixes from EXT to
       KHR (for ES) or no suffix (for GL).

   10. How should this extension be enabled via EGL?

       PROPOSED: Either by using EGL 1.5 context creation APIs (see section
       3.7.1.5 of the EGL 1.5 spec), or EGL_EXT_create_context_robustness.
       This interaction will be noted in both the EGL 1.5 spec and the
       extension spec by allowing at least one, and possibly both of
       GL_EXT_robustness and GL_KHR_robustness to be supported by contexts
       created via these mechanisms. If a context supporting
       GL_KHR_robustness is created, it will optionally support
       GL_KHR_robust_buffer_access_behavior as well (see issue 5 of that
       extension).

   11. What should the behavior of GL calls made after a context is lost be?
       This can be expected to occur when the context has been lost, but the
       app hasn't polled the reset status yet.

       RESOLVED: Set a new CONTEXT_LOST error on all GL calls (except
       GetError and GetGraphicsReset).

       DISCUSSION: GetError and GetGraphicsResetStatus must continue to
       work at least to the extent of their interactions with robustness
       features, so that apps can determine a context was lost and see the
       effect on other commands. Commands which might block indefinitely or
       cause the app to block indefinitely while polling are defined to
       return immediately, with values which should end a polling loop. Such
       commands include sync and query object queries for completion.

       Special handling of these commands is defined to return values which
       should not cause blocking, but also to generate the CONTEXT_LOST
       error. This is intended to deal well both with apps that are polling
       on a query value, and apps that may test for the error immediately
       after each command (such as debuggers). There has been no pushback
       against

       We believe there are no other commands requiring this special
       handling in the core API. ClientWaitSync and WaitSync were also
       proposed, but with the current language (which specifies that
       commands on a lost context may not block) should not need exceptional
       handling.

       REJECTED OPTIONS:

       A) GL will try to handle the call as best as possible. Depending on
       the call this may use GPU resources which may now have undefined
       contents.

       B) GL calls become no-ops. This would be like having a null-dispatch
       table installed when you don't have a current context. The problem
       with this approach is that any call that has return parameters won't
       fill them in and the application won't be able to detect that a value
       was not returned.

       REJECTED SUB-FEATURES:

       We discussed using OUT_OF_MEMORY or INVALID_OPERATION. Both are
       misleading and don't uniquely identify the problem as a runtime error
       out of scope of anything the app did.

       We discussed allowing all commands to have side effects in addition
       to generating CONTEXT_LOST, such as putting a "safe" value into
       return parameters. Without compelling reason to allow this behavior,
       it is cleaner to define the spec to leave results unchanged aside
       from the exceptional cases intended to prevent hanging on polling
       loops.

   12. What changed in promoting OES_robustness to KHR_robustness? What
       remains to be done for consistency between GL and ES?

       DISCUSSION: The ARB agreed to support robustness and
       robust_buffer_access_behavior as a KHR extension, with the following
       chnages and issues to be resolved during the ratification period
       (none are IP-related):

       a) As was done for KHR_debug, the extension is defined to have KHR
          suffixes only in ES implementations. GL implementations do not
          have suffixes. This is so KHR_robustness can be used as a
          backwards-compatibility extension for OpenGL 4.5.

       b) Minor spec language tweaks were done for consistency with OpenGL
          4.5, to eliminate redundancy. None are functional with the
          exception of a change in section 10.3.1.1rob, which imposes
          stronger requirements on out-of-bounds indexed attribute access
          for GL (returns zero) relative to ES (undefined return values).

       c) The ARB wants to add these commands to the extension, as defined
          in OpenGL 4.5. They would be only be supported in GL contexts:

            GetnUniformdv
            GetnTexImage
            GetnCompressedTexImage

          We do not think we need to add the compatibility-mode Getn*
          queries defined by ARB_robustness.

       d) OpenGL 4.5 exposes support for robustness by setting
          CONTEXT_FLAG_ROBUST_ACCESS_BIT in the CONTEXT_FLAGS query. ES (and
          this extension) expose it with the CONTEXT_ROBUST_ACCESS query.
          Jon proposes we resolve this by only defining the CONTEXT_FLAGS
          query for GL, but defining the CONTEXT_ROBUST_ACCESS query for
          both GL and ES, and aliasing the flag bit with the access boolean.
          This will result in minor changes to both GL 4.5 and this
          extension.

       e) This extension modifies the Shading Language specification in
          section 4.1.9 to restrict behavior of out of bounds array
          accesses. GLSL 4.50 has a considerably broader section 5.11
          "Out-of-Bounds Accesses" which restricts behavior of arrays,
          vectors, structs, etc. We will want to include that language in
          KHR_robustness at least as GLSL-specific language; if ES wants to
          adopt the broader language for GLSL-ES that might still be doable.

Revision History

    Rev.    Date       Author     Changes
    ----  ------------ ---------  ------------------------------------------
     11   2014/08/21   Jon Leech  Fix typo.
     10   2014/06/26   Jon Leech  Change from OES to KHR. Update issues 1
                                  and 9; add issue 12 on ES / GL
                                  differences.
      9   2014/06/26   Jon Leech  Minor phrasing fixes to be more consistent
                                  with equivalent GL functionality.
      8   2014/06/24   Jon Leech  Fix typos & mention GetError in issue 5.
                                  Reorder API spec edits in section order.
                                  Resolve issues 9-11 (Bug 12104 comments
                                  #42-45). Assign CONTEXT_LOST enum.
      7   2014/06/02   Jon Leech  Remove "safe" return value behavior for
                                  queries when contexts are lost (Bug 12104
                                  comment #27).
      6   2014/06/02   Jon Leech  Rebase extension on OpenGL ES 3.1 specs
                                  and reflow paragraphs (no functionality
                                  changes are made in this version).
      5   2014/05/16   Jon Leech  Add CONTEXT_LOST error and exceptional
                                  behavior for potentially-blocking
                                  commands (Bug 8411).
      4   2014/05/14   Jon Leech  Add issue 11 on behavior of GL calls made
                                  after a context is lost.
      3   2014/05/07   Jon Leech  Add GetnUniformuivOES for ES 3.0.
      2   2014/04/26   Jon Leech  Updates based on Ken's comments in bug
                                  12104 and to reference EGL 1.5.
      1   2014/04/23   Jon Leech  Branch from EXT_robustness version 3 and
                                  promote to OES suffixes. Add issues 9-10.