diff options
Diffstat (limited to 'glew/auto/EGL-Registry/extensions/ANDROID')
11 files changed, 1674 insertions, 0 deletions
diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_GLES_layers.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_GLES_layers.txt new file mode 100644 index 0000000..eb2a7d9 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_GLES_layers.txt @@ -0,0 +1,64 @@ +Name + + ANDROID_GLES_layers + +Name Strings + + EGL_ANDROID_GLES_layers + +Contributors + + Cody Northrop + +Contact + + Cody Northrop, Google LLC (cnorthrop 'at' google.com) + +Status + + Draft + +Version + + Version 1, March 3, 2019 + +Number + + EGL Extension #132 + +Extension Type + + EGL client extension + +Dependencies + + Requires EGL 1.5 or EGL_EXT_client_extensions + +Overview + + This extension indicates the EGL loader supports GLES layering on Android. + It does not add any requirements to drivers or hardware. + + See frameworks/native/opengl/libs/EGL/GLES_layers.md in Android for + more information. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + None + +Issues + + None + +Revision History + +#1 (Cody Northrop, March 3, 2019) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_blob_cache.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_blob_cache.txt new file mode 100644 index 0000000..e984694 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_blob_cache.txt @@ -0,0 +1,211 @@ +Name + + ANDROID_blob_cache + +Name Strings + + EGL_ANDROID_blob_cache + +Contributors + + Jamie Gennis + +Contact + + Jamie Gennis, Google Inc. (jgennis 'at' google.com) + +Status + + Complete + +Version + + Version 3, December 13, 2012 + +Number + + EGL Extension #48 + +Dependencies + + Requires EGL 1.0 + + This extension is written against the wording of the EGL 1.4 Specification + +Overview + + Shader compilation and optimization has been a troublesome aspect of OpenGL + programming for a long time. It can consume seconds of CPU cycles during + application start-up. Additionally, state-based re-compiles done + internally by the drivers add an unpredictable element to application + performance tuning, often leading to occasional pauses in otherwise smooth + animations. + + This extension provides a mechanism through which client API + implementations may cache shader binaries after they are compiled. It may + then retrieve those cached shaders during subsequent executions of the same + program. The management of the cache is handled by the application (or + middleware), allowing it to be tuned to a particular platform or + environment. + + While the focus of this extension is on providing a persistent cache for + shader binaries, it may also be useful for caching other data. This is + perfectly acceptable, but the guarantees provided (or lack thereof) were + designed around the shader use case. + + Note that although this extension is written as if the application + implements the caching functionality, on the Android OS it is implemented + as part of the Android EGL module. This extension is not exposed to + applications on Android, but will be used automatically in every + application that uses EGL if it is supported by the underlying + device-specific EGL implementation. + +New Types + + /* + * EGLsizeiANDROID is a signed integer type for representing the size of a + * memory buffer. + */ + #include <khrplatform.h> + typedef khronos_ssize_t EGLsizeiANDROID; + + /* + * EGLSetBlobFunc is a pointer to an application-provided function that a + * client API implementation may use to insert a key/value pair into the + * cache. + */ + typedef void (*EGLSetBlobFuncANDROID) (const void* key, + EGLsizeiANDROID keySize, const void* value, EGLsizeiANDROID valueSize) + + /* + * EGLGetBlobFunc is a pointer to an application-provided function that a + * client API implementation may use to retrieve a cached value from the + * cache. + */ + typedef EGLsizeiANDROID (*EGLGetBlobFuncANDROID) (const void* key, + EGLsizeiANDROID keySize, void* value, EGLsizeiANDROID valueSize) + +New Procedures and Functions + + void eglSetBlobCacheFuncsANDROID(EGLDisplay dpy, + EGLSetBlobFuncANDROID set, + EGLGetBlobFuncANDROID get); + +New Tokens + + None. + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + Add a new subsection after Section 3.8, page 50 + (Synchronization Primitives) + + "3.9 Persistent Caching + + In order to facilitate persistent caching of internal client API state that + is slow to compute or collect, the application may specify callback + function pointers through which the client APIs can request data be cached + and retrieved. The command + + void eglSetBlobCacheFuncsANDROID(EGLDisplay dpy, + EGLSetBlobFuncANDROID set, EGLGetBlobFuncANDROID get); + + sets the callback function pointers that client APIs associated with + display <dpy> can use to interact with caching functionality provided by + the application. <set> points to a function that inserts a new value into + the cache and associates it with the given key. <get> points to a function + that retrieves from the cache the value associated with a given key. The + semantics of these callback functions are described in Section 3.9.1 (Cache + Operations). + + Cache functions may only be specified once during the lifetime of an + EGLDisplay. The <set> and <get> functions may be called at any time and + from any thread from the time at which eglSetBlobCacheFuncsANDROID is + called until the time that the last resource associated with <dpy> is + deleted and <dpy> itself is terminated. Concurrent calls to these + functions from different threads is also allowed. + + If eglSetBlobCacheFuncsANDROID generates an error then all client APIs must + behave as though eglSetBlobCacheFuncsANDROID was not called for the display + <dpy>. If <set> or <get> is NULL then an EGL_BAD_PARAMETER error is + generated. If a successful eglSetBlobCacheFuncsANDROID call was already + made for <dpy> and the display has not since been terminated then an + EGL_BAD_PARAMETER error is generated. + + 3.9.1 Cache Operations + + To insert a new binary value into the cache and associate it with a given + key, a client API implementation can call the application-provided callback + function + + void (*set) (const void* key, EGLsizeiANDROID keySize, + const void* value, EGLsizeiANDROID valueSize) + + <key> and <value> are pointers to the beginning of the key and value, + respectively, that are to be inserted. <keySize> and <valueSize> specify + the size in bytes of the data pointed to by <key> and <value>, + respectively. + + No guarantees are made as to whether a given key/value pair is present in + the cache after the set call. If a different value has been associated + with the given key in the past then it is undefined which value, if any, is + associated with the key after the set call. Note that while there are no + guarantees, the cache implementation should attempt to cache the most + recently set value for a given key. + + To retrieve the binary value associated with a given key from the cache, a + client API implementation can call the application-provided callback + function + + EGLsizeiANDROID (*get) (const void* key, EGLsizeiANDROID keySize, + void* value, EGLsizeiANDROID valueSize) + + <key> is a pointer to the beginning of the key. <keySize> specifies the + size in bytes of the binary key pointed to by <key>. If the cache contains + a value associated with the given key then the size of that binary value in + bytes is returned. Otherwise 0 is returned. + + If the cache contains a value for the given key and its size in bytes is + less than or equal to <valueSize> then the value is written to the memory + pointed to by <value>. Otherwise nothing is written to the memory pointed + to by <value>. + +Issues + + 1. How should errors be handled in the callback functions? + + RESOLVED: No guarantees are made about the presence of values in the cache, + so there should not be a need to return error information to the client API + implementation. The cache implementation can simply drop a value if it + encounters an error during the 'set' callback. Similarly, it can simply + return 0 if it encouters an error in a 'get' callback. + + 2. When a client API driver gets updated, that may need to invalidate + previously cached entries. How can the driver handle this situation? + + RESPONSE: There are a number of ways the driver can handle this situation. + The recommended way is to include the driver version in all cache keys. + That way each driver version will use a set of cache keys that are unique + to that version, and conflicts should never occur. Updating the driver + could then leave a number of values in the cache that will never be + requested again. If needed, the cache implementation can handle those + values in some way, but the driver does not need to take any special + action. + + 3. How much data can be stored in the cache? + + RESPONSE: This is entirely dependent upon the cache implementation. + Presumably it will be tuned to store enough data to be useful, but not + enough to become problematic. :) + +Revision History + +#3 (Jon Leech, December 13, 2012) + - Fix typo in New Functions section & assign extension #. + +#2 (Jamie Gennis, April 25, 2011) + - Swapped the order of the size and pointer arguments to the get and set + functions. + +#1 (Jamie Gennis, April 22, 2011) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_create_native_client_buffer.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_create_native_client_buffer.txt new file mode 100644 index 0000000..3e0c4a9 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_create_native_client_buffer.txt @@ -0,0 +1,197 @@ +Name + + ANDROID_create_native_client_buffer + +Name Strings + + EGL_ANDROID_create_native_client_buffer + +Contributors + + Craig Donner + +Contact + + Craig Donner, Google Inc. (cdonner 'at' google.com) + +Status + + Draft + +Version + + Version 1, January 19, 2016 + +Number + + EGL Extension #99 + +Dependencies + + Requires EGL 1.2. + + EGL_ANDROID_image_native_buffer and EGL_KHR_image_base are required. + + This extension is written against the wording of the EGL 1.2 + Specification as modified by EGL_KHR_image_base and + EGL_ANDROID_image_native_buffer. + +Overview + + This extension allows creating an EGLClientBuffer backed by an Android + window buffer (struct ANativeWindowBuffer) which can be later used to + create an EGLImage. + +New Types + + None. + +New Procedures and Functions + + EGLClientBuffer eglCreateNativeClientBufferANDROID( + const EGLint *attrib_list) + +New Tokens + + EGL_NATIVE_BUFFER_USAGE_ANDROID 0x3143 + EGL_NATIVE_BUFFER_USAGE_PROTECTED_BIT_ANDROID 0x00000001 + EGL_NATIVE_BUFFER_USAGE_RENDERBUFFER_BIT_ANDROID 0x00000002 + EGL_NATIVE_BUFFER_USAGE_TEXTURE_BIT_ANDROID 0x00000004 + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add the following to section 2.5.1 "EGLImage Specification" (as modified by + the EGL_KHR_image_base and EGL_ANDROID_image_native_buffer specifications), + below the description of eglCreateImageKHR: + + "The command + + EGLClientBuffer eglCreateNativeClientBufferANDROID( + const EGLint *attrib_list) + + may be used to create an EGLClientBuffer backed by an ANativeWindowBuffer + struct. EGL implementations must guarantee that the lifetime of the + returned EGLClientBuffer is at least as long as the EGLImage(s) it is bound + to, following the lifetime semantics described below in section 2.5.2; the + EGLClientBuffer must be destroyed no earlier than when all of its associated + EGLImages are destroyed by eglDestroyImageKHR. <attrib_list> is a list of + attribute-value pairs which is used to specify the dimensions, format, and + usage of the underlying buffer structure. If <attrib_list> is non-NULL, the + last attribute specified in the list must be EGL_NONE. + + Attribute names accepted in <attrib_list> are shown in Table aaa, + together with the <target> for which each attribute name is valid, and + the default value used for each attribute if it is not included in + <attrib_list>. + + +---------------------------------+----------------------+---------------+ + | Attribute | Description | Default Value | + | | | | + +---------------------------------+----------------------+---------------+ + | EGL_NONE | Marks the end of the | N/A | + | | attribute-value list | | + | EGL_WIDTH | The width of the | 0 | + | | buffer data | | + | EGL_HEIGHT | The height of the | 0 | + | | buffer data | | + | EGL_RED_SIZE | The bits of Red in | 0 | + | | the color buffer | | + | EGL_GREEN_SIZE | The bits of Green in | 0 | + | | the color buffer | | + | EGL_BLUE_SIZE | The bits of Blue in | 0 | + | | the color buffer | | + | EGL_ALPHA_SIZE | The bits of Alpha in | 0 | + | | the color buffer | | + | | buffer data | | + | EGL_NATIVE_BUFFER_USAGE_ANDROID | The usage bits of | 0 | + | | the buffer data | | + +---------------------------------+----------------------+---------------+ + Table aaa. Legal attributes for eglCreateNativeClientBufferANDROID + <attrib_list> parameter. + + The maximum width and height may depend on the amount of available memory, + which may also depend on the format and usage flags. The values of + EGL_RED_SIZE, EGL_GREEN_SIZE, and EGL_BLUE_SIZE must be non-zero and + correspond to a valid pixel format for the implementation. If EGL_ALPHA_SIZE + is non-zero then the combination of all four sizes must correspond to a + valid pixel format for the implementation. The + EGL_NATIVE_BUFFER_USAGE_ANDROID flag may include any of the following bits: + + EGL_NATIVE_BUFFER_USAGE_PROTECTED_BIT_ANDROID: Indicates that the + created buffer must have a hardware-protected path to external display + sink. If a hardware-protected path is not available, then either don't + composite only this buffer (preferred) to the external sink, or (less + desirable) do not route the entire composition to the external sink. + + EGL_NATIVE_BUFFER_USAGE_RENDERBUFFER_BIT_ANDROID: The buffer will be + used to create a renderbuffer. This flag must not be set if + EGL_NATIVE_BUFFER_USAGE_TEXTURE_BIT_ANDROID is set. + + EGL_NATIVE_BUFFER_USAGE_TEXTURE_BIT_ANDROID: The buffer will be used to + create a texture. This flag must not be set if + EGL_NATIVE_BUFFER_USAGE_RENDERBUFFER_BIT_ANDROID is set. + + Errors + + If eglCreateNativeClientBufferANDROID fails, NULL will be returned, no + memory will be allocated, and one of the following errors will be + generated: + + * If the value of EGL_WIDTH or EGL_HEIGHT is not positive, the error + EGL_BAD_PARAMETER is generated. + + * If the combination of the values of EGL_RED_SIZE, EGL_GREEN_SIZE, + EGL_BLUE_SIZE, and EGL_ALPHA_SIZE is not a valid pixel format for the + EGL implementation, the error EGL_BAD_PARAMETER is generated. + + * If the value of EGL_NATIVE_BUFFER_ANDROID is not a valid combination + of gralloc usage flags for the EGL implementation, or is incompatible + with the value of EGL_FORMAT, the error EGL_BAD_PARAMETER is + Generated. + + * If both the EGL_NATIVE_BUFFER_USAGE_RENDERBUFFER_BIT_ANDROID and + EGL_NATIVE_BUFFER_USAGE_TEXTURE_BIT_ANDROID are set in the value of + EGL_NATIVE_BUFFER_USAGE_ANDROID, the error EGL_BAD_PARAMETER is + Generated." + +Issues + + 1. Should this extension define what combinations of formats and usage flags + EGL implementations are required to support? + + RESOLVED: Partially. + + The set of valid color combinations is implementation-specific and may + depend on additional EGL extensions, but generally RGB565 and RGBA888 should + be supported. The particular valid combinations for a given Android version + and implementation should be documented by that version. + + 2. Should there be an eglDestroyNativeClientBufferANDROID to destroy the + client buffers created by this extension? + + RESOLVED: No. + + A destroy function would add several complications: + + a) ANativeWindowBuffer is a reference counted object, may be used + outside of EGL. + b) The same buffer may back multiple EGLImages, though this usage may + result in undefined behavior. + c) The interactions between the lifetimes of EGLImages and their + EGLClientBuffers would become needlessly complex. + + Because ANativeWindowBuffer is a reference counted object, implementations + of this extension should ensure the buffer has a lifetime at least as long + as a generated EGLImage (via EGL_ANDROID_image_native_buffer). The simplest + method is to increment the reference count of the buffer in + eglCreateImagKHR, and then decrement it in eglDestroyImageKHR. This should + ensure proper lifetime semantics. + +Revision History + +#2 (Craig Donner, April 15, 2016) + - Set color formats and usage bits explicitly using additional attributes, + and add value for new token EGL_NATIVE_BUFFER_USAGE_ANDROID. + +#1 (Craig Donner, January 19, 2016) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_framebuffer_target.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_framebuffer_target.txt new file mode 100644 index 0000000..a15dfa8 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_framebuffer_target.txt @@ -0,0 +1,102 @@ +Name + + ANDROID_framebuffer_target + +Name Strings + + EGL_ANDROID_framebuffer_target + +Contributors + + Jamie Gennis + +Contact + + Jamie Gennis, Google Inc. (jgennis 'at' google.com) + +Status + + Complete + +Version + + Version 1, September 20, 2012 + +Number + + EGL Extension #47 + +Dependencies + + Requires EGL 1.0 + + This extension is written against the wording of the EGL 1.4 Specification + +Overview + + Android supports a number of different ANativeWindow implementations that + can be used to create an EGLSurface. One implementation, which is used to + send the result of performing window composition to a display, may have + some device-specific restrictions. Because of this, some EGLConfigs may + be incompatible with these ANativeWindows. This extension introduces a + new boolean EGLConfig attribute that indicates whether the EGLConfig + supports rendering to an ANativeWindow for which the buffers are passed to + the HWComposer HAL as a framebuffer target layer. + +New Types + + None. + +New Procedures and Functions + + None. + +New Tokens + + Accepted by the <attribute> parameter of eglGetConfigAttrib and + the <attrib_list> parameter of eglChooseConfig: + + EGL_FRAMEBUFFER_TARGET_ANDROID 0x3147 + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + Section 3.4, Configuration Management, add a row to Table 3.1. + + Attribute Type Notes + ------------------------------ ------- --------------------------- + EGL_FRAMEBUFFER_TARGET_ANDROID boolean whether use as a HWComposer + framebuffer target layer is + supported + + Section 3.4, Configuration Management, add a row to Table 3.4. + + Attribute Default Selection Sort Sort + Criteria Order Priority + ------------------------------ ------------- --------- ----- -------- + EGL_FRAMEBUFFER_TARGET_ANDROID EGL_DONT_CARE Exact None + + Section 3.4, Configuration Management, add a paragraph at the end of the + subsection titled Other EGLConfig Attribute Descriptions. + + EGL_FRAMEBUFFER_TARGET_ANDROID is a boolean indicating whether the + config may be used to create an EGLSurface from an ANativeWindow for + which the buffers are to be passed to HWComposer as a framebuffer + target layer. + + Section 3.4.1, Querying Configurations, change the last paragraph as follow + + EGLConfigs are not sorted with respect to the parameters + EGL_BIND_TO_TEXTURE_RGB, EGL_BIND_TO_TEXTURE_RGBA, EGL_CONFORMANT, + EGL_LEVEL, EGL_NATIVE_RENDERABLE, EGL_MAX_SWAP_INTERVAL, + EGL_MIN_SWAP_INTERVAL, EGL_RENDERABLE_TYPE, EGL_SURFACE_TYPE, + EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_RED_VALUE, + EGL_TRANSPARENT_GREEN_VALUE, EGL_TRANSPARENT_BLUE_VALUE, and + EGL_RECORDABLE_ANDROID. + +Issues + + +Revision History + +#1 (Jamie Gennis, September 20, 2012) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_front_buffer_auto_refresh.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_front_buffer_auto_refresh.txt new file mode 100644 index 0000000..4c0e64c --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_front_buffer_auto_refresh.txt @@ -0,0 +1,70 @@ +Name + + ANDROID_front_buffer_auto_refresh + +Name Strings + + EGL_ANDROID_front_buffer_auto_refresh + +Contributors + + Pablo Ceballos + +Contact + + Pablo Ceballos, Google Inc. (pceballos 'at' google.com) + +Status + + Draft + +Version + + Version 1, February 3, 2016 + +Number + + EGL Extension #XXX + +Dependencies + + Requires EGL 1.2 + + This extension is written against the wording of the EGL 1.5 Specification + +Overview + + This extension is intended for latency-sensitive applications that are doing + front-buffer rendering. It allows them to indicate to the Android compositor + that it should perform composition every time the display refreshes. This + removes the overhead of having to notify the compositor that the window + surface has been updated, but it comes at the cost of doing potentially + unneeded composition work if the window surface has not been updated. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + EGL_FRONT_BUFFER_AUTO_REFRESH_ANDROID 0x314C + +Add to the list of supported tokens for eglSurfaceAttrib in section 3.5.6 +"Surface Attributes", page 43: + + If attribute is EGL_ANDROID_front_buffer_auto_refresh, then value specifies + whether to enable or disable auto-refresh in the Android compositor when + doing front-buffer rendering. + +Issues + + None + +Revision History + +#1 (Pablo Ceballos, February 3, 2016) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_frame_timestamps.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_frame_timestamps.txt new file mode 100644 index 0000000..bf8d149 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_frame_timestamps.txt @@ -0,0 +1,259 @@ +Name + + ANDROID_get_frame_timestamps + +Name Strings + + EGL_ANDROID_get_frame_timestamps + +Contributors + + Brian Anderson + Dan Stoza + Pablo Ceballos + Jesse Hall + Fabien Sanglard + +Contact + + Brian Anderson, Google Inc. (brianderson 'at' google.com) + Dan Stoza, Google Inc. (stoza 'at' google.com) + Pablo Ceballos, Google Inc. (pceballos 'at' google.com) + Jesse Hall, Google Inc. (jessehall 'at' google.com) + Fabien Sanglard, Google Inc. (sanglardf 'at' google.com) + +Status + + Draft + +Version + + Version 8, April 11, 2017 + +Number + + EGL Extension #122 + +Dependencies + + Requires EGL 1.2 + + This extension is written against the wording of the EGL 1.5 Specification + +Overview + + This extension allows querying various timestamps related to the composition + and display of window surfaces. + + Some examples of how this might be used: + - The display present time can be used to calculate end-to-end latency + of the entire graphics pipeline. + - The queue time and rendering complete time can be used to determine + how long the application's rendering took to complete. Likewise, the + composition start time and finish time can be used to determine how + long the compositor's rendering work took. In combination these can be + used to help determine if the system is GPU or CPU bound. + +New Types + + /* + * EGLnsecsANDROID is a signed integer type for representing a time in + * nanoseconds. + */ + #include <khrplatform.h> + typedef khronos_stime_nanoseconds_t EGLnsecsANDROID; + +New Procedures and Functions + + EGLBoolean eglGetNextFrameIdANDROID(EGLDisplay dpy, EGLSurface surface, + EGLuint64KHR *frameId); + + EGLBoolean eglGetCompositorTimingANDROID(EGLDisplay dpy, + EGLSurface surface, EGLint numTimestamps, + const EGLint *names, EGLnsecsANDROID *values); + + EGLBoolean eglGetFrameTimestampsANDROID(EGLDisplay dpy, EGLSurface surface, + EGLuint64KHR frameId, EGLint numTimestamps, + const EGLint *timestamps, EGLnsecsANDROID *values); + + EGLBoolean eglGetFrameTimestampSupportedANDROID(EGLDisplay dpy, + EGLSurface surface, EGLint timestamp); + +New Tokens + + EGL_TIMESTAMPS_ANDROID 0x3430 + EGL_COMPOSITE_DEADLINE_ANDROID 0x3431 + EGL_COMPOSITE_INTERVAL_ANDROID 0x3432 + EGL_COMPOSITE_TO_PRESENT_LATENCY_ANDROID 0x3433 + EGL_REQUESTED_PRESENT_TIME_ANDROID 0x3434 + EGL_RENDERING_COMPLETE_TIME_ANDROID 0x3435 + EGL_COMPOSITION_LATCH_TIME_ANDROID 0x3436 + EGL_FIRST_COMPOSITION_START_TIME_ANDROID 0x3437 + EGL_LAST_COMPOSITION_START_TIME_ANDROID 0x3438 + EGL_FIRST_COMPOSITION_GPU_FINISHED_TIME_ANDROID 0x3439 + EGL_DISPLAY_PRESENT_TIME_ANDROID 0x343A + EGL_DEQUEUE_READY_TIME_ANDROID 0x343B + EGL_READS_DONE_TIME_ANDROID 0x343C + EGL_TIMESTAMP_PENDING_ANDROID -2 + EGL_TIMESTAMP_INVALID_ANDROID -1 + +Add to the list of supported tokens for eglSurfaceAttrib in section 3.5.6 +"Surface Attributes", page 43: + + If attribute is EGL_TIMESTAMPS_ANDROID, then values specifies whether to + enable/disable timestamp collection for this surface. A value of EGL_TRUE + enables timestamp collection, while a value of EGL_FALSE disables it. The + initial value is false. If surface is not a window surface this has no + effect. +Changes to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors) + + Add a new subsection under Section 3, + + "3.13 Composition and Display Timestamps + + The function + + EGLBoolean eglGetNextFrameIdANDROID(EGLDisplay dpy, EGLSurface surface, + EGLuint64KHR *frameId); + + Returns an identifier for the next frame to be swapped. The identifier can + be used to correlate a particular eglSwapBuffers with its timestamps in + eglGetFrameTimestampsANDROID. If any error is generated, the function will + return EGL_FALSE. + + The function + + EGLBoolean eglGetCompositorTimingANDROID(EGLDisplay dpy, + EGLSurface surface, EGLint numTimestamps, + const EGLint *names, EGLnsecsANDROID *values); + + allows querying anticipated timestamps and durations related to the + composition and display of a window surface. The values are not associated + with a particular frame and can be retrieved before the first swap. + + The eglGetCompositorTimingANDROID function takes an array of names to + query and returns their values in the corresponding indices of the values + array. The possible names that can be queried are: + - EGL_COMPOSITE_DEADLINE_ANDROID - The timestamp of the next time the + compositor will begin composition. This is effectively the deadline + for when the compositor must receive a newly queued frame. + - EGL_COMPOSITE_INTERVAL_ANDROID - The time delta between subsequent + composition events. + - EGL_COMPOSITE_TO_PRESENT_LATENCY_ANDROID - The time delta between + the start of composition and the expected present time of that + composition. This can be used to estimate the latency of the + actual present time. + + The function + + EGLBoolean eglGetFrameTimestampsANDROID(EGLDisplay dpy, + EGLSurface surface, EGLuint64KHR frameId, EGLint numTimestamps, + const EGLint *timestamps, EGLnsecsANDROID *values); + + allows querying various timestamps related to the composition and display + of specific frames of a window surface. + + The frameId indicates which frame to query. The implementation maintains a + limited history of timestamp data. If a query is made for a frame whose + timestamp history no longer exists then EGL_BAD_ACCESS is generated. If + timestamp collection has not been enabled for the surface then + EGL_BAD_SURFACE is generated. Timestamps for events that might still occur + will have the value EGL_TIMESTAMP_PENDING_ANDROID. Timestamps for events + that did not occur will have the value EGL_TIMESTAMP_INVALID_ANDROID. + Otherwise, the timestamp will be valid and indicate the event has occured. + Timestamp queries that are not supported will generate an EGL_BAD_PARAMETER + error. If any error is generated the function will return EGL_FALSE. + + The application can poll for the timestamp of particular events by calling + eglGetFrameTimestamps over and over without needing to call any other EGL + function between calls. This is true even for the most recently swapped + frame. eglGetFrameTimestamps is thread safe and can be called from a + different thread than the swapping thread. + + The eglGetFrameTimestampsANDROID function takes an array of timestamps to + query and returns timestamps in the corresponding indices of the values + array. The possible timestamps that can be queried are: + - EGL_REQUESTED_PRESENT_TIME_ANDROID - The time the application + requested this frame be presented. See EGL_ANDROID_presentation_time. + If the application does not request a presentation time explicitly, + this will correspond to buffer's queue time. + - EGL_RENDERING_COMPLETE_TIME_ANDROID - The time when all of the + application's rendering to the surface was completed. + - EGL_COMPOSITION_LATCH_TIME_ANDROID - The time when the compositor + selected this frame as the one to use for the next composition. The + latch is the earliest indication that the frame was submitted in time + to be composited. + - EGL_FIRST_COMPOSITION_START_TIME_ANDROID - The first time at which + the compositor began preparing composition for this frame. + - EGL_LAST_COMPOSITION_START_TIME_ANDROID - The last time at which the + compositor began preparing composition for this frame. If this frame + is composited only once, it will have the same value as + EGL_FIRST_COMPOSITION_START_TIME_ANDROID. If the value is not equal, + that indicates the subsequent frame was not submitted in time to be + latched by the compositor. Note: The value may not be updated for + every display refresh if the compositor becomes idle. + - EGL_FIRST_COMPOSITION_GPU_FINISHED_TIME_ANDROID - The time at which + the compositor's rendering work for this frame finished. This will be + zero if composition was handled by the display and the compositor + didn't do any rendering. + - EGL_DISPLAY_PRESENT_TIME_ANDROID - The time at which this frame + started to scan out to the physical display. + - EGL_DEQUEUE_READY_TIME_ANDROID - The time when the buffer became + available for reuse as a buffer the client can target without + blocking. This is generally the point when all read commands of the + buffer have been submitted, but not necessarily completed. + - EGL_READS_DONE_TIME_ANDROID - The time at which all reads for the + purpose of display/composition were completed for this frame. + + Not all implementations may support all of the above timestamp queries. The + functions + + EGLBoolean eglGetCompositorTimingSupportedANDROID(EGLDisplay dpy, + EGLSurface surface, EGLint name); + + and + + EGLBoolean eglGetFrameTimestampSupportedANDROID(EGLDisplay dpy, + EGLSurface surface, EGLint timestamp); + + allows querying which values are supported by the implementations of + eglGetCompositorTimingANDROID and eglGetFrameTimestampSupportedANDROID + respectively." + +Issues + + None + +Revision History + +#9 (Chris Forbes, June 11, 2019) + - Fix eglGetFrameTimestampSupportedANDROID function name in extension + spec to match reality + +#8 (Brian Anderson, April 11, 2017) + - Use reserved enumerant values. + +#7 (Brian Anderson, March 21, 2017) + - Differentiate between pending events and events that did not occur. + +#6 (Brian Anderson, March 16, 2017) + - Remove DISPLAY_RETIRE_TIME_ANDROID. + +#5 (Brian Anderson, January 13, 2017) + - Add eglGetCompositorTimingANDROID. + +#4 (Brian Anderson, January 10, 2017) + - Use an absolute frameId rather than a relative framesAgo. + +#3 (Brian Anderson, November 30, 2016) + - Add EGL_COMPOSITION_LATCH_TIME_ANDROID, + EGL_LAST_COMPOSITION_START_TIME_ANDROID, and + EGL_DEQUEUE_READY_TIME_ANDROID. + +#2 (Brian Anderson, July 22, 2016) + - Replace EGL_QUEUE_TIME_ANDROID with EGL_REQUESTED_PRESENT_TIME_ANDROID. + - Add DISPLAY_PRESENT_TIME_ANDROID. + +#1 (Pablo Ceballos, May 31, 2016) + - Initial draft. + diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_native_client_buffer.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_native_client_buffer.txt new file mode 100644 index 0000000..285bba4 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_get_native_client_buffer.txt @@ -0,0 +1,102 @@ +Name + + ANDROID_get_native_client_buffer + +Name Strings + + EGL_ANDROID_get_native_client_buffer + +Contributors + + Craig Donner + +Contact + + Craig Donner, Google Inc. (cdonner 'at' google.com) + +Status + + Complete + +Version + + Version 3, October 11, 2017 + +Number + + EGL Extension #123 + +Dependencies + + Requires EGL 1.2. + + EGL_ANDROID_image_native_buffer and EGL_KHR_image_base are required. + + This extension is written against the wording of the EGL 1.2 + Specification as modified by EGL_KHR_image_base and + EGL_ANDROID_image_native_buffer. + +Overview + + This extension allows creating an EGLClientBuffer from an Android + AHardwareBuffer object which can be later used to create an EGLImage. + +New Types + + struct AHardwareBuffer + +New Procedures and Functions + + EGLClientBuffer eglGetNativeClientBufferANDROID(const struct AHardwareBuffer *buffer) + +New Tokens + + None + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add the following to section 2.5.1 "EGLImage Specification" (as modified by + the EGL_KHR_image_base and EGL_ANDROID_image_native_buffer specifications), + below the description of eglCreateImageKHR: + + "The command + + EGLClientBuffer eglGetNativeClientBufferANDROID( + const struct AHardwareBuffer *buffer) + + may be used to create an EGLClientBuffer from an AHardwareBuffer object. + EGL implementations must guarantee that the lifetime of the returned + EGLClientBuffer is at least as long as the EGLImage(s) it is bound to, + following the lifetime semantics described below in section 2.5.2; the + EGLClientBuffer must be destroyed no earlier than when all of its associated + EGLImages are destroyed by eglDestroyImageKHR. + + Errors + + If eglGetNativeClientBufferANDROID fails, NULL will be returned, no + memory will be allocated, and the following error will be generated: + + * If the value of buffer is NULL, the error EGL_BAD_PARAMETER is + generated. + +Issues + + 1. Should this extension define what particular AHardwareBuffer formats EGL + implementations are required to support? + + RESOLVED: No. + + The set of valid formats is implementation-specific and may depend on + additional EGL extensions. The particular valid combinations for a given + Android version and implementation should be documented by that version. + +Revision History + +#3 (Jesse Hall, October 11, 2017) + - Assigned extension number, fixed minor issues for publication + +#2 (Craig Donner, February 17, 2017) + - Fix typographical errors. + +#1 (Craig Donner, January 27, 2017) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_image_native_buffer.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_image_native_buffer.txt new file mode 100644 index 0000000..7392d4f --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_image_native_buffer.txt @@ -0,0 +1,108 @@ +Name + + ANDROID_image_native_buffer + +Name Strings + + EGL_ANDROID_image_native_buffer + +Contributors + + Mathias Agopian + Jamie Gennis + Jesse Hall + +Contact + + Jesse Hall, Google Inc. (jessehall 'at' google.com) + +Status + + Complete + +Version + + Version 1, November 28, 2012 + +Number + + EGL Extension #49 + +Dependencies + + EGL 1.2 is required. + + EGL_KHR_image_base is required. + + This extension is written against the wording of the EGL 1.2 + Specification. + +Overview + + This extension enables using an Android window buffer (struct + ANativeWindowBuffer) as an EGLImage source. + +New Types + + None. + +New Procedures and Functions + + None. + +New Tokens + + Accepted by the <target> parameter of eglCreateImageKHR: + + EGL_NATIVE_BUFFER_ANDROID 0x3140 + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add to section 2.5.1 "EGLImage Specification" (as defined by the + EGL_KHR_image_base specification), in the description of + eglCreateImageKHR: + + "Values accepted for <target> are listed in Table aaa, below. + + +----------------------------+-----------------------------------------+ + | <target> | Notes | + +----------------------------+-----------------------------------------+ + | EGL_NATIVE_BUFFER_ANDROID | Used for ANativeWindowBuffer objects | + +----------------------------+-----------------------------------------+ + Table aaa. Legal values for eglCreateImageKHR <target> parameter + + ... + + If <target> is EGL_NATIVE_BUFFER_ANDROID, <dpy> must be a valid display, + <ctx> must be EGL_NO_CONTEXT, <buffer> must be a pointer to a valid + ANativeWindowBuffer object (cast into the type EGLClientBuffer), and + attributes other than EGL_IMAGE_PRESERVED_KHR are ignored." + + Add to the list of error conditions for eglCreateImageKHR: + + "* If <target> is EGL_NATIVE_BUFFER_ANDROID and <buffer> is not a + pointer to a valid ANativeWindowBuffer, the error EGL_BAD_PARAMETER + is generated. + + * If <target> is EGL_NATIVE_BUFFER_ANDROID and <ctx> is not + EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated. + + * If <target> is EGL_NATIVE_BUFFER_ANDROID and <buffer> was created + with properties (format, usage, dimensions, etc.) not supported by + the EGL implementation, the error EGL_BAD_PARAMETER is generated." + +Issues + + 1. Should this extension define what combinations of ANativeWindowBuffer + properties implementations are required to support? + + RESOLVED: No. + + The requirements have evolved over time and will continue to change with + future Android releases. The minimum requirements for a given Android + version should be documented by that version. + +Revision History + +#1 (Jesse Hall, November 28, 2012) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt new file mode 100644 index 0000000..d72edd7 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt @@ -0,0 +1,281 @@ +Name + + ANDROID_native_fence_sync + +Name Strings + + EGL_ANDROID_native_fence_sync + +Contributors + + Jamie Gennis + +Contact + + Jamie Gennis, Google Inc. (jgennis 'at' google.com) + +Status + + Complete + +Version + + Version 3, September 4, 2012 + +Number + + EGL Extension #50 + +Dependencies + + Requires EGL 1.1 + + This extension is written against the wording of the EGL 1.2 Specification + + EGL_KHR_fence_sync is required. + +Overview + + This extension enables the creation of EGL fence sync objects that are + associated with a native synchronization fence object that is referenced + using a file descriptor. These EGL fence sync objects have nearly + identical semantics to those defined by the KHR_fence_sync extension, + except that they have an additional attribute storing the file descriptor + referring to the native fence object. + + This extension assumes the existence of a native fence synchronization + object that behaves similarly to an EGL fence sync object. These native + objects must have a signal status like that of an EGLSyncKHR object that + indicates whether the fence has ever been signaled. Once signaled the + native object's signal status may not change again. + +New Types + + None. + +New Procedures and Functions + + EGLint eglDupNativeFenceFDANDROID( + EGLDisplay dpy, + EGLSyncKHR); + +New Tokens + + Accepted by the <type> parameter of eglCreateSyncKHR, and returned + in <value> when eglGetSyncAttribKHR is called with <attribute> + EGL_SYNC_TYPE_KHR: + + EGL_SYNC_NATIVE_FENCE_ANDROID 0x3144 + + Accepted by the <attrib_list> parameter of eglCreateSyncKHR: + + EGL_SYNC_NATIVE_FENCE_FD_ANDROID 0x3145 + + Accepted by the <attrib_list> parameter of eglCreateSyncKHR, and returned + by eglDupNativeFenceFDANDROID in the event of an error: + + EGL_NO_NATIVE_FENCE_FD_ANDROID -1 + + Returned in <value> when eglGetSyncAttribKHR is called with <attribute> + EGL_SYNC_CONDITION_KHR: + + EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID 0x3146 + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add the following after the sixth paragraph of Section 3.8.1 (Sync + Objects), added by KHR_fence_sync + + "If <type> is EGL_SYNC_NATIVE_FENCE_ANDROID, an EGL native fence sync + object is created. In this case the EGL_SYNC_NATIVE_FENCE_FD_ANDROID + attribute may optionally be specified. If this attribute is specified, it + must be set to either a file descriptor that refers to a native fence + object or to the value EGL_NO_NATIVE_FENCE_FD_ANDROID. + + The default values for the EGL native fence sync object attributes are as + follows: + + Attribute Name Initial Attribute Value(s) + --------------- -------------------------- + EGL_SYNC_TYPE_KHR EGL_SYNC_NATIVE_FENCE_ANDROID + EGL_SYNC_STATUS_KHR EGL_UNSIGNALED_KHR + EGL_SYNC_CONDITION_KHR EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR + EGL_SYNC_NATIVE_FENCE_FD_ANDROID EGL_NO_NATIVE_FENCE_FD_ANDROID + + If the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute is not + EGL_NO_NATIVE_FENCE_FD_ANDROID then the EGL_SYNC_CONDITION_KHR attribute is + set to EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID and the EGL_SYNC_STATUS_KHR + attribute is set to reflect the signal status of the native fence object. + Additionally, the EGL implementation assumes ownership of the file + descriptor, so the caller must not use it after calling eglCreateSyncKHR." + + Modify Section 3.8.1 (Sync Objects), added by KHR_fence_sync, starting at + the seventh paragraph + + "When a fence sync object is created or when an EGL native fence sync + object is created with the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute set + to EGL_NO_NATIVE_FENCE_FD_ANDROID, eglCreateSyncKHR also inserts a fence + command into the command stream of the bound client API's current context + (i.e., the context returned by eglGetCurrentContext), and associates it + with the newly created sync object. + + After associating the fence command with an EGL native fence sync object, + the next Flush() operation performed by the current client API causes a + new native fence object to be created, and the + EGL_SYNC_NATIVE_FENCE_ANDROID attribute of the EGL native fence object is + set to a file descriptor that refers to the new native fence object. This + new native fence object is signaled when the EGL native fence sync object + is signaled. + + When the condition of the sync object is satisfied by the fence command, + the sync is signaled by the associated client API context, causing any + eglClientWaitSyncKHR commands (see below) blocking on <sync> to unblock. + If the sync object is an EGL native fence sync object then the native + fence object is also signaled when the condition is satisfied. The + EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR condition is satisfied by completion + of the fence command corresponding to the sync object and all preceding + commands in the associated client API context's command stream. The sync + object will not be signaled until all effects from these commands on the + client API's internal and framebuffer state are fully realized. No other + state is affected by execution of the fence command. + + The EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID condition is satisfied by the + signaling of the native fence object referred to by the + EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute. When this happens any + eglClientWaitSyncKHR commands blocking on <sync> unblock." + + Modify the list of eglCreateSyncKHR errors in Section 3.8.1 (Sync Objects), + added by KHR_fence_sync + + "Errors + ------ + + * If <dpy> is not the name of a valid, initialized EGLDisplay, + EGL_NO_SYNC_KHR is returned and an EGL_BAD_DISPLAY error is + generated. + * If <type> is EGL_SYNC_FENCE_KHR and <attrib_list> is neither NULL nor + empty (containing only EGL_NONE), EGL_NO_SYNC_KHR is returned and an + EGL_BAD_ATTRIBUTE error is generated. + * If <type> is EGL_SYNC_NATIVE_FENCE_ANDROID and <attrib_list> contains + an attribute other than EGL_SYNC_NATIVE_FENCE_FD_ANDROID, + EGL_NO_SYNC_KHR is returned and an EGL_BAD_ATTRIBUTE error is + generated. + * If <type> is not a supported type of sync object, + EGL_NO_SYNC_KHR is returned and an EGL_BAD_ATTRIBUTE error is + generated. + * If <type> is EGL_SYNC_FENCE_KHR or EGL_SYNC_NATIVE_FENCE_ANDROID and + no context is current for the bound API (i.e., eglGetCurrentContext + returns EGL_NO_CONTEXT), EGL_NO_SYNC_KHR is returned and an + EGL_BAD_MATCH error is generated. + * If <type> is EGL_SYNC_FENCE_KHR or EGL_SYNC_NATIVE_FENCE_ANDROID and + <dpy> does not match the EGLDisplay of the currently bound context for + the currently bound client API (the EGLDisplay returned by + eglGetCurrentDisplay()) then EGL_NO_SYNC_KHR is returned and an + EGL_BAD_MATCH error is generated. + * If <type> is EGL_SYNC_FENCE_KHR or EGL_SYNC_NATIVE_FENCE_ANDROID and + the currently bound client API does not support the client API + extension indicating it can place fence commands, then EGL_NO_SYNC_KHR + is returned and an EGL_BAD_MATCH error is generated." + + Modify table 3.cc in Section 3.8.1 (Sync Objects), added by KHR_fence_sync + + " + Attribute Description Supported Sync Objects + ----------------- ----------------------- ---------------------- + EGL_SYNC_TYPE_KHR Type of the sync object All + EGL_SYNC_STATUS_KHR Status of the sync object All + EGL_SYNC_CONDITION_KHR Signaling condition EGL_SYNC_FENCE_KHR and + EGL_SYNC_NATIVE_FENCE_ANDROID only + " + + Modify the second paragraph description of eglDestroySyncKHR in Section + 3.8.1 (Sync Objects), added by KHR_fence_sync + + "If no errors are generated, EGL_TRUE is returned, and <sync> will no + longer be the handle of a valid sync object. Additionally, if <sync> is an + EGL native fence sync object and the EGL_SYNC_NATIVE_FENCE_FD_ANDROID + attribute is not EGL_NO_NATIVE_FENCE_FD_ANDROID then that file descriptor + is closed." + + Add the following after the last paragraph of Section 3.8.1 (Sync + Objects), added by KHR_fence_sync + + The command + + EGLint eglDupNativeFenceFDANDROID( + EGLDisplay dpy, + EGLSyncKHR sync); + + duplicates the file descriptor stored in the + EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute of an EGL native fence sync + object and returns the new file descriptor. + + Errors + ------ + + * If <sync> is not a valid sync object for <dpy>, + EGL_NO_NATIVE_FENCE_FD_ANDROID is returned and an EGL_BAD_PARAMETER + error is generated. + * If the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute of <sync> is + EGL_NO_NATIVE_FENCE_FD_ANDROID, EGL_NO_NATIVE_FENCE_FD_ANDROID is + returned and an EGL_BAD_PARAMETER error is generated. + * If <dpy> does not match the display passed to eglCreateSyncKHR + when <sync> was created, the behaviour is undefined." + +Issues + + 1. Should EGLSyncKHR objects that wrap native fence objects use the + EGL_SYNC_FENCE_KHR type? + + RESOLVED: A new sync object type will be added. + + We don't want to require all EGL fence sync objects to wrap native fence + objects, so we need some way to tell the EGL implementation at sync object + creation whether the sync object should support querying the native fence + FD attribute. We could do this with either a new sync object type or with a + boolean attribute. It might be nice to pick up future signaling conditions + that might be added for fence sync objects, but there may be things that + get added that don't make sense in the context of native fence objects. + + 2. Who is responsible for dup'ing the native fence file descriptors? + + RESOLVED: Whenever a file descriptor is passed into or returned from an + EGL call in this extension, ownership of that file descriptor is + transfered. The recipient of the file descriptor must close it when it is + no longer needed, and the provider of the file descriptor must dup it + before providing it if they require continued use of the native fence. + + 3. Can the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute be queried? + + RESOLVED: No. + + Returning the file descriptor owned by the EGL implementation would + violate the file descriptor ownership rule described in issue #2. Having + eglGetSyncAttribKHR return a different (dup'd) file descriptor each time + it's called seems wrong, so a new function was added to explicitly dup the + file descriptor. + + That said, the attribute is useful both as a way to pass an existing file + descriptor to eglCreateSyncKHR and as a way to describe the subsequent + behavior of EGL native fence sync objects, so it is left as an attribute + for which the value cannot be queried. + +Revision History + +#3 (Jamie Gennis, September 4, 2012) + - Reworded the extension to refer to "native fence" objects rather than + "Android fence" objects. + - Added a paragraph to the overview that describes assumptions about the + native fence sync objects. + +#2 (Jamie Gennis, July 23, 2012) + - Changed the file descriptor ownership transferring behavior. + - Added the eglDupAndroidFenceFDANDROID function. + - Removed EGL_SYNC_NATIVE_FENCE_FD_ANDROID from the table of gettable + attributes. + - Added language specifying that a native Android fence is created at the + flush following the creation of an EGL Android fence sync object that is + not passed an existing native fence. + +#1 (Jamie Gennis, May 29, 2012) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_presentation_time.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_presentation_time.txt new file mode 100644 index 0000000..ac1f45e --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_presentation_time.txt @@ -0,0 +1,140 @@ +Name + + ANDROID_presentation_time + +Name Strings + + EGL_ANDROID_presentation_time + +Contributors + + Jamie Gennis + Andy McFadden + Jesse Hall + +Contact + + Jamie Gennis, Google Inc. (jgennis 'at' google.com) + +Status + + Draft + +Version + + Version 4, June 6, 2016 + +Number + + EGL Extension #98 + +Dependencies + + Requires EGL 1.1 + + This extension is written against the wording of the EGL 1.4 Specification + +Overview + + Often when rendering a sequence of images, there is some time at which each + image is intended to be presented to the viewer. This extension allows + this desired presentation time to be specified for each frame rendered to + an EGLSurface, allowing the native window system to use it. + +New Types + + /* + * EGLnsecsANDROID is a signed integer type for representing a time in + * nanoseconds. + */ + #include <khrplatform.h> + typedef khronos_stime_nanoseconds_t EGLnsecsANDROID; + + +New Procedures and Functions + + EGLBoolean eglPresentationTimeANDROID( + EGLDisplay dpy, + EGLSurface surface, + EGLnsecsANDROID time); + +New Tokens + + None. + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add a new subsection before Section 3.9.4, page 53 (Posting Errors) + + "3.9.4 Presentation Time + + The function + + EGLBoolean eglPresentationTimeANDROID(EGLDisplay dpy, EGLSurface + surface, EGLnsecsANDROID time); + + specifies the time at which the current color buffer of <surface> should be + presented to the viewer. The <time> parameter should be a time in + nanoseconds, but the exact meaning of the time depends on the native + window system's use of the presentation time. In situations where + an absolute time is needed such as displaying the color buffer on a + display device, the time should correspond to the system monotonic up-time + clock. For situations in which an absolute time is not needed such as + using the color buffer for video encoding, the presentation time of the + first frame may be arbitrarily chosen and those of subsequent frames + chosen relative to that of the first frame. + + The presentation time may be set multiple times, with each call to + eglPresentationTimeANDROID overriding prior calls. Setting the + presentation time alone does not cause the color buffer to be made + visible, but if the color buffer is subsequently posted to a native window + or copied to a native pixmap then the presentation time of the surface at + that time may be passed along for the native window system to use. + + If the surface presentation time is successfully set, EGL_TRUE is + returned. Otherwise EGL_FALSE is returned and an appropriate error is + set. If <dpy> is not the name of a valid, initialized EGLDisplay, an + EGL_BAD_DISPLAY error is generated. If <surface> is not a valid EGLSurface + then an EGL_BAD_SURFACE error is generated. + +Issues + + 1. How is the presentation time used? + + RESOLVED: The uses of the presentation time are intentionally not specified + in this extension. Some possible uses include Audio/Video synchronization, + video frame timestamps for video encoding, display latency metrics, and + display latency control. + + 2. How can the current value of the clock that should be used for the + presentation time when an absolute time is needed be queried on Android? + + RESOLVED: The current clock value can be queried from the Java + System.nanoTime() method, or from the native clock_gettime function by + passing CLOCK_MONOTONIC as the clock identifier. + + 3. Should the presentation time be state which is used by eglSwapBuffers, + or should it be a new parameter to an extended variant of eglSwapBuffers? + + RESOLVED: The presentation time should be new state which is used by + the existing eglSwapBuffers call. Adding new state composes better with + other (hypothetical) extensions that also modify the behavior of + eglSwapBuffers. + +Revision History + +#4 (Jon Leech, June 6, 2016) + - Clean up for publication. Make prototype parameter name 'surface' + match the spec body. + +#3 (Jesse Hall, June 26, 2013) + - Enumerated errors generated by eglPresentationTimeANDROID. + - Added Issue #3 with resolution. + +#2 (Jamie Gennis, April 1, 2013) + - Clarified how uses that either do or do not need an absolute time should + be handled. + - Specified the eglPresentationTimeANDROID return value. + +#1 (Jamie Gennis, January 8, 2013) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_recordable.txt b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_recordable.txt new file mode 100644 index 0000000..d21094e --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ANDROID/EGL_ANDROID_recordable.txt @@ -0,0 +1,140 @@ +Name + + ANDROID_recordable + +Name Strings + + EGL_ANDROID_recordable + +Contributors + + Jamie Gennis + +Contact + + Jamie Gennis, Google Inc. (jgennis 'at' google.com) + +Status + + Complete + +Version + + Version 2, July 15, 2011 + +Number + + EGL Extension #51 + +Dependencies + + Requires EGL 1.0 + + This extension is written against the wording of the EGL 1.4 Specification + +Overview + + Android supports a number of different ANativeWindow implementations that + can be used to create an EGLSurface. One implementation, which records the + rendered image as a video each time eglSwapBuffers gets called, may have + some device-specific restrictions. Because of this, some EGLConfigs may be + incompatible with these ANativeWindows. This extension introduces a new + boolean EGLConfig attribute that indicates whether the EGLConfig supports + rendering to an ANativeWindow that records images to a video. + +New Types + + None. + +New Procedures and Functions + + None. + +New Tokens + + Accepted by the <attribute> parameter of eglGetConfigAttrib and + the <attrib_list> parameter of eglChooseConfig: + + EGL_RECORDABLE_ANDROID 0x3142 + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + Section 3.4, Configuration Management, add a row to Table 3.1. + + Attribute Type Notes + ---------------------- ------- -------------------------- + EGL_RECORDABLE_ANDROID boolean whether video recording is + supported + + Section 3.4, Configuration Management, add a row to Table 3.4. + + Attribute Default Selection Sort Sort + Criteria Order Priority + ---------------------- ------------- --------- ----- -------- + EGL_RECORDABLE_ANDROID EGL_DONT_CARE Exact None + + Section 3.4, Configuration Management, add a paragraph at the end of the + subsection titled Other EGLConfig Attribute Descriptions. + + EGL_RECORDABLE_ANDROID is a boolean indicating whether the config may + be used to create an EGLSurface from an ANativeWindow that is a video + recorder as indicated by the NATIVE_WINDOW_IS_VIDEO_RECORDER query on + the ANativeWindow. + + Section 3.4.1, Querying Configurations, change the last paragraph as follow + + EGLConfigs are not sorted with respect to the parameters + EGL_BIND_TO_TEXTURE_RGB, EGL_BIND_TO_TEXTURE_RGBA, EGL_CONFORMANT, + EGL_LEVEL, EGL_NATIVE_RENDERABLE, EGL_MAX_SWAP_INTERVAL, + EGL_MIN_SWAP_INTERVAL, EGL_RENDERABLE_TYPE, EGL_SURFACE_TYPE, + EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_RED_VALUE, + EGL_TRANSPARENT_GREEN_VALUE, EGL_TRANSPARENT_BLUE_VALUE, and + EGL_RECORDABLE_ANDROID. + +Issues + + 1. Should this functionality be exposed as a new attribute or as a bit in + the EGL_SURFACE_TYPE bitfield? + + RESOLVED: It should be a new attribute. It does not make sense to use up a + bit in the limit-size bitfield for a platform-specific extension. + + 2. How should the new attribute affect the sorting of EGLConfigs? + + RESOLVED: It should not affect sorting. Some implementations may not have + any drawback associated with using a recordable EGLConfig. Such + implementations should not have to double-up some of their configs to one + sort earlier than . Implementations that do have drawbacks can use the + existing caveat mechanism to report this drawback to the client. + + 3. How is this extension expected to be implemented? + + RESPONSE: There are two basic approaches to implementing this extension + that were considered during its design. In both cases it is assumed that a + color space conversion must be performed at some point because most video + encoding formats use a YUV color space. The two approaches are + distinguished by the point at which this color space conversion is + performed. + + One approach involves performing the color space conversion as part of the + eglSwapBuffers call before queuing the rendered image to the ANativeWindow. + In this case, the VisualID of the EGLConfig would correspond to a YUV + Android HAL pixel format from which the video encoder can read. The + EGLConfig would likely have the EGL_SLOW_CONFIG caveat because using that + config to render normal window contents would result in an RGB -> YUV color + space conversion when rendering the frame as well as a YUV -> RGB + conversion when compositing the window. + + The other approach involves performing the color space conversion in the + video encoder. In this case, the VisualID of the EGLConfig would + correspond to an RGB HAL pixel format from which the video encoder can + read. The EGLConfig would likely not need to have any caveat set, as using + this config for normal window rendering would not have any added cost. + +Revision History + +#2 (Jamie Gennis, July 15, 2011) + - Added issue 3. + +#1 (Jamie Gennis, July 8, 2011) + - Initial draft. |