diff options
Diffstat (limited to 'glew/auto/EGL-Registry/extensions/ARM')
3 files changed, 530 insertions, 0 deletions
diff --git a/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_image_format.txt b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_image_format.txt new file mode 100644 index 0000000..c1a40ec --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_image_format.txt @@ -0,0 +1,126 @@ +Name + + ARM_image_format + +Name Strings + + EGL_ARM_image_format + +Contributors + + Jan-Harald Fredriksen + +Contact + + Jan-Harald Fredriksen (jan-harald.fredriksen 'at' arm.com) + +IP Status + + No known IP claims. + +Status + + Complete + +Version + + Version 1 - February 18, 2020 + +Number + + 138 + +Dependencies + + This extension is written against the wording of the EGL 1.4 + specification. + + This extension reuses tokens from EGL_EXT_pixel_format_float. + +Overview + + When an EGLImage is created from an existing image resource the + implementation will deduce the format of the image data from that + resource. In some cases, however, the implementation may not know how to + map the existing image resource to a known format. This extension extends + the list of attributes accepted by eglCreateImageKHR such that applications + can tell the implementation how to interpret the data. + +New Procedures and Functions + + None. + +New Tokens + + Accepted as an attribute name in the <attrib_list> argument of + eglCreateImageKHR: + EGL_COLOR_COMPONENT_TYPE_EXT 0x3339 + + Accepted as attribute values for the EGL_COLOR_COMPONENT_TYPE_EXT attribute + of eglCreateImageKHR: + + EGL_COLOR_COMPONENT_TYPE_FIXED_EXT 0x333A + EGL_COLOR_COMPONENT_TYPE_FLOAT_EXT 0x333B + EGL_COLOR_COMPONENT_TYPE_UNSIGNED_INTEGER_ARM 0x3287 + EGL_COLOR_COMPONENT_TYPE_INTEGER_ARM 0x3288 + EGL_RED_SIZE 0x3024 + EGL_GREEN_SIZE 0x3023 + EGL_BLUE_SIZE 0x3022 + EGL_ALPHA_SIZE 0x3021 + +Modifications to the EGL 1.4 Specification + + Add the following rows to Table 3.xx: Legal attributes for + eglCreateImageKHR <attrib_list> parameter: + + +------------------------------+------------------------------+-----------+---------------+ + | Attribute | Description | Valid | Default Value | + | | | <target>s | | + +------------------------------+------------------------------+-----------+---------------+ + | EGL_COLOR_COMPONENT_TYPE_EXT | Specifies the component | All | NA | + | | type the EGLImage source | | | + | | is interpreted as | | | + | EGL_RED_SIZE | Specifies the red component | All | NA | + | | size the EGLImage source | | | + | | is interpreted as | | | + | EGL_GREEN_SIZE | Specifies the green component| All | NA | + | | size the EGLImage source | | | + | | is interpreted as | | | + | EGL_BLUE_SIZE | Specifies the blue component | All | NA | + | | size the EGLImage source | | | + | | is interpreted as | | | + | EGL_ALPHA_SIZE | Specifies the alpha component| All | NA | + | | size the EGLImage source | | | + | | is interpreted as | | | + +------------------------------+------------------------------+-----------+---------------+ + + If <attrib_list> specifies values for EGL_COLOR_COMPONENT_TYPE_EXT, + EGL_RED_SIZE, EGL_GREEN_SIZE, EGL_BLUE_SIZE, or EGL_ALPHA_SIZE, the + implementation will treat these as hints for how to interpret the contents + of <buffer>. + + EGL_COLOR_COMPONENT_TYPE_EXT indicates the component type of <buffer> and + must be either EGL_COLOR_COMPONENT_TYPE_FIXED_EXT for fixed-point, + EGL_COLOR_COMPONENT_TYPE_FLOAT_EXT for floating-point, + EGL_COLOR_COMPONENT_TYPE_UNSIGNED_INTEGER_ARM for unsigned integer, or + EGL_COLOR_COMPONENT_TYPE_INTEGER_ARM for integer components. + +Add to the list of error conditions for eglCreateImageKHR: + + * If the implementation is unable to interpret the contents <buffer> + according to the component types and sizes in <attrib_list>, then a + EGL_BAD_MATCH error is generated. + +Issues + + 1. Should there be a way to specify the component order? + + Resolved. No, the component order is interpreted to be R, G, B, A, + with R mapping to component 0. If the application needs a different + component order it can use swizzle in the client API side or in the + shader. + +Revision History + + Version 1, 2020/02/18 + - Internal revisions diff --git a/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt new file mode 100644 index 0000000..bce6a74 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt @@ -0,0 +1,219 @@ +Name + + ARM_implicit_external_sync + +Name Strings + + EGL_ARM_implicit_external_sync + +Contributors + + David Garbett + Ray Smith + +Contacts + + David Garbett, ARM Ltd. (david 'dot' garbett 'at' arm 'dot' com) + +Status + + Draft + +Version + + Version 1, September 8, 2014 + +Number + + EGL Extension #103 + +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 extends the "fence sync objects" defined in + EGL_KHR_fence_sync. It allows the condition that triggers the associated + fence command in the client API command stream to be explicitly specified on + fence object creation. It introduces a new condition that can be used to + ensure ordering between operations on buffers that may be accessed + externally to the client API, when those operations use an implicit + synchronization mechanism. Such a fence object will be signaled when all + prior commands affecting such buffers are guaranteed to be executed before + such external commands. + + Applications have limited control over when a native buffer is read or + written by the GPU when imported as an EGLImageKHR or via + eglCreatePixmapSurface, which is controlled by the EGL and client API + implementations. While eglWaitClient or a client call such as glFinish + could be called, this forces all rendering to complete, which can result in + CPU/GPU serialization. Note this isn't an issue for window surfaces, where + eglSwapBuffers ensures the rendering occurs in the correct order for the + platform. + + Some platforms have an implicit synchronization mechanism associated with + native resources, such as buffers. This means that accesses to the buffer + have an implicit ordering imposed on them, without involvement from the + application. However, this requires that an application that has imported + an affected buffer into EGL has a mechanism to flush any drawing operations + in flight such that they are waiting on the synchronization mechanism. + Otherwise the application cannot guarantee that subsequent operations (such + as displaying a rendered buffer) will occur after the commands performed by + the client API (such as rendering the buffer). + + The mechanism to wait for the synchronization mechanism should not require + the application to wait for all rendering to complete, so that it can + continue preparing further commands asynchronously to the queued commands. + This extension provides this functionality using the new condition type for + fence sync objects, so the application only waits for the external + synchronization. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + Accepted as a value of the EGL_SYNC_CONDITION_KHR attribute passed in the + <attrib_list> list to eglCreateSyncKHR when <type> is EGL_FENCE_SYNC_KHR, + and can populate <*value> when eglGetSyncAttribKHR is called with + <attribute> set to EGL_SYNC_CONDITION_KHR: + + EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM 0x328A + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add the following after the fifth paragraph of Section 3.8.1 (Sync Objects), + added by KHR_fence_sync: + + "Typically client APIs are considered to execute commands in a linear queue, + where a prior command is executed and completes before a later command is + started. By default fence sync objects adhere to this model - a fence is + signaled once prior commands have completed. However on some platforms a + command in a client API may transition through multiple states before it + completes, which may impact other components of the system. Therefore the + condition that all prior commands must meet before the fence is triggered is + configurable." + + Replace the sixth paragraph of Section 3.8.1 (Sync Objects), added by + KHR_fence_sync: + + "If, <type> is EGL_SYNC_FENCE_KHR, a fence sync object is created. In this + case <attrib_list> can be NULL or empty, or can specify the + EGL_SYNC_CONDITION_KHR attribute. Attributes of the fence sync object have + the following default values:" + + Replace the eighth paragraph of Section 3.8.1 (Sync Objects), added by + KHR_fence_sync: + + "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. The + condition is specified by the EGL_SYNC_CONDITION_KHR attribute passed to + eglCreateSyncKHR. + + If the condition is specified as EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, the + fence sync object 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. + + If the condition is specified as + EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM, the fence sync object is + satisfied by the completion of the fence command corresponding to the sync + object, and the <submission> of all preceding commands in the associated + client API context's command stream. <Submission> defines the point in time + when a command has been queued on any implicit synchronization mechanisms + present on the platform which apply to any of the resources used by the + command. This enforces an ordering, as defined by the synchronization + mechanism, between the command and any other operations that also respect + the synchronization mechanism(s)." + + Replace the second entry in the list of eglCreateSyncKHR errors in Section + 3.8.1 (Sync Objects), added by KHR_fence_sync: + + " * If <type> is EGL_SYNC_FENCE_KHR and <attrib_list> contains an attribute + other than EGL_SYNC_CONDITION_KHR, EGL_NO_SYNC_KHR is returned and an + EGL_BAD_ATTRIBUTE error is generated. + * If <type> is EGL_SYNC_FENCE_KHR and the value specified for + EGL_SYNC_CONDITION_KHR is not EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR or + EGL_SYNC_PRIOR_COMMANDS_SUBMITTED_ARM, EGL_NO_SYNC_KHR is returned and + an EGL_BAD_ATTRIBUTE error is generated." + +Issues + + 1. Could glFlush guarantee commands are submitted, making this extension + unnecessary? + + RESOLVED: The Open GL ES 3.1 specification defines glFlush() as causing "all + previously issued GL commands to complete in finite time". There is no + requirement for the execution of commands to reach any specific point before + it returns - a valid implementation of glFlush() could spawn a new thread + that sleeps for a minute before submitting the pending commands. While an + implementation could decide to ensure all commands are submitted within + glFlush(), it could not be assumed to be the case across all + implementations. + + In addition, there may be scenarios when submitting commands within + glFlush() is harmful. Waiting for command submission may have a performance + impact on some implementations that perform processing of commands + asynchronously. In addition such a change may restrict what is possible in + the future. For example if user events were introduced into OpenGL ES they + have the potential of introducing deadlocks if submission in glFlush() is + guaranteed. + + 2. Should a new entry point be defined that flushes commands synchronously, + instead of the new fence type as defined by this extension? + + RESOLVED: While a synchronous "flush and submit" entrypoint would meet the + requirements for this extension, there may be a small benefit in enabling + the application to continue processing between flushing and waiting for + submission. In addition, the semantics of the existing EGL_KHR_fence_sync + extension closely match what is required for this extension, so defining + the new functionality in terms of fences may enable simpler implementations. + + 3. Should OpenGL ES 3 glFenceSync be extended in preference to + eglCreateSyncKHR? + + RESOLVED: Some platforms are yet to move to a OpenGL ES 3 implementation, or + may be unwilling to expose OpenGL ES 3 entrypoints to applications. As + EGL_KHR_fence_sync is older than OpenGL ES 3, and is comparatively a small + change, it has a better chance of adoption in a platform. + + In addition this extension is based on the idea that there are + platform-specific ways to interact with the client API command stream. As + this is platform-specific, and does not fit with the existing model + typically used by client APIs (such as Open GL ES) it is better placed in + EGL. + + Finally extending EGL has the advantage that the extension applies to all + client APIs. + + 4. Should a new <type> parameter be defined, instead of extending the + EGL_FENCE_SYNC_KHR fence sync objects defined by EGL_KHR_fence_sync? + + RESOLVED: Whether the new functionality is defined as an extension to the + existing fence sync objects, or whether they are defined as a new type of + sync object, we must acknowledge that the model of a client API processing + commands serially (with prior commands completing before later commands are + executed) is too simplistic for some platforms. + + Extending the existing fence sync objects allows us to use the existing + concept of conditions that trigger the fences. It also allows the maximum + amount of reuse of existing functionality, potentially simplifying the + implementation and the use of the extension by applications. + +Revision History +#1 (David Garbett, September 8, 2014) + - Initial draft. diff --git a/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_pixmap_multisample_discard.txt b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_pixmap_multisample_discard.txt new file mode 100644 index 0000000..847a749 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_pixmap_multisample_discard.txt @@ -0,0 +1,185 @@ +Name + + ARM_pixmap_multisample_discard + +Name Strings + + EGL_ARM_pixmap_multisample_discard + +Contributors + + Arne Bergene Fossaa + Tom Cooksey + Endre Sund + David Garbett + +Contacts + + Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) + +Status + + Complete. + +Version + + Version 1, March 5, 2013 + +Number + + EGL Extension #54 + +Dependencies + + EGL 1.0 is required. + + This extension is written against the wording of the EGL 1.4 Specification. + +Overview + + ARM_pixmap_multisample_discard adds an attribute to eglCreatePixmapSurface + that allows the client API implementation to resolve a multisampled pixmap + surface, therefore allowing the multisample buffer to be discarded. + + Some GPU architectures - such as tile-based renderers - are capable of + performing multisampled rendering by storing multisample data in internal + high-speed memory and downsampling the data when writing out to external + memory after rendering has finished. Since per-sample data is never written + out to external memory, this approach saves bandwidth and storage space. In + this case multisample data gets discarded, however this is acceptable in + most cases. + + The extension provides the EGL_DISCARD_SAMPLES_ARM attribute that allows + for implicit resolution when rendering to a pixmap surface. This complements + the OpenGL ES EXT_multisampled_render_to_texture extension which provides + similar functionality for rendering to an OpenGL ES texture. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + Accepted as an attribute name in the <attrib_list> argument of + eglCreatePixmapSurface and by the <attribute> parameter of eglQuerySurface: + + EGL_DISCARD_SAMPLES_ARM 0x3286 + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + Modify the second paragraph under "The Multisample Buffer" of Section 3.4, + page 18 (Configuration Management) + + "Operations such as posting a surface with eglSwapBuffers (see section + 3.9.1, copying a surface with eglCopyBuffers (see section 3.9.2), reading + from the color buffer using client API commands, binding a client API + context to a surface (see section 3.7.3), and flushing to a pixmap surface + created with the EGL_DISCARD_SAMPLES_ARM attribute enabled (see + section 3.5.4) may cause resolution of the multisample buffer to the color + buffer." + + Modify the fifth paragraph under "The Multisample Buffer" of Section 3.4, + page 18 (Configuration Management) + + "There are no single-sample depth or stencil buffers for a multisample + EGLConfig, or with a pixmap surface created with the + EGL_DISCARD_SAMPLES_ARM attribute (see section 3.5.4). The only depth and + stencil buffers are those in the multisample buffer. If the color samples + in the multisample buffer store fewer bits than are stored in the color + buffers, this fact will not be reported accurately. Presumably a + compression scheme is being employed, and is expected to maintain an + aggregate resolution equal to that of the color buffers." + + Modify the fifth paragraph of Section 3.5.4, page 34 (Creating Native + Pixmap Rendering Surfaces) + + "attrib list specifies a list of attributes for the pixmap. The list has the + same structure as described for eglChooseConfig. Attributes that can be + specified in attrib list include EGL_VG_COLORSPACE, EGL_VG_ALPHA_FORMAT and + EGL_DISCARD_SAMPLES_ARM." + + Add the following between paragraphs eight and nine of Section 3.5.4, + page 34 (Creating Native Pixmap Rendering Surfaces) + + "EGL_DISCARD_SAMPLES_ARM specifies whether the client API implementation is + allowed to implicitly resolve the multisample buffer. On some GPU + architectures - such as tile-based renderers - an implicit resolve can avoid + writing the multisample buffer back to external memory as the multisample + data is stored in internal high-speed memory. + + The implicit resolve can occur when the client API uses the pixmap as the + source or destination of any operation, when flushing to the pixmap or when + the client API unbinds (or breaks) the pixmap. When these operations occur + is dependent on the client API implementation. They can occur as an explicit + part of client API functions (such as glFinish, glReadPixels and + glCopyTexImage) or they can occur implicitly. + + Further rendering causes the implementation to read the surface buffer and + any ancillary buffers back in as single-sampled data. + Therefore use of this attribute may result in lower quality images. + + Valid values are EGL_TRUE, in which case the multisample buffer can be + discarded, or EGL_FALSE, in which case the multisample buffer is preserved. + The default value is EGL_FALSE. + + Note that the multisample buffer may be discarded during eglMakeCurrent + regardless of the value of the EGL_DISCARD_SAMPLES_ARM attribute (see + section 3.7.3)." + + Modify the ninth paragraph of Section 3.5.4, page 34 (Creating Native + Pixmap Rendering Surfaces) + + "On failure eglCreatePixmapSurface returns EGL_NO_SURFACE. If the attributes + of pixmap do not correspond to config, then an EGL_BAD_MATCH error is + generated. If config does not support rendering to pixmaps (the + EGL_SURFACE_TYPE attribute does not contain EGL_PIXMAP_BIT), an + EGL_BAD_MATCH error is generated. If config does not support the colorspace + or alpha format attributes specified in attriblist (as defined for + eglCreateWindowSurface), an EGL_BAD_MATCH error is generated. If config does + not specify non-zero EGL_SAMPLES and EGL_SAMPLE_BUFFERS and the + EGL_DISCARD_SAMPLES_ARM attribute is set to EGL_TRUE, then an EGL_BAD_MATCH + error is generated. If config is not a valid EGLConfig, an EGL_BAD_CONFIG + error is generated. If pixmap is not a valid native pixmap handle, then an + EGL_BAD_NATIVE_PIXMAP error should be generated. If there is already an + EGLSurface associated with pixmap (as a result of a previous + eglCreatePixmapSurface call), then a EGL_BAD_ALLOC error is generated. + Finally, if the implementation cannot allocate resources for the new EGL + pixmap, an EGL_BAD_ALLOC error is generated." + + + Add the following entry to Table 3.5, page 36 + (Queryable surface attributes and types) + + Attribute Type Description + ------------------------- ------- --------------------------------------- + EGL_DISCARD_SAMPLES_ARM boolean Multisample resolve when flushing to + surface + + Add the following paragraph before the last paragraph of Section 3.5.7, + page 38 (Surface Attributes) + + "Querying EGL_DISCARD_SAMPLES_ARM returns whether a multisample resolve + is forced on every flush to the surface (see section 3.5.4). This will only + return EGL_TRUE for pixmap surfaces created with the EGL_DISCARD_SAMPLES_ARM + attribute set to EGL_TRUE. EGL_FALSE will be returned for window and + pbuffer surfaces." + +Issues + + 1. Should eglSurfaceAttrib accept EGL_DISCARD_SAMPLES_ARM? + RESOLVED: No. The attribute should be decided at surface creation time. + + 2. Should eglCreateWindowSurface or eglCreatePbufferSurface accept + EGL_DISCARD_SAMPLES_ARM? + RESOLVED: No. While the attribute could equally apply to window and + pbuffer surfaces, no use case has been identified to justify the + additional maintenance this would require. + +Revision History + + Version 1, 2013/03/05 - Original release. + |