1Names 2 3 KHR_get_all_proc_addresses 4 KHR_client_get_all_proc_addresses 5 6Name Strings 7 8 EGL_KHR_get_all_proc_addresses 9 EGL_KHR_client_get_all_proc_addresses 10 11Contributors 12 13 Jon Leech 14 Marcus Lorentzon 15 Robert Palmer 16 Acorn Pooley 17 Greg Prisament 18 Chad Versace 19 20Contacts 21 22 James Jones, NVIDIA (jajones 'at' nvidia.com) 23 24Notice 25 26 Copyright (c) 2013 The Khronos Group Inc. Copyright terms at 27 http://www.khronos.org/registry/speccopyright.html 28 29Status 30 31 Complete. Approved by the EGL Working Group on April 3, 2013. 32 Ratified by the Khronos Board of Promoters on July 19, 2013. 33 34Version 35 36 Version 3 - July 31, 2013 37 38Number 39 40 EGL Extension #61 41 42Extension Types 43 44 EGL_KHR_get_all_proc_addresses is an EGL display extension 45 EGL_KHR_client_get_all_proc_addresses is an EGL client extension 46 47Dependencies 48 49 EGL 1.2 is required. 50 51 This extension is written based on the wording of the EGL 1.4 52 specification. 53 54 Interacts with EGL_EXT_client_extensions. 55 56Overview 57 58 eglGetProcAddress is currently defined to not support the querying 59 of non-extension EGL or client API functions. Non-extension 60 functions are expected to be exposed as library symbols that can 61 be resolved statically at link time, or dynamically at run time 62 using OS-specific runtime linking mechanisms. 63 64 With the addition of OpenGL and OpenGL ES 3 support to EGL, the 65 definition of a non-extension function becomes less clear. It is 66 common for one OpenGL library to implement many versions of 67 OpenGL. The suggested library name for OpenGL ES 3 is the same as 68 that of OpenGL ES 2. If OpenGL ES 3 applications linked 69 statically to OpenGL ES 3 functions are run on a system with only 70 OpenGL ES 2 support, they may fail to load. Similar problems 71 would be encountered by an application linking statically to 72 various OpenGL functions. 73 74 To avoid requiring applications to fall back to OS-specific 75 dynamic linking mechanisms, this extension drops the requirement 76 that eglGetProcAddress return only non-extension functions. If 77 the extension string is present, applications can query all EGL 78 and client API functions using eglGetProcAddress. 79 80 To allow users to query this extension before initializing a display, and 81 to also allow vendors to ship this extension without 82 EGL_EXT_client_extensions, two names are assigned to this extension: one 83 a display extension and the other a client extension. Identical 84 functionality is exposed by each name, but users query each name using 85 different methods. Users query EGL_KHR_get_all_proc_addresses in the 86 usual way; that is, by calling eglQueryString(dpy, EGL_EXTENSIONS) on an 87 initialized display. To query EGL_KHR_client_get_all_proc_addresses, 88 users must use a different method which is described below in the section 89 concerning EGL_EXT_client_extensions. 90 91New Types 92 93 None 94 95New functions 96 97 None 98 99New Tokens 100 101 None 102 103Rename section "3.10 Obtaining Extension Function Pointers" to "3.10 104Obtaining Function Pointers", and replace its content with the 105following: 106 107 "The client API and EGL extensions and versions which are available to a 108 client may vary at runtime, depending on factors such as the rendering 109 path being used (hardware or software), resources available to the 110 implementation, or updated device drivers. Therefore, the address of 111 functions may be queried at runtime. The function 112 113 void (*eglGetProcAddress(const char *procname))(void); 114 115 returns the address of the function named by <procName>. <procName> must 116 be a NULL-terminated string. The pointer returned should be cast to a 117 function pointer matching the function's definition in the corresponding 118 API or extension specification. A return value of NULL indicates that 119 the specified function does not exist for the implementation. 120 121 A non-NULL return value for eglGetProcAddress does not guarantee that a 122 function is actually supported at runtime. The client must also make a 123 corresponding query, such as glGetString(GL_EXTENSIONS) for OpenGL and 124 OpenGL ES extensions; vgGetString(VG_EXTENSIONS) for OpenVG extensions; 125 eglQueryString(dpy, EGL_EXTENSIONS) for EGL extensions; or query the 126 corresponding API's version for non-extension functions, to determine if 127 a function is supported by a particular client API context or display. 128 129 Client API function pointers returned by eglGetProcAddress are 130 independent of the display and the currently bound client API context, 131 and may be used by any client API context which supports the function. 132 133 eglGetProcAddress may be queried for all EGL and client API extension 134 and non-extension functions supported by the implementation (whether 135 those functions are supported by the current client API context or not). 136 137 For functions that are queryable with eglGetProcAddress, implementations 138 may also choose to export those functions statically from the object 139 libraries implementing them. However, portable clients cannot rely on 140 this behavior." 141 142Interactions with EGL_EXT_client_extensions 143 144 The EGL specification describes the behavior of eglGetProcAddress as 145 independent of any display. Therefore, this extension's functionality 146 falls under the classification 'client extension' rather than 'display 147 extension'. Accordingly, users may wish to query this extension before 148 initializing a display. 149 150 If the EGL_EXT_client_extensions is supported, then users can query this 151 extension by checking for the name EGL_KHR_client_get_all_proc_addresses 152 in the extension string of EGL_NO_DISPLAY. 153 154 The EGL implementation must expose the name 155 EGL_KHR_client_get_all_proc_addresses if and only if it exposes 156 EGL_KHR_get_all_proc_addresses and supports EGL_EXT_client_extensions. 157 This requirement eliminates the problematic situation where, if an EGL 158 implementation exposed only one name, then an EGL client would fail to 159 detect the extension if it queried only the other name. 160 161 Despite having two names assigned to this extension, the restrictions 162 described in EGL_EXT_client_extensions still apply. As 163 EGL_KHR_client_get_all_proc_addresses is defined as a client extension, 164 its name can appear only in the extension string of EGL_NO_DISPLAY and 165 not in the extension string of any valid display. The converse applies 166 to EGL_KHR_get_all_proc_addresses, as it is defined as a display 167 extension. 168 169Issues 170 171 1. What should this spec be called? 172 173 PROPOSED: KHR_get_all_proc_addresses 174 175 2. Should this extension be classified as a client extension, as defined 176 by EGL_EXT_client_extensions? 177 178 DISCUSSION: Yes and no. 179 180 Yes, because this extension exposes functionality that is solely 181 a property of the EGL library itself, independent of any display. 182 Such functionality falls under the classification of 'client 183 extension'. 184 185 No, because classifying it as a client extension would create 186 a dependency on EGL_EXT_client_extensions, and there exists no 187 precedent for a KHR extension that depends on an EXT extension. 188 189 RESOLUTION: Expose this extension under two names, one a client 190 extension and the other a display extension. 191 192Revision History 193 194 #3 (July 31, 2013) Chad Versace 195 - Assign additional name, EGL_KHR_client_get_all_proc_addresses. 196 - Add section "Extension Types", section "Interactions with 197 EGL_EXT_client_extensions", and issue #2. 198 199 #2 (March 6, 2013) Jon Leech 200 - Bring into sync with latest EGL 1.4 spec update and simplify 201 language describing which functions may be queried. Minor 202 formatting changes for greater consistency with other KHR 203 extension specs. 204 205 #1 (February 4, 2013) James Jones 206 - Initial draft 207