| 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 |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL and OpenGL ES Working Groups. 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 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 |
