1Name 2 3 KHR_no_error 4 5Name Strings 6 7 GL_KHR_no_error 8 9Contributors 10 11 Maurice Ribble 12 Dominik Witczak 13 Christophe Riccio 14 Piers Daniell 15 Jon Leech 16 James Jones 17 Daniel Kartch 18 Steve Hill 19 Jan-Harald Fredriksen 20 21Contact 22 23 Maurice Ribble (mribble 'at' qti.qualcomm.com) 24 25Notice 26 27 Copyright (c) 2012-2014 The Khronos Group Inc. Copyright terms at 28 http://www.khronos.org/registry/speccopyright.html 29 30Specification Update Policy 31 32 Khronos-approved extension specifications are updated in response to 33 issues and bugs prioritized by the Khronos OpenGL and OpenGL ES Working Groups. For 34 extensions which have been promoted to a core Specification, fixes will 35 first appear in the latest version of that core Specification, and will 36 eventually be backported to the extension document. This policy is 37 described in more detail at 38 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 39 40Status 41 42 Complete. 43 Approved by the Khronos Board of Promoters on May 8, 2015. 44 45Version 46 47 Version 6, February 25, 2015 48 49Number 50 51 ARB Extension #175 52 OpenGL ES Extension #243 53 54Dependencies 55 56 Requires OpenGL ES 2.0 or OpenGL 2.0. 57 58 Written against the OpenGL ES 3.1 specification. 59 60 Interacts with EGL_KHR_create_context_no_error (or equivalent) extension. 61 62 CONTEXT_FLAG_NO_ERROR_BIT_KHR is only supported if the OpenGL version has 63 support for context flags (as defined in the OpenGL 4.5 core spec) or an 64 extension supporting equivalent functionality is exposed. 65 66Overview 67 68 With this extension enabled any behavior that generates a GL error will 69 have undefined behavior. The reason this extension exists is performance 70 can be increased and power usage decreased. When this mode is used, a GL 71 driver can have undefined behavior where it would have generated a GL error 72 without this extension. This could include application termination. In 73 general this extension should be used after you have verified all the GL 74 errors are removed, and an application is not the kind that would check 75 for GL errors and adjust behavior based on those errors. 76 77New Procedures and Functions 78 79 None 80 81New Tokens 82 83 CONTEXT_FLAG_NO_ERROR_BIT_KHR 0x00000008 84 85Additions to the OpenGL ES Specification 86 87 Add the following to the end of section 2.3.1 "Errors": 88 89 If this context was created with the no error mode enabled then any place 90 where the driver would have generated an error instead has undefined 91 behavior. This could include application termination. All calls to 92 GetError will return NO_ERROR or OUT_OF_MEMORY. OUT_OF_MEMORY 93 errors are a special case because they already allow for undefined behavior 94 and are more difficult for application developers to predict than other 95 errors. This extension allows OUT_OF_MEMORY errors to be delayed, which 96 can be useful for optimizing multithreaded drivers, but eventually the 97 OUT_OF_MEMORY error should be reported if an implementation would have 98 reported this error. Since behavior of OUT_OF_MEMORY errors are undefined 99 there is some implementation flexibility here. However, this behavior may 100 provide useful information on some implementations that do report 101 OUT_OF_MEMORY without crashing. 102 103 Add the following in the section that describes CONTEXT_FLAGS: 104 105 If CONTEXT_FLAG_NO_ERROR_BIT_KHR is set in CONTEXT_FLAGS, then no error 106 behavior is enabled for this context. 107 108Errors 109 110 None 111 112New State 113 114 None 115 116Conformance Tests 117 118 TBD 119 120Issues 121 122 (1) How does this extension interact with KHR_robustness and debug contexts? 123 124 RESOLVED: The EGL/WGL/GLX layers should prevent these features from being 125 enabled at the same time. However, if they are somehow enabled at the same 126 time this extension should be ignored. 127 128 (2) Can we provide a guarantee bad usage of this API won't affect other apps 129 that are running? This implies (but perhaps is not limited to) the risk of 130 resource leaks (eg. If I use incorrect coordinates when executing load ops on 131 images, am I guaranteed such ops will return the spec-guaranteed values or 132 can I accidentally read someone else's memory?) and crashing other apps if I 133 do horrendous stuff with the API. 134 135 RESOLVED: GL already allows passing in invalid pointers in some calls that 136 read or write to memory outside this apps process space. Many drivers/OS 137 models today offer protection from one process accessing memory from another 138 process. If you have that sort of protection before this extension then using 139 this extension does not remove such protections. 140 141 To put it another way this should not turn off kernel level or hardware level 142 protections. 143 144 (3) Should glGetError() always return NO_ERROR or have undefined results? 145 146 RESOLVED: It should for all errors except OUT_OF_MEMORY. For OUT_OF_MEMORY 147 errors the error may be delayed to allow more optimization in multithreaded 148 drivers, but if a driver would typically not crash and return OUT_OF_MEMORY 149 then it should eventually return OUT_OF_MEMORY in this mode. Since 150 OUT_OF_MEMORY errors have undefined behavior this can't really be enforced. 151 The reason OUT_OF_MEMORY errors aren't just converted to NO_ERROR like other 152 errors is because some implementations don't crash on OUT_OF_MEMORY errors 153 and apps can't easily predict when OUT_OF_MEMORY errors will happen so on 154 these implementations apps might want to check for OUT_OF_MEMORY errors at 155 certain points to see if things have gone very badly and then decide to do 156 something else if they see an OUT_OF_MEMORY error. 157 158 (4) Should we add something similar for CheckFramebufferStatus()? 159 160 RESOLVED: NO. It is unclear what the gain of this would be, and this is 161 vendor specific behavior. The same is true for ValidateProgram and 162 ValidateProgramPipeline. Also these features aren't as frequent as other GL 163 calls so the gains from optimizing these would be much smaller. 164 165 (5) Should there be a CONTEXT_FLAG for this behavior? 166 167 RESOLVED: If CONTEXT_FLAGS are supported in the version of OpenGL being used 168 or with an extension then yes. 169 170Revision History 171 172 Rev. Date Author Changes 173 ---- ------------ --------- ---------------------------------------- 174 1 Jan 28, 2015 ribble Initial version 175 2 Jan 29, 2015 ribble Added issues list 176 3 Jan 30, 2015 ribble Split into separate GL and EGL extensions 177 4 Feb 18, 2015 ribble Add special OOM error case and cleanup 178 5 Feb 23, 2015 ribble Add CONTEXT_FLAG issue 179 6 Feb 25, 2015 ribble Spec cleanup 180