Name

    KHR_no_error

Name Strings

    GL_KHR_no_error

Contributors

    Maurice Ribble
    Dominik Witczak
    Christophe Riccio
    Piers Daniell
    Jon Leech
    James Jones
    Daniel Kartch
    Steve Hill
    Jan-Harald Fredriksen

Contact

    Maurice Ribble (mribble 'at' qti.qualcomm.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 Khronos Board of Promoters on May 8, 2015.

Version

    Version 6, February 25, 2015

Number

    ARB Extension #175
    OpenGL ES Extension #243

Dependencies

    Requires OpenGL ES 2.0 or OpenGL 2.0.

    Written against the OpenGL ES 3.1 specification.

    Interacts with EGL_KHR_create_context_no_error (or equivalent) extension.

    CONTEXT_FLAG_NO_ERROR_BIT_KHR is only supported if the OpenGL version has
    support for context flags (as defined in the OpenGL 4.5 core spec) or an
    extension supporting equivalent functionality is exposed.

Overview

    With this extension enabled any behavior that generates a GL error will
    have undefined behavior.  The reason this extension exists is performance
    can be increased and power usage decreased.  When this mode is used, a GL
    driver can have undefined behavior where it would have generated a GL error
    without this extension.  This could include application termination.  In
    general this extension should be used after you have verified all the GL
    errors are removed, and an application is not the kind that would check
    for GL errors and adjust behavior based on those errors.

New Procedures and Functions

    None

New Tokens

    CONTEXT_FLAG_NO_ERROR_BIT_KHR    0x00000008

Additions to the OpenGL ES Specification

    Add the following to the end of section 2.3.1 "Errors":

    If this context was created with the no error mode enabled then any place
    where the driver would have generated an error instead has undefined
    behavior.  This could include application termination.  All calls to
    GetError will return NO_ERROR or OUT_OF_MEMORY.  OUT_OF_MEMORY
    errors are a special case because they already allow for undefined behavior
    and are more difficult for application developers to predict than other
    errors.  This extension allows OUT_OF_MEMORY errors to be delayed, which
    can be useful for optimizing multithreaded drivers, but eventually the
    OUT_OF_MEMORY error should be reported if an implementation would have
    reported this error.  Since behavior of OUT_OF_MEMORY errors are undefined
    there is some implementation flexibility here.  However, this behavior may
    provide useful information on some implementations that do report
    OUT_OF_MEMORY without crashing.

    Add the following in the section that describes CONTEXT_FLAGS:

    If CONTEXT_FLAG_NO_ERROR_BIT_KHR is set in CONTEXT_FLAGS, then no error
    behavior is enabled for this context.

Errors

    None

New State

    None

Conformance Tests

    TBD

Issues

  (1) How does this extension interact with KHR_robustness and debug contexts?

  RESOLVED: The EGL/WGL/GLX layers should prevent these features from being
  enabled at the same time.  However, if they are somehow enabled at the same
  time this extension should be ignored.

  (2) Can we provide a guarantee bad usage of this API won't affect other apps
  that are running? This implies (but perhaps is not limited to) the risk of
  resource leaks (eg. If I use incorrect coordinates when executing load ops on
  images, am I guaranteed such ops will return the spec-guaranteed values or
  can I accidentally read someone else's memory?) and crashing other apps if I
  do horrendous stuff with the API.

  RESOLVED: GL already allows passing in invalid pointers in some calls that
  read or write to memory outside this apps process space.  Many drivers/OS
  models today offer protection from one process accessing memory from another
  process.  If you have that sort of protection before this extension then using
  this extension does not remove such protections.

  To put it another way this should not turn off kernel level or hardware level
  protections.

  (3) Should glGetError() always return NO_ERROR or have undefined results?

  RESOLVED: It should for all errors except OUT_OF_MEMORY.  For OUT_OF_MEMORY
  errors the error may be delayed to allow more optimization in multithreaded
  drivers, but if a driver would typically not crash and return OUT_OF_MEMORY
  then it should eventually return OUT_OF_MEMORY in this mode.  Since
  OUT_OF_MEMORY errors have undefined behavior this can't really be enforced.
  The reason OUT_OF_MEMORY errors aren't just converted to NO_ERROR like other
  errors is because some implementations don't crash on OUT_OF_MEMORY errors
  and apps can't easily predict when OUT_OF_MEMORY errors will happen so on
  these implementations apps might want to check for OUT_OF_MEMORY errors at
  certain points to see if things have gone very badly and then decide to do
  something else if they see an OUT_OF_MEMORY error.

  (4) Should we add something similar for CheckFramebufferStatus()?

  RESOLVED: NO.  It is unclear what the gain of this would be, and this is
  vendor specific behavior.  The same is true for ValidateProgram and
  ValidateProgramPipeline.  Also these features aren't as frequent as other GL
  calls so the gains from optimizing these would be much smaller.

  (5) Should there be a CONTEXT_FLAG for this behavior?

  RESOLVED: If CONTEXT_FLAGS are supported in the version of OpenGL being used
  or with an extension then yes.

Revision History

    Rev.    Date       Author     Changes
    ----  ------------ ---------  ----------------------------------------
      1   Jan 28, 2015 ribble     Initial version
      2   Jan 29, 2015 ribble     Added issues list
      3   Jan 30, 2015 ribble     Split into separate GL and EGL extensions
      4   Feb 18, 2015 ribble     Add special OOM error case and cleanup
      5   Feb 23, 2015 ribble     Add CONTEXT_FLAG issue
      6   Feb 25, 2015 ribble     Spec cleanup