diff options
Diffstat (limited to 'engine-ocean/External/glew/auto/EGL-Registry/extensions/NV')
26 files changed, 5904 insertions, 0 deletions
diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_3dvision_surface.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_3dvision_surface.txt new file mode 100644 index 0000000..c190687 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_3dvision_surface.txt @@ -0,0 +1,94 @@ +Name + + EGL_NV_3dvision_surface + +Name Strings + + EGL_NV_3dvision_surface + +Contact + + Greg Roth, NVIDIA (groth 'at' nvidia.com) + +Contributors + + Swaminathan Narayanan, NVIDIA + +IP Status + + NVIDIA Proprietary. + +Status + + Complete + +Version + + Last Modified Date: 02 December 2011 + Revision: 1 + +Number + + EGL Extension #46 + +Dependencies + + Requires EGL 1.4 + + Written against the EGL 1.4 specification. + +Overview + + NVIDIA 3D Vision provides stereoscopic 3d rendering without + requiring applications to change their rendering methods. However + there are cases where applications can benefit from adjusting 3D + vision parameters directly to experiment with this functionality in + applications not yet known to 3D Vision, to assist 3D Vision in + setting parameters correctly for unusual situations, or to present + application-specific user-accessible controls for 3D Vision + parameters. + + This extension provides the ability to explicitly create a surface + with 3D Vision support regardless of application detection. + +IP Status + + NVIDIA Proprietary + +New Procedures and Functions + + None + +New Tokens + + Accepted as an attribute to the <attrib_list> parameter of + CreateWindowSurface and CreatePbufferSurface + + EGL_AUTO_STEREO_NV 0x3136 + +Additions to Chapter 3 of the EGL 1.4 Specification (EGL Functions and +Errors) + + Additions to section 3.5.1 (Creating On-Screen Rendering Surfaces) + + Alter the end of the second to last paragraph: + + Attributes that can be specified in <attrib_list> include + EGL_RENDER_BUFFER, EGL_VG_COLORSPACE, EGL_VG_ALPHA_FORMAT, + and EGL_AUTO_STEREO_NV. + + Add before the last paragraph of section 3.5.1: + + EGL_AUTO_STEREO_NV specifies whether 3D Vision stereo + (stereo override) should be enabled in the driver. The default + value of EGL_AUTO_STEREO_NV is zero. + +Issues + + None + +Revision History + + Rev. Date Author Changes + ---- ------------- --------- ---------------------------------------- + 1 02 Dec 2011 groth Split 3D Vision capability from previous extension. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_context_priority_realtime.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_context_priority_realtime.txt new file mode 100644 index 0000000..5435c8c --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_context_priority_realtime.txt @@ -0,0 +1,195 @@ +Name + + NV_context_priority_realtime + +Name Strings + + EGL_NV_context_priority_realtime + +Contributors + + Sandeep Shinde + Kirill Artamonov + Sami Kiminki + Donghan Ryu + Daniel Koch + Mark Kilgard + +Contacts + + Sandeep Shinde, NVIDIA (sashinde 'at' nvidia 'dot' com) + +Status + + Complete + +Version + + Version 4 - November 21, 2017 + +Number + + EGL Extension #124 + +Dependencies + + Requires EGL 1.0. + + Requires EGL_IMG_context_priority + + This extension is written against the wording of the EGL 1.5 + Specification - August 27, 2014 (but may be implemented against earlier + versions). + +Overview + + This extension allows an EGLContext to be created with one extra + priority level in addition to three priority levels that are part of + EGL_IMG_context_priority extension. + + This new level has extra privileges that are not available to other three + levels. Some of the privileges may include: + - Allow realtime priority to only few contexts + - Allow realtime priority only to trusted applications + - Make sure realtime priority contexts are executed immediately + - Preempt any current context running on GPU on submission of + commands for realtime context + + The mechanism for determining which EGL context is allowed to use this + priority level is platform dependent. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + New attribute value accepted for the EGL_CONTEXT_PRIORITY_LEVEL_IMG + attribute in the <attrib_list> argument of eglCreateContext: + + EGL_CONTEXT_PRIORITY_REALTIME_NV 0x3357 + +Additions to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors) + + Add a NEW section "3.7.1.7 Context Priority" to specify the context + priority attribute for EGL_IMG_context_priority and values: + + "3.7.1.7 Context Priority + + The attribute EGL_CONTEXT_PRIORITY_LEVEL_IMG specifies a context + priority hint for a context supporting context priority. This + attribute's value may be one of EGL_CONTEXT_PRIORITY_HIGH_IMG, + EGL_CONTEXT_PRIORITY_MEDIUM_IMG, EGL_CONTEXT_PRIORITY_LOW_IMG, + or EGL_CONTEXT_PRIORITY_REALTIME_NV. The default value for + EGL_CONTEXT_PRIORITY_LEVEL_IMG is EGL_CONTEXT_PRIORITY_MEDIUM_IMG. + + This attribute is a hint, as an implementation may not support + multiple contexts at some priority levels and system policy may limit + access to high priority contexts to appropriate system privilege + level. + + The value EGL_CONTEXT_PRIORITY_REALTIME_NV requests the created + context run at the highest possible priority and be capable of + preempting the current executing context when commands are flushed + by such a realtime context. + + This attribute is supported only for OpenGL and OpenGL ES contexts." + + Within section 3.7.4 "Context Queries" amend the eglQueryContext + discussion as follows: + + Change the sentence describing the attribute parameter to include + EGL_CONTEXT_PRIORITY_LEVEL_IMG so it reads: + + "attribute must be set to EGL_CONFIG_ID, EGL_CONTEXT_CLIENT_TYPE, + EGL_CONTEXT_CLIENT_VERSION, EGL_RENDER_BUFFER, or + EGL_CONTEXT_PRIORITY_LEVEL_IMG." + + After the discussion of "Querying EGL_RENDER_BUFFER", add: + + "Querying EGL_CONTEXT_PRIORITY_LEVEL_IMG returns the priority this + context was actually created with. Note: this may not be the same + as specified at context creation time, due to implementation limits + on the number of contexts that can be created at a specific priority + level in the system." + +Issues + + 1) The EGL_IMG_context_priority extension is written to amend the EGL + 1.4 specification. Should this extension amend EGL 1.5 or 1.4? + + RESOLVED: EGL 1.5 because it is newer and better organized to + extend context attributes. + + EGL 1.5 rewrites 3.7.1 "Creating Rendering Contexts" to have subsections + for different context attributes. This extension adds a new such section + that includes the EGL_IMG_context_priority attribute and values too. + + 2) Is context priority hint supported for both OpenGL and OpenGL ES contexts? + + RESOLVED: Yes. + + 3) What is the intended application of the realtime priority level? + + RESOLVED: One anticipated application is the system compositor + for a Head Mounted Display (HMD) requires realtime recomposition + for time-warping. + + 4) What action causes a context with realtime priority to preempt + other contexts? + + RESOLVED: Preemption by a context with realtime priority should + occur when there are pending rendering commands and an implicit or + explicit flush (i.e. glFlush or glFinish) occurs. + + 5) What does "trusted" or "appropriate system privilege level" + mean in practice for a Linux-based operating system such as Android? + + RESOLVED: Trusted means an application that has higher privileges + than other apps such as having CAP_SYS_NICE capability. On Android + such applications have to be registered in advance with the OS; + unpriviledged third party app cannot acquire this capability. + + This restriction exists so arbitrary applications do not starve or + otherwise compromise the interactivity of the system overall. + + 6) In practice how many realtime priority contexts can exist in a system to + get best performance? + + RESOLVED: Only one realtime priority context should be active at a given + moment to get best performance. + + 7) Can a context created with a realtime priority hint that is + in fact given a realtime priority, subsequently find that realtime + priority revoked and, if revoked, can it be restored? + + RESOLVED: No, once a context is created with specific priority level, the + priority will not change for lifetime of the context. This means there will + not be revoking or restoring of realtime priority to already created context. + + 8) The attrib_list for eglCreateContext could list the attribute + EGL_CONTEXT_PRIORITY_LEVEL_IMG multiple times with different valid values. + What happens in this case? + + RESOLVED: Behavior is undefined in this case. + + NVIDIA's EGL implementation handles such case by using the last (valid) attribute + value listed in the attrib_list array as the effective attribute value for + creating the context. + + The EGL specification is unfortunately silent on this issue. + + +Revision History + Version 1, 2016/11/23 (Sandeep Shinde) + - Initial version + Version 2, 2017/10/13 (Mark Kilgard) + - Complete and convert to NV extension + Version 3, 2017/10/31 (Sandeep Shinde) + - Few minor corrections. Issue 6 resolved. + Version 4, 2017/11/21 (Sandeep Shinde) + - Update enum value and add extension number diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample.txt new file mode 100644 index 0000000..e016a6f --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample.txt @@ -0,0 +1,554 @@ +Name + + NV_coverage_sample + +Name Strings + + GL_NV_coverage_sample + EGL_NV_coverage_sample + +Contact + + Gary King, NVIDIA Corporation (gking 'at' nvidia.com) + +Notice + + Copyright NVIDIA Corporation, 2005 - 2007 + +Status + + NVIDIA Proprietary + +Version + + Last Modified Date: 2007/03/20 + NVIDIA Revision: 1.0 + +Number + + EGL Extension #17 + OpenGL ES Extension #72 + +Dependencies + + Written based on the wording of the OpenGL 2.0 specification + and the EXT_framebuffer_object specification. + + Written based on the wording of the EGL 1.2 specification. + + Requires OpenGL-ES 2.0 and OES_framebuffer_object. + + Requires EGL 1.1. + +Overview + + Anti-aliasing is a critical component for delivering high-quality + OpenGL rendering. Traditionally, OpenGL implementations have + implemented two anti-aliasing algorithms: edge anti-aliasing + and multisampling. + + Edge anti-aliasing computes fractional fragment coverage for all + primitives in a rendered frame, and blends edges of abutting + and/or overlapping primitives to produce smooth results. The + image quality produced by this approach is exceptionally high; + however, applications are render their geometry perfectly ordered + back-to-front in order to avoid artifacts such as bleed-through. + Given the algorithmic complexity and performance cost of performing + exact geometric sorts, edge anti-aliasing has been used very + sparingly, and almost never in interactive games. + + Multisampling, on the other hand, computes and stores subpixel + (a.k.a. "sample") coverage for rasterized fragments, and replicates + all post-alpha test operations (e.g., depth test, stencil test, + alpha blend) for each sample. After the entire scene is rendered, + the samples are filtered to compute the final anti-aliased image. + Because the post-alpha test operations are replicated for each sample, + all of the bleed-through and ordering artifacts that could occur with + edge anti-aliasing are avoided completely; however, since each sample + must be computed and stored separately, anti-aliasing quality is + limited by framebuffer storage and rendering performance. + + This extension introduces a new anti-aliasing algorithm to OpenGL, + which dramatically improves multisampling quality without + adversely affecting multisampling's robustness or significantly + increasing the storage required, coverage sampling. + + Coverage sampling adds an additional high-precision geometric + coverage buffer to the framebuffer, which is used to produce + high-quality filtered results (with or without the presence of a + multisample buffer). This coverage information is computed and stored + during rasterization; since applications may render objects where the + specified geometry does not correspond to the visual result (examples + include alpha-testing for "imposters," or extruded volume rendering + for stencil shadow volumes), coverage buffer updates may be masked + by the application, analagous to masking the depth buffer. + +IP Status + + NVIDIA Proprietary + +New Procedures and Functions + + void CoverageMaskNV( boolean mask ) + void CoverageOperationNV( enum operation ) + +New Tokens + + + Accepted by the <attrib_list> parameter of eglChooseConfig + and eglCreatePbufferSurface, and by the <attribute> + parameter of eglGetConfigAttrib + + EGL_COVERAGE_BUFFERS_NV 0x30E0 + EGL_COVERAGE_SAMPLES_NV 0x30E1 + + Accepted by the <internalformat> parameter of + RenderbufferStorageEXT and the <format> parameter of ReadPixels + + COVERAGE_COMPONENT_NV 0x8ED0 + + Accepted by the <internalformat> parameter of + RenderbufferStorageEXT + + COVERAGE_COMPONENT4_NV 0x8ED1 + + Accepted by the <operation> parameter of CoverageOperationNV + + COVERAGE_ALL_FRAGMENTS_NV 0x8ED5 + COVERAGE_EDGE_FRAGMENTS_NV 0x8ED6 + COVERAGE_AUTOMATIC_NV 0x8ED7 + + Accepted by the <attachment> parameter of + FramebufferRenderbuffer, and GetFramebufferAttachmentParameteriv + + COVERAGE_ATTACHMENT_NV 0x8ED2 + + Accepted by the <buf> parameter of Clear + + COVERAGE_BUFFER_BIT_NV 0x8000 + + Accepted by the <pname> parameter of GetIntegerv + + COVERAGE_BUFFERS_NV 0x8ED3 + COVERAGE_SAMPLES_NV 0x8ED4 + +Changes to Chapter 4 of the OpenGL 2.0 Specification + + Insert a new section, after Section 3.2.1 (Multisampling) + + "3.2.2 Coverage Sampling + + Coverage sampling is a mechanism to antialias all GL primitives: points, + lines, polygons, bitmaps and images. The technique is similar to + multisampling, with all primitives being sampled multiple times at each + pixel, and a sample resolve applied to compute the color values stored + in the framebuffer's color buffers. As with multisampling, coverage + sampling resolves color sample and coverage values to a single, displayable + color each time a pixel is updated, so antialiasing appears to be automatic + at the application level. Coverage sampling may be used simultaneously + with multisampling; however, this is not required. + + An additional buffer, called the coverage buffer, is added to + the framebuffer. This buffer stores additional coverage information + that may be used to produce higher-quality antialiasing than what is + provided by conventional multisampling. + + When the framebuffer includes a multisample buffer (3.5.6), the + samples contain this coverage information, and the framebuffer + does not include the coverage buffer. + + If the value of COVERAGE_BUFFERS_NV is one, the rasterization of + all primitives is changed, and is referred to as coverage sample + rasterization. Otherwise, primitive rasterization is referred to + as multisample rasterization (if SAMPLE_BUFFERS is one) or + single-sample rasterization (otherwise). The value of + COVERAGE_BUFFERS_NV is queried by calling GetIntegerv with <pname> + set to COVERAGE_BUFFERS_NV. + + During coverage sample rasterization the pixel fragment contents + are modified to include COVERAGE_SAMPLES_NV coverage values. The + value of COVERAGE_SAMPLES_NV is an implementation-dependent + constant, and is queried by calling GetIntegerv with <pname> set + to COVERAGE_SAMPLES_NV. + + The command + + CoverageOperationNV(enum operation) + + may be used to modify the manner in which coverage sampling is + performed for all primitives. If <operation> is + COVERAGE_ALL_FRAGMENTS_NV, coverage sampling will be performed and the + coverage buffer updated for all fragments generated during rasterization. + If <operation> is COVERAGE_EDGE_FRAGMENTS_NV, coverage sampling will + only be performed for fragments generated at the edge of the + primitive (by only updating fragments at the edges of primitives, + applications may get better visual results when rendering partially + transparent objects). If <operation> is COVERAGE_AUTOMATIC_NV, + the GL will automatically select the appropriate coverage operation, + dependent on the GL blend mode and the use of gl_LastFragColor / + gl_LastFragData in the bound fragment program. If blending is enabled, + or gl_LastFragColor / gl_LastFragData appears in the bound fragment + program, COVERAGE_AUTOMATIC_NV will behave identically to + COVERAGE_EDGE_FRAGMENTS_NV; otherwise, COVERAGE_AUTOMATIC_NV will behave + identically to COVERAGE_ALL_FRAGMENTS_NV. The default coverage operation + is COVERAGE_AUTOMATIC_NV." + + Insert a new section, after Section 3.3.3 (Point Multisample + Rasterization) + + "3.3.4 Point Coverage Sample Rasterization + + If the value of COVERAGE_BUFFERS_NV is one, then points are + rasterized using the following algorithm, regardless of whether + point antialiasing (POINT_SMOOTH) is enabled or disabled. Point + rasterization produces fragments using the same algorithm described + in section 3.3.3; however, sample points are divided into SAMPLES + multisample points and COVERAGE_SAMPLES_NV coverage sample points. + + Rasterization for multisample points uses the algorithm described + in section 3.3.3. Rasterization for coverage sample points uses + implementation-dependent algorithms, ultimately storing the results + in the coverage buffer." + + Insert a new section, after Section 3.4.4 (Line Multisample + Rasterization) + + "3.4.5 Line Coverage Sample Rasterization + + If the value of COVERAGE_BUFFERS_NV is one, then lines are + rasterized using the following algorithm, regardless of whether + line antialiasing (LINE_SMOOTH) is enabled or disabled. Line + rasterization produces fragments using the same algorithm described + in section 3.4.4; however, sample points are divided into SAMPLES + multisample points and COVERAGE_SAMPLES_NV coverage sample points. + + Rasterization for multisample points uses the algorithm described in + section 3.4.4. Rasterization for coverage sample points uses + implementation-dependent algorithms, ultimately storing results in + the coverage buffer." + + Insert a new section, after Section 3.5.6 (Polygon Multisample + Rasterization) + + "3.5.7 Polygon Coverage Sample Rasterization + + If the value of COVERAGE_BUFFERS_NV is one, then polygons are + rasterized using the following algorithm, regardless of whether + polygon antialiasing (POLYGON_SMOOTH) is enabled or disabled. Polygon + rasterization produces fragments using the same algorithm described in + section 3.5.6; however, sample points are divided into SAMPLES multisample + points and COVERAGE_SAMPLES_NV coverage sample points. + + Rasterization for multisample points uses the algorithm described in + section 3.5.7. Rasterization for coverage sample points uses + implementation-dependent algorithms, ultimately storing results in the + coverage buffer." + + Insert a new section, after Section 3.6.6 (Pixel Rectangle Multisample + Rasterization) + + "3.6.7 Pixel Rectangle Coverage Sample Rasterization + + If the value of COVERAGE_BUFFERS_NV is one, then pixel rectangles are + rasterized using the algorithm described in section 3.6.6." + + Modify the first sentence of the second-to-last paragraph of section + 3.7 (Bitmaps) to read: + + "Bitmap Multisample and Coverage Sample Rasterization + + If MULTISAMPLE is enabled, and the value of SAMPLE_BUFFERS is one; + or if the value of COVERAGE_BUFFERS_NV is one, then bitmaps are + rasterized using the following algorithm. [...]" + + Insert after the first paragraph of Section 4.2.2 (Fine Control of + Buffer Updates): + + "The coverage buffer can be enabled or disabled for writing coverage + sample values using + + void CoverageMaskNV( boolean mask ); + + If <mask> is non-zero, the coverage buffer is enabled for writing; + otherwise, it is disabled. In the initial state, the coverage + buffer is enabled for writing." + + And change the text of the last 2 paragraphs of Section 4.2.2 to read: + + "The state required for the various masking operations is three + integers and two bits: an integer for color indices, an integer for + the front and back stencil values, a bit for depth values, and a + bit for coverage sample values. A set of four bits is also required + indicating which components of an RGBA value should be written. In the + initial state, the integer masks are all ones, as are the bits + controlling the depth value, coverage sample value and RGBA component + writing. + + Fine Control of Multisample Buffer Updates + + When the value of SAMPLE_BUFFERS is one, ColorMask, DepthMask, + CoverageMask, and StencilMask or StencilMaskSeparate control the + modification of values in the multisample buffer. [...]" + + Change paragraph 2 of Section 4.2.3 (Clearing the Buffers) to read: + + "is the bitwise OR of a number of values indicating which buffers are to + be cleared. The values are COLOR_BUFFER_BIT, DEPTH_BUFFER_BIT, + STENCIL_BUFFER_BIT, ACCUM_BUFFER_BIT and COVERAGE_BUFFER_BIT_NV, indicating + the buffers currently enabled for color writing, the depth buffer, + the stencil buffer, the accumulation buffer and the virtual-coverage + buffer, respectively. [...]" + + Insert a new paragraph after paragraph 4 of Section 4.3.2 (Reading Pixels) + (beginning with "If there is a multisample buffer ..."): + + "If the <format> is COVERAGE_COMPONENT_NV, then values are taken from the + coverage buffer; again, if there is no coverage buffer, the error + INVALID_OPERATION occurs. When <format> is COVERAGE_COMPONENT_NV, + <type> must be GL_UNSIGNED_BYTE. Any other value for <type> will + generate the error INVALID_ENUM. If there is a multisample buffer, the + values are undefined." + + + +Modifications to the OES_framebuffer_object specification + + Add a new table at the end of Section 4.4.2.1 (Renderbuffer Objects) + + "+-------------------------+-----------------------+-----------+ + | Sized internal format | Base Internal Format | C Samples | + +-------------------------+-----------------------+-----------+ + | COVERAGE_COMPONENT4_NV | COVERAGE_COMPONENT_NV | 4 | + +-------------------------+-----------------------+-----------+ + Table 1.ooo Desired component resolution for each sized internal + format that can be used only with renderbuffers" + + Add to the bullet list in Section 4.4.4 (Framebuffer Completeness) + + "An internal format is 'coverage-renderable' if it is COVERAGE_COMPONENT_NV + or one of the COVERAGE_COMPONENT_NV formats from table 1.ooo. No other + formats are coverage-renderable" + + Add to the bullet list in Section 4.4.4.1 (Framebuffer Attachment + Completeness) + + "If <attachment> is COVERAGE_ATTACHMENT_NV, then <image> must have a + coverage-renderable internal format." + + Add a paragraph at the end of Section 4.4.4.2 (Framebuffer Completeness) + + "The values of COVERAGE_BUFFERS_NV and COVERAGE_SAMPLES_NV are derived from + the attachments of the currently bound framebuffer object. If the current + FRAMEBUFFER_BINDING_OES is not 'framebuffer-complete', then both + COVERAGE_BUFFERS_NV and COVERAGE_SAMPLES_NV are undefined. Otherwise, + COVERAGE_SAMPLES_NV is equal to the number of coverage samples for the + image attached to COVERAGE_ATTACHMENT_NV, or zero if COVERAGE_ATTACHMENT_NV + is zero." + +Additions to the EGL 1.2 Specification + + Add to Table 3.1 (EGLConfig attributes) + +---------------------------+---------+-----------------------------------+ + | Attribute | Type | Notes | + +---------------------------+---------+-----------------------------------+ + | EGL_COVERAGE_BUFFERS_NV | integer | number of coverage buffers | + | EGL_COVERAGE_SAMPLES_NV | integer | number of coverage samples per | + | | | pixel | + +---------------------------+---------+-----------------------------------+ + + Modify the first sentence of the last paragraph of the "Buffer + Descriptions and Attributes" subsection of Section 3.4 (Configuration + Management), p. 16 + + "There are no single-sample depth, stencil or coverage buffers for a + multisample EGLConfig; the only depth, stencil and coverage buffers are + those in the multisample buffer. [...]" + + And add the following text at the end of that paragraph: + + "The <coverage buffer> is used only by OpenGL ES. It contains primitive + coverage information that is used to produce a high-quality anti-aliased + image. The format of the coverage buffer is not specified, and its + contents are not directly accessible. Only the existence of the coverage + buffer, and the number of coverage samples it contains, are exposed by EGL. + + EGL_COVERAGE_BUFFERS_NV indicates the number of coverage buffers, which + must be zero or one. EGL_COVERAGE_SAMPLES_NV gives the number of coverage + samples per pixel; if EGL_COVERAGE_BUFFERS_NV is zero, then + EGL_COVERAGE_SAMPLES_NV will also be zero." + + Add to Table 3.4 (Default values and match criteria for EGLConfig + attributes) + + +---------------------------+-----------+-------------+---------+---------+ + | Attribute | Default | Selection | Sort | Sort | + | | | Criteria | Order | Priority| + +---------------------------+-----------+-------------+---------+---------+ + | EGL_COVERAGE_BUFFERS_NV | 0 | At Least | Smaller | 7 | + | EGL_COVERAGE_SAMPLES_NV | 0 | At Least | Smaller | 8 | + +---------------------------+-----------+-------------+---------+---------+ + And renumber existing sort priorities 7-11 as 9-13. + + Modify the list in "Sorting of EGLConfigs" (Section 3.4.1, pg 20) + + " [...] + 5. Smaller EGL_SAMPLE_BUFFERS + 6. Smaller EGL_SAMPLES + 7. Smaller EGL_COVERAGE_BUFFERS_NV + 8. Smaller EGL_COVERAGE_SAMPLES_NV + 9. Smaller EGL_DEPTH_SIZE + 10. Smaller EGL_STENCIL_SIZE + 11. Smaller EGL_ALPHA_MASK_SIZE + 12. Special: [...] + 13. Smaller EGL_CONFIG_ID [...]" + +Usage Examples + + (1) Basic Coverage Sample Rasterization + + glCoverageMaskNV(GL_TRUE); + glDepthMask(GL_TRUE); + glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); + + while (1) + { + glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | + GL_COVERAGE_BUFFER_BIT_NV); + glDrawElements(...); + eglSwapBuffers(...); + } + + (2) Multi-Pass Rendering Algorithms + + while (1) + { + glDepthMask(GL_TRUE); + glCoverageMaskNV(GL_TRUE); + glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); + glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | + GL_COVERAGE_BUFFER_BIT_NV); + + // first render pass: render Z-only (occlusion surface), with + // coverage info. color writes are disabled + + glCoverageMaskNV(GL_TRUE); + glDepthMask(GL_TRUE); + glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE); + glDepthFunc(GL_LESS); + glDrawElements(...); + + // second render pass: set Z test to Z-equals, disable Z-writes & + // coverage writes. enable color writes. coverage may be + // disabled, because subsequent rendering passes are rendering + // identical geometry -- since the final coverage buffer will be + // unchanged, we can disable coverage writes as an optimization. + + glCoverageMaskNV(GL_FALSE); + glDepthMask(GL_FALSE); + glDepthFunc(GL_EQUAL); + glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); + glDrawElements(...); + + eglSwapBuffers(); + } + + (3) Rendering Translucent Objects on Top of Opaque Objects + + while (1) + { + glDepthMask(GL_TRUE); + glCoverageMaskNV(GL_TRUE); + glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); + glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | + GL_COVERAGE_BUFFER_BIT_NV); + + // render opaque, Z-buffered geometry with coverage info for the + // entire primitive. Overwrite coverage data for all fragments, so + // that interior fragments do not get resolved incorrectly. + + glDepthFunc(GL_LESS); + glCoverageOperationNV(GL_COVERAGE_ALL_FRAGMENTS_NV); + glDrawElements(...); + + // render translucent, Z-buffered geometry. to ensure that visible + // edges of opaque geometry remain anti-aliased, change the + // coverage operation to just edge fragments. this will maintain + // the coverage information underneath the translucent geometry, + // except at translucent edges. + + glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); + glCoverageOperationNV(GL_COVERAGE_EDGE_FRAGMENTS_NV); + glEnable(GL_BLEND); + glDrawElements(...); + glDisable(GL_BLEND); + + eglSwapBuffers(); + } + + (4) Rendering Opacity-Mapped Particle Systems & HUDs on Top of Opaque + Geometry + + while (1) + { + glDepthMask(GL_TRUE); + glCoverageMaskNV(GL_TRUE); + glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE); + glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | + GL_COVERAGE_BUFFER_BIT_NV); + + // render opaque, Z-buffered geometry, with coverage info. + glDepthFunc(GL_LESS); + glDrawElements(...); + + // render opacity-mapped geometry. disable Z writes, enable alpha + // blending. also, disable coverage writes -- the edges of the + // geometry used for the HUD/particle system have alpha values + // tapering to zero, so edge coverage is uninteresting, and + // interior coverage should still refer to the underlying opaque + // geometry, so that opaque edges visible through the translucent + // regions remain anti-aliased. + + glCoverageMaskNV(GL_FALSE); + glDepthMask(GL_FALSE); + glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); + glEnable(GL_BLEND); + glDrawElements(...); + glDisable(GL_BLEND); + + eglSwapBuffers(); + } + + +Issues + + 1. Is any specific discussion of coverage sampling resolves required, + particularly with respect to application-provided framebuffer objects? + + RESOLVED: No. Because the coverage sampling resolve is an + implementation-dependent algorithm, it is always legal behavior for + framebuffer read / copy functions to return the value in the selected + ReadBuffer as if COVERAGE_BUFFERS_NV was zero. This allows + textures attached to the color attachment points of framebuffer objects + to behave predictably, even when COVERAGE_BUFFERS_NV is one. + + Implementations are encouraged, whenever possible, to use the highest- + quality coverage sample resolve supported for calls to eglSwapBuffers, + eglCopyBuffers, ReadPixels, CopyPixels and CopyTex{Sub}Image. + + 2. Should all render buffer & texture types be legal sources for image + resolves and coverage attachment? + + RESOLVED: This spec should not place any arbitrary limits on usage; + however, there are many reasons why implementers may not wish to + support coverage sampling for all surface types. + + Implementations may return FRAMEBUFFER_UNSUPPORTED_OES from + CheckFramebufferStatusOES if an object bound to COVERAGE_ATTACHMENT_NV + is incompatible with one or more objects bound to DEPTH_ATTACHMENT_OES, + STENCIL_ATTACHMENT_OES, or COLOR_ATTACHMENTi_OES. + +Revision History + +#1.0 - 20.03.2007 + + Renumbered enumerants. Reformatted to 80 columns. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample_resolve.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample_resolve.txt new file mode 100644 index 0000000..fa5cc15 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_coverage_sample_resolve.txt @@ -0,0 +1,127 @@ +Name + + NV_coverage_sample_resolve + +Name Strings + + EGL_NV_coverage_sample_resolve + +Contact + + James Jones, NVIDIA Corporation (jajones 'at' nvidia.com) + +Notice + + Copyright NVIDIA Corporation, 2011 + +Status + + NVIDIA Proprietary + +Version + + Last Modified Date: 2011/04/13 + NVIDIA Revision: 1.0 + +Number + + EGL Extension #30 + +Dependencies + + Written based on the wording of the EGL 1.4 specification. + + Trivially interacts with EGL_NV_coverage_sample + + Requires EGL 1.2. + +Overview + + NV_coverage_sample introduced a method to improve rendering quality + using a separate buffer to store coverage information for pixels in + the color buffers. It also provided a mechanism to disable writing + to the coverage buffer when coverage sample filtering was not needed + or undesirable. However, it did not provide a way to disable + reading data from the coverage buffer at resolve time. In some + cases performance can be improved by eliminating these memory reads. + To that end, this extension exposes a surface attribute that allows + applications to specify when no coverage sample resolve is desired. + +IP Status + + NVIDIA Proprietary + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + Accepted by the <attribute> parameter of eglSurfaceAttrib and + eglQuerySurface: + + EGL_COVERAGE_SAMPLE_RESOLVE_NV 0x3131 + + Accepted by the <value> parameter of eglSurfaceAttrib and returned + in the <value> parameter of eglQuerySurface when <attribute> is + EGL_COVERAGE_SAMPLE_RESOLVE_NV: + + EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV 0x3132 + EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV 0x3133 + +Additions to Chapter 3 of the EGL 1.4 Specification (EGL Functions and +Errors) + + Additions to section 3.5.6 (Surface Attributes) + + Replace the last sentence of paragraph 2 (p. 35): + + "Attributes that can be specified are + EGL_COVERAGE_SAMPLE_RESOLVE_NV, EGL_MIPMAP_LEVEL, + EGL_MULTISAMPLE_RESOLVE, and EGL_SWAP_BEHAVIOR." + + Add the following paragraphs between paragraphs 2 and 3 (p. 35): + + "If <attribute> is EGL_COVERAGE_SAMPLE_RESOLVE_NV, then <value> + specifies the filter to use when resolving the coverage sample + buffer. A <value> of EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV chooses + the default implementation-defined filtering method, while + EGL_MULTISAMPLE_RESOLVE_NONE_NV disables filtering based on coverage + data. + + "The initial value of EGL_COVERAGE_SAMPLE_RESOLVE_NV is + EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV." + + Add the following paragraph after paragraph 13 (p. 36): + + "Querying EGL_COVERAGE_SAMPLE_RESOLVE_NV returns the filtering + method used when performing coverage buffer resolution. The filter + may be either EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV or + EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV, as described above for + eglSurfaceAttrib." + +Interactions with EGL_NV_coverage_sample: + + This extension relies on language in EGL_NV_coverage_sample to + describe the coverage sample buffer. + + If EGL_NV_coverage_sample is not present, this extension has no + effect on rendering. + +Issues + + 1. Should it be an error to set EGL_COVERAGE_SAMPLE_RESOLVE_NV on + surfaces that don't have a coverage buffer? + + RESOLVED: No. EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV will behave + the same as EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV in this case. + +Revision History + +#1 (James Jones, 2011-04-13) + + - Initial revision. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_cuda_event.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_cuda_event.txt new file mode 100644 index 0000000..cc54749 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_cuda_event.txt @@ -0,0 +1,206 @@ +Name + + NV_cuda_event + +Name Strings + + EGL_NV_cuda_event + +Contributors + + Debalina Bhattacharjee + Michael Chock + James Jones + Daniel Kartch + +Contact + + Michael Chock (mchock 'at' nvidia.com) + +Status + + Complete + +Version + + Version 2, June 28, 2018 + +Number + + EGL Extension #75 + +Extension Type + + EGL display extension + +Dependencies + + This extension is written against the language of EGL 1.5 and the + EGL_EXT_sync_reuse extension. + + Either EGL_KHR_fence_sync and the EGLAttrib type or EGL 1.5 are + required. + + This extension interacts with, but does not require, + EGL_EXT_sync_reuse. + + This extension interacts with EGL_NV_device_cuda. + +Overview + + This extension allows creating an EGL sync object linked to a CUDA + event object, potentially improving efficiency of sharing images and + compute results between the two APIs. + +IP Status + + No known claims. + +New Types + + A pointer to type cudaEvent_t, defined in the CUDA header files, may + be included in the attribute list passed to eglCreateSync. + +New Procedures and Functions + + None. + +New Tokens + + Accepted as attribute names in the <attrib_list> argument + of eglCreateSync: + + EGL_CUDA_EVENT_HANDLE_NV 0x323B + + Returned in <values> for eglGetSyncAttrib <attribute> + EGL_SYNC_TYPE: + + EGL_SYNC_CUDA_EVENT_NV 0x323C + + Returned in <values> for eglGetSyncAttrib <attribute> + EGL_SYNC_CONDITION: + + EGL_SYNC_CUDA_EVENT_COMPLETE_NV 0x323D + +Add to section 3.8.1 (Sync Objects) of the EGL 1.5 specification, after +the sixth paragraph: + + Likewise, a <CUDA event sync object> reflects the status of a + corresponding CUDA object. Waiting on this type of sync object is + equivalent to waiting for completion of the corresponding linked + CUDA event object. + +Add a new section following section 3.8.1.2 (Creating and Signaling +OpenCL Event Sync Objects): + + Section 3.8.1.X Creating and Signaling CUDA Event Sync Objects + + If <type> is EGL_SYNC_CUDA_EVENT_NV, a CUDA event sync object is + created. The <attrib_list> may contain the attribute + EGL_CUDA_EVENT_HANDLE_NV, set to a pointer to a cudaEvent_t object. + If it does not contain this attribute, the sync object will start in + the signaled state, and an event attribute must be provided the + first time eglUnsignalSyncEXT is called. Otherwise, a call to + eglUnsignalSyncEXT may replace this event attribute or leave it + unspecified, causing the previous object to be reused. + + A cudaEvent_t object provided to eglCreateSync or eglUnsignalSyncEXT + must be properly initialized and recorded by the CUDA API (using + cudaEventCreate and cudaEventRecord), and the CUDA device + used to create the event must correspond to <dpy>[fn1]. Note that + EGL_CUDA_EVENT_HANDLE_NV is not a queryable property of a sync + object. + + [fn1] If EGL_NV_device_cuda is supported, it is sufficient that the + CUDA device used to create the CUDA event matches the + EGL_CUDA_DEVICE_NV attribute of <dpy>'s underlying EGL + device. + + Attributes of the CUDA event sync object are set as follows: + + Attribute Name Initial Attribute Value(s) + ------------- -------------------------- + EGL_SYNC_TYPE EGL_SYNC_CUDA_EVENT_NV + EGL_SYNC_STATUS Depends on status of <event> + EGL_SYNC_CONDITION EGL_SYNC_CUDA_EVENT_COMPLETE_NV + + If an <event> is linked to the sync object, the status of this type + of sync object depends on the state of <event> evaluated at the time + of the most recent call to eglCreateSync or eglUnsignalSyncEXT. If + all device work preceding the most recent call to cudaEventRecord on + the event has not yet completed, the status of the linked sync + object will be EGL_UNSIGNALED. If all such work has completed, the + status of the linked sync object will be EGL_SIGNALED. Calling + cudaEventRecord to modify an event has no effect on the sync object + while its status is EGL_UNSIGNALED, but will have an effect if the + event is reevaluated at a subsequent eglUnsignalSyncEXT call. + + The only condition supported for CUDA event sync objects is + EGL_SYNC_CUDA_EVENT_COMPLETE_NV. It is satisfied when all device + work prior to the most recent call to cudaEventRecord at sync + unsignaling time has completed. + +If EGL_EXT_sync_reuse is not present, then change the second sentence of +3.8.1.X above to "The <attrib_list> must contain ..." and omit the +remaining sentences in the paragraph. Omit all references to +eglUnsignalSyncEXT. + +In 3.8.1 (Sync Objects), if EGL_EXT_sync_reuse is present, then add the +following to the error list for eglUnsignalSyncEXT. Otherwise add it to +the error list for eglCreateSync: + + If <type> is EGL_SYNC_CUDA_EVENT_NV and a EGL_CUDA_EVENT_HANDLE_NV + is not linked to the sync object, then an EGL_BAD_ATTRIBUTE error is + generated. If its attribute value is not a valid CUDA event pointer + or has not been initialized as described above, then + EGL_BAD_ATTRIBUTE may be generated, but the results are undefined + and may include program termination. + +Modify the third paragraph of section 3.8.1.4 (Querying Sync Object +Attributes): + + If any eglClientWaitSync or eglWaitSync commands are blocking on + <sync> when eglDestroySync is called, <sync> is flagged for deletion + and will be deleted when the associated fence command, OpenCL event + object, or CUDA event object has completed, and <sync> is no longer + blocking any such egl*WaitSync command. Otherwise, the sync object + is destroyed immediately. + +Replace the EGL_SYNC_CONDITION row of table 3.9 with: + + Attribute Description Supported Sync Objects + ------------------ ----------------------- ---------------------- + EGL_SYNC_CONDITION Signaling condition EGL_SYNC_FENCE, + EGL_SYNC_CL_EVENT, or + EGL_SYNC_CUDA_EVENT_NV + + Table 3.9 Attributes Accepted by eglGetSyncAttrib + + +Interactions with EGL versions prior to 1.5 + + This extension may be used with earlier versions of EGL, provided + that the EGL_KHR_fence_sync extension is supported. In this case, + replace all references to sync functions and tokens with + corresponding KHR-suffixed versions (e.g., replace eglCreateSync + with eglCreateSyncKHR). + + Additionally, this extension may be used with the 64-bit types and + functions added to EGL_KHR_fence_sync introduced by + EGL_KHR_cl_event2 (EGLAttribKHR and eglCreateSync64KHR). Support + for OpenCL events is not required. + +Issues + + None + +Revision History + + Version 2, 2018/06/28 (Daniel Kartch) + - Rewritten to clearly define interactions with + EGL_EXT_sync_reuse, without requiring it + - Fixed incorrect CUDA function name + - Fixed table spacing + + Version 1, 2014/06/20 (Michael Chock) + - initial version. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_depth_nonlinear.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_depth_nonlinear.txt new file mode 100644 index 0000000..b46b3ca --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_depth_nonlinear.txt @@ -0,0 +1,142 @@ +Name + + NV_depth_nonlinear + +Name Strings + + GL_NV_depth_nonlinear + EGL_NV_depth_nonlinear + +Contact + + Gary King, NVIDIA Corporation (gking 'at' nvidia.com) + +Notice + + Copyright NVIDIA Corporation, 2005 - 2007. + +Status + + NVIDIA Proprietary + +Version + + Last Modified: 2007/03/20 + NVIDIA Revision: 1.0 + +Number + + EGL Extension #18 + OpenGL ES Extension #73 + +Dependencies + + Written based on the wording of the OpenGL 2.0 Specification and + EGL 1.2 Specification. + + Requires EGL 1.1. + + Requires OpenGL-ES 1.0. + + OES_framebuffer_object affects the wording of this specification. + +Overview + + Due to the perspective divide, conventional integer Z-buffers have + a hyperbolic distribution of encodings between the near plane + and the far plane. This can result in inaccurate depth testing, + particularly when the number of depth buffer bits is small + and objects are rendered near the far plane. + + Particularly when the number of depth buffer bits is limited + (desirable and/or required in low-memory environments), artifacts + due to this loss of precision may occur even with relatively + modest far plane-to-near plane ratios (e.g., greater than 100:1). + + Many attempts have been made to provide alternate encodings for + Z-buffer (or alternate formulations for the stored depth) to + reduce the artifacts caused by perspective division, such as + W-buffers, Z-complement buffers and floating-point 1-Z buffers. + + This extension adds a non-linear encoded Z buffer to OpenGL, + which can improve the practically useful range of, e.g. 16-bit + depth buffers by up to a factor of 16, greatly improving depth + test quality in applications where the ratio between the near + and far planes can not be as tightly controlled. + +IP Status + + NVIDIA Proprietary + +New Procedures and Functions + + None + +New Tokens + + Accepted as a valid sized internal format by all functions accepting + sized internal formats with a base format of DEPTH_COMPONENT + + DEPTH_COMPONENT16_NONLINEAR_NV 0x8E2C + + Accepted by the <attrib_list> parameter of eglChooseConfig and + eglCreatePbufferSurface, and by the <attribute> parameter of + eglGetConfigAttrib + + EGL_DEPTH_ENCODING_NV 0x30E2 + + Accepted as a value in the <attrib_list> parameter of eglChooseConfig + and eglCreatePbufferSurface, and returned in the <value> parameter + of eglGetConfigAttrib + + EGL_DEPTH_ENCODING_NONE_NV 0 + EGL_DEPTH_ENCODING_NONLINEAR_NV 0x30E3 + +Changes to the OpenGL 2.0 Specification + + Add the following line to table 3.16 (p. 154) + + +--------------------------------+-----------------+------+ + | Sized Internal Format | Base Internal | D | + | | Format | Bits | + +--------------------------------+-----------------+------+ + | DEPTH_COMPONENT16_NONLINEAR_NV | DEPTH_COMPONENT | 16 | + +--------------------------------+-----------------+------+ + +Changes to the EGL 1.2 Specification + + Add the following line to table 3.1 (p. 14) + + +--------------------------+------+---------------------------------------+ + | Attribute | Type | Notes | + +--------------------------+------+---------------------------------------+ + | EGL_DEPTH_ENCODING_NV | enum | Type of depth-buffer encoding employed| + +--------------------------+------+---------------------------------------+ + + Modify the description of the depth buffer in Section 3.4 (p. 15) + + "The depth buffer is used only by OpenGL ES. It contains fragment depth + (Z) information generated during rasterization. EGL_DEPTH_SIZE indicates + the depth of this buffer in bits, and EGL_DEPTH_ENCODING_NV indicates which + alternate depth-buffer encoding (if any) should be used. Legal values for + EGL_DEPTH_ENCODING_NV are: EGL_DONT_CARE, EGL_DEPTH_ENCODING_NONE_NV and + EGL_DEPTH_ENCODING_NONLINEAR_NV." + + Add the following line to table 3.4 (p. 20) + + +-----------------------+---------------+-----------+-------+----------+ + | Attribute | Default | Selection | Sort | Sort | + | | | Criteria | Order | Priority | + +-----------------------+---------------+-----------+-------+----------+ + | EGL_DEPTH_ENCODING_NV | EGL_DONT_CARE | Exact | None | - | + +-----------------------+---------------+-------------------+----------+ + +Issues + + None + +Revision History + +#1.0 - 20.03.2007 + + Renumbered enumerants. Reformatted to 80 columns. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_device_cuda.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_device_cuda.txt new file mode 100644 index 0000000..1fdc5d6 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_device_cuda.txt @@ -0,0 +1,91 @@ +Name + + NV_device_cuda + +Name Strings + + EGL_NV_device_cuda + +Contributors + + Michael Chock + James Jones + +Contact + + Michael Chock (mchock 'at' nvidia.com) + +Status + + Complete + +Version + + Version 1, June 21, 2014 + +Number + + EGL Extension #74 + +Extension Type + + EGL device extension + +Dependencies + + This extension is written against the language of EGL 1.5 as + modified by EGL_EXT_device_base. + + EGL_EXT_device_base is required. + +Overview + + EGL and CUDA both have the capability to drive multiple devices, + such as GPUs, within a single system. To interoperate with one + another, both APIs must have compatible notions of such devices. + This extension defines a mapping from an EGL device to a CUDA device + enumerant. + +IP Status + + No known claims. + +New Types + + None. + +New Procedures and Functions + + None. + +New Tokens + + Accepted as a queried <attribute> in eglQueryDeviceAttribEXT: + + EGL_CUDA_DEVICE_NV 0x323A + +Add a new section 2.1.3 (CUDA Devices) after 2.1.2 (Devices) + + "Somewhat analogous to an EGL device, a CUDA device establishes a + namespace for CUDA operations. In the CUDA API, such a device is + represented by a C int. For more details, see the CUDA + documentation." + +Changes to section 3.2 (Device Enumeration) + + Replace the paragraph immediately following the prototype for + eglQueryDeviceAttribEXT: + + "The only valid value of <attribute> is EGL_CUDA_DEVICE_NV. On + success, EGL_TRUE is returned, and a valid CUDA device handle + corresponding to the EGL device is returned in <value>. This handle + is compatible with CUDA API functions." + +Issues + + None + +Revision History + + Version 1, 2014/06/24 (Michael Chock) + - initial version. diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_n_buffer.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_n_buffer.txt new file mode 100644 index 0000000..9004652 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_n_buffer.txt @@ -0,0 +1,157 @@ +Name + + NV_triple_buffer + NV_quadruple_buffer + +Name Strings + + EGL_NV_triple_buffer + EGL_NV_quadruple_buffer + +Contributors + + Daniel Kartch, NVIDIA Corporation + Tom McReynolds, NVIDIA Corporation + Santanu Thangaraj, NVIDIA Corporation + +Contact + + Daniel Kartch, NVIDIA Corporation (dkartch 'at' nvidia.com) + +Status + + Complete. + +Version + + Version 1 - February 28, 2019 + +Number + + 133 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL 1.0 + + This extension is written against the wording of the EGL 1.3 + Specification. + +Overview + + NV_triple_buffer and NV_quadruple_buffer allow applications to + request additional back buffers, in order to produce greater and + less variable frame rates. + + This document describes two related extensions, one dependent on + the other. Implementations may choose to support only + NV_triple_buffer and not NV_quadruple_buffer, but not vice versa. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + Added by NV_triple_buffer: + + Accepted as a value for EGL_RENDER_BUFFER in the <attrib_list> + parameter of eglCreateWindowSurface: + + EGL_TRIPLE_BUFFER_NV 0x3230 + + Added by NV_quadruple_buffer: + + Accepted as a value for EGL_RENDER_BUFFER in the <attrib_list> + parameter of eglCreateWindowSurface: + + EGL_QUADRUPLE_BUFFER_NV 0x3231 + +Additions to the EGL 1.3 Specification: + + Insert after third sentence of second paragraph of Section 2.2.2 + (Rendering Models): + + Windows may have more than one back buffer, allowing rendering + of a new frame to proceed while the copy requested by + eglSwapBuffers is still pending. + + Replace the third sentence of the EGL_RENDER_BUFFER description in + Section 3.5.1 (Creating On-Screen Rendering Surfaces): + + If its value is EGL_BACK_BUFFER, EGL_TRIPLE_BUFFER_NV, or + EGL_QUADRUPLE_BUFFER_NV, then client APIs should render into + the current back buffer. The implementation should provide + at least one, two, or three back buffers, respectively, which + will be used in rotation each frame. + + Change first sentence of third bullet point of eglQueryContext + description in Section 3.7.4 (Context Queries): + + If the context is bound to a window surface, then either + EGL_SINGLE_BUFFER, EGL_BACK_BUFFER, EGL_TRIPLE_BUFFER_NV, or + EGL_QUADRUPLE_BUFFER_NV may be returned. + + Replace first sentence of eglSwapBuffers description in + Section 3.9.1 + (Posting to a Window): + + If surface is a back-buffered window surface, then the current + color buffer is copied to the native window associated with + that surface. If there is more than one back buffer, then the + next color buffer in rotation becomes current, and rendering + of the next frame may proceed before the copy takes place, + provided any previous swaps from the new current buffer have + completed. + +Issues + + 1. Why do we need triple-buffering? + + RESOLVED: With only a single back buffer and a non-zero swap + interval, eglSwapBuffers must block rendering to the back- + buffer until the copy has completed. This can leave the CPU + and/or GPU idle, wasting valuable compute time, and possibly + cause the next frame to be delivered later than otherwise could + have been. Additional buffers allow rendering to continue even + when a frame is awaiting display, maximizing our use of + computational resources. + + 2. Why quadruple-buffering? Isn't triple-buffering enough to + produce frames as fast as the processor(s) and swap interval + allow? + + RESOLVED: When there is only a single rendering stream + operating on a system, triple-buffering is sufficient. However, + if other threads are contending for resources, variable + latencies may be introduced. This is especially problematic + with video, where any deviation in frame rate from the recorded + media can produce visible artifacts. Additional buffers smooth + out these latencies, allowing a steady frame rate. + + 3. Then why not arbitrary n-buffering? + + RESOLVED: The TRIPLE/QUADRUPLE buffer specification fits nicely + into the RENDER_BUFFER attribute already in use for + eglCreateWindowSurface. Arbitrary buffer counts would require a + new attribute. Additionally, case studies indicated no + significant benefit to using more than three back buffers, + especially when factoring in the added memory cost. + +Revision History + + #2 (February 28, 2019) Santanu Thangaraj + - Marked issues 1,2 and 3 as resolved. + - Included extension type section. + - Corrected line length violations. + + #1 (August 12, 2008) Daniel Kartch + - Initial Draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_native_query.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_native_query.txt new file mode 100644 index 0000000..ce35633 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_native_query.txt @@ -0,0 +1,137 @@ +Name + + NV_native_query + +Name Strings + + EGL_NV_native_query + +Contributors + + Mathias Heyer, NVIDIA + Daniel Kartch, NVIDIA + Peter Pipkorn, NVIDIA + Acorn Pooley, NVIDIA + Greg Roth, NVIDIA + +Contacts + + Peter Pipkorn, NVIDIA Corporation (ppipkorn 'at' nvidia.com) + +Status + + Complete + +Version + + Version 0.4, 25 Sept, 2012 + +Number + + EGL Extension #45 + +Dependencies + + Requires EGL 1.0 + + This extension is written against the wording of the EGL 1.4 + Specification. + +Overview + + This extension allows an application to query which native display, + pixmap and surface corresponds to a EGL object. + +New Procedures and Functions + + EGLBoolean eglQueryNativeDisplayNV( + EGLDisplay dpy, + EGLNativeDisplayType* display_id); + + EGLBoolean eglQueryNativeWindowNV( + EGLDisplay dpy, + EGLSurface surf, + EGLNativeWindowType* window); + + EGLBoolean eglQueryNativePixmapNV( + EGLDisplay dpy, + EGLSurface surf, + EGLNativePixmapType* pixmap); + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + In Chapter 3.2, after the description of eglInitialize and before the + description of eglTerminate insert + + "While initialized, the native display that corresponds to an + EGLDisplay can retrieved by + + EGLBoolean eglQueryNativeDisplayNV( + EGLDisplay dpy, + EGLNativeDisplayType* display_id); + + If the <dpy> is a valid and initialized EGLDisplay, EGL_TRUE + will be returned and the native display handle will be written + to <display_id>. Otherwise EGL_FALSE will be returned and the + contents of <display_id> are left untouched. If the <dpy> is + not valid, an EGL_BAD_DISPLAY error will be generated. If <dpy> + is not initialized, an EGL_NOT_INITIALIZED error will be + generated. If <display_id> is NULL, an EGL_BAD_PARAMETER error + will be generated. + + In Chapter 3.5 Rendering Surfaces, after section 3.5.1 insert + + "The native window that corresponds to an EGLSurface can be + retrieved by + + EGLBoolean eglQueryNativeWindowNV( + EGLDisplay dpy, + EGLSurface surf, + EGLNativeWindowType* win); + + The corresponding native window will be written to <win>, + and EGL_TRUE will be returned. If the call fails, EGL_FALSE + will be returned, and content of <win> will not be modified. + If <dpy> is not a valid EGLDisplay, an EGL_BAD_DISPLAY error + will be generated. If <dpy> is not initialized, an EGL_NOT_- + INITIALIZED error will be generated. If <surf> is not a valid + EGLSurface, or <surf> does not have a corresponding native + window, an EGL_BAD_SURFACE error will be generated." If <win> + is NULL, an EGL_BAD_PARAMETER error will be generated. + + After section 3.5.4 Creating Native Pixmap Rendering Surfaces insert + + "The native pixmap that corresponds to an EGLSurface can be + retrieved by + + EGLBoolean eglQueryNativePixmapNV( + EGLDisplay dpy, + EGLSurface surf, + EGLNativePixmapType* pixmap); + + The corresponding native pixmap will be written to <pixmap>, + and EGL_TRUE will be returned. If the call fails, EGL_FALSE + will be returned, and the content of <pixmap> will not be + modified. If <dpy> is not a valid EGLDisplay, an EGL_BAD_- + DISPLAY error will be generated. If <dpy> is not initialized, + an EGL_NOT_INITIALIZED error will be generated. If <surf> is + not a valid EGLSurface, or <surf> does not have a corresponding + native pixmap, an EGL_BAD_SURFACE error will be generated." If + <pixmap> is NULL, an EGL_BAD_PARAMETER error will be + generated. + +Issues + +Revision History +#4 (Greg Roth, Sept 25, 2012) + - Further document all potential errors for all functions + +#3 (Daniel Kartch, August 30, 2011) + - Add restriction that EGLDisplay be initialized + +#2 (Peter Pipkorn, December 16, 2009) + - Minor cleanup + +#1 (Peter Pipkorn, December 15, 2009) + - First Draft + diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_convert_rounding.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_convert_rounding.txt new file mode 100644 index 0000000..6b7c340 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_convert_rounding.txt @@ -0,0 +1,85 @@ +Name + + NV_post_convert_rounding + +Name Strings + + EGL_NV_post_convert_rounding + +Contributors + + Bryan Eyler, NVIDIA + Daniel Kartch, NVIDIA + Greg Roth, NVIDIA + Mark Vojkovich, NVIDIA + Nicolai de Haan Brogger, NVIDIA + Peter Pipkorn, NVIDIA + +Contacts + + Nicolai de Haan Brogger, NVIDIA Corporation (nicolaid 'at' nvidia.com) + +Status + + Complete + +Version + + Last Modified 17 Oct 2012 + Version 2 + +Number + + EGL Extension #44 + +Dependencies + + Requires EGL 1.0. + + This extension is written against the wording of the EGL 1.4 + Specification. + +Overview + + This extension defines the conversions for posting operations + when the destination's number of components or component sizes do + not match the color buffer. This extension supports posting a 24 bit + (888) color buffer to a 16 bit (565) destination buffer, posting a + 16 bit (565) color buffer to a 24 bit (888) destination buffer, and + posting a component that is present in the source buffer, but not + present in the destination buffer. + +New Procedures and Functions + + None + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and +Errors) + + In Chapter 3.9.3, replace paragraph 3 with: + " For each color component, if the bit depth of the color + buffer being posted is 24 (888) and the destination buffer is + 16 (565), the lower order bits of the color buffer are + truncated. + + If the bit depth of the destination buffer is 24 (888) and the + color buffer being posted is 16 bit (565), a RGB gain and + rounding operation is applied to the color buffer values prior + to posting. The destination buffer will contain the rounded + (nearest) and clamped result of the vector product of [1.03125, + 1.015625, 1.03125] with the RGB values of the color buffer. + + For cases where a component is present in the color buffer but + the matching component is not present in the destination + buffer, that component will be dropped." + + In Chapter 3.9.3, remove paragraph 5. + +Issues + +Revision History +#2 (Greg Roth, Oct 17, 2012) + - Clarify limitations and reformat a bit. + +#1 (Nicolai de Haan Brogger, July 07, 2010) + - First Draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_sub_buffer.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_sub_buffer.txt new file mode 100644 index 0000000..69c113c --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_post_sub_buffer.txt @@ -0,0 +1,241 @@ +Name + + NV_post_sub_buffer + +Name Strings + + EGL_NV_post_sub_buffer + +Contributors + + Arcady Goldmints-Orlov + James Jones + Daniel Kartch + +Contact + + James Jones, NVIDIA Corporation (jajones 'at' nvidia.com) + +Status + + Draft. + +Version + + Version 3, November 5, 2010 + +Number + + EGL Extension #27 + +Dependencies + + Requires EGL 1.1 + + This extension is written against the wording of the EGL 1.4 + Specification + +Overview + + Many EGL client APIs do not support rendering to window surfaces + directly, so there is no way to efficiently make small updates to + window surfaces. Applications that need to perform many small updates + must either use the back-buffer preservation flag which forces + eglSwapBuffers to copy the entire back surface, or redraw the entire + back buffer on every update and hope eglSwapBuffers is implemented + using buffer-flipping. This extension provides a 3rd alternative: a + function which posts a sub-rectangle of a window surface and + preserves the back-buffer contents. + +New Types + + None. + +New Procedures and Functions + + EGLBoolean eglPostSubBufferNV(EGLDisplay dpy, + EGLSurface surface, + EGLint x, EGLint y, + EGLint width, EGLint height); + +New Tokens + + Accepted by the <attribute> parameter of eglQuerySurface and by the + <attrib_list> parameter of eglCreateWindowSurface: + + EGL_POST_SUB_BUFFER_SUPPORTED_NV 0x30BE + +Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) + + Modify the second paragraph of Section 3.5.1, page 27 + (Creating On-Screen Rendering Surfaces) + + "<attrib_list> specifies a list of attributes for the window. The list + has the same structure as described for eglChooseConfig. Attributes + that can be specified in <attrib_list> include EGL_POST_SUB_BUFFER_- + SUPPORTED_NV, EGL_RENDER_BUFFER, EGL_VG_COLORSPACE, and EGL_VG_ALPHA_- + FORMAT." + + Add the following between paragraphs 4 and 5 of Section 3.5.1, page 27 + (Creating On-Screen Rendering Surfaces) + + "EGL_POST_SUB_BUFFER_SUPPORTED_NV specifies whether the application + would perfer a surface that supports sub-buffer post operations, as + described in section 3.9.1. Its values can be EGL_TRUE, in which case + the implementation will attempt to allocate a surface that supports + sub-buffer posts, or EGL_FALSE, in which case the implementation will + not take sub-buffer post capabilities into account. + + "Implementations may not be able to support sub-buffer post + mechanisms, or may support them only on some native windows. Use + eglQuerySurface to determine a surface's capabilities (see section + 3.5.6)." + + Add the following entry to Table 3.5, page 36 + (Queryable surface attributes and types) + + Attribute Type Description + -------------------------------- ------- ------------------------ + EGL_POST_SUB_BUFFER_SUPPORTED_NV boolean Surface can be used with + eglPostSubBufferNV + + Add the following paragraph to Section 3.5.6, page 37 + (Surface Attributes) + + "Querying EGL_POST_SUB_BUFFER_SUPPORTED_NV returns EGL_TRUE if the + surface can use eglPostSubBufferNV (See section 3.9.1) to post sub- + rectangles of the back color buffer. Otherwise, EGL_FALSE is + returned." + + Replace all but the last paragraph of section Section 3.9.1, page 50 + (Posting to a Window) + + "To post the color buffer to a window, call + + EGLBoolean eglSwapBuffers(EGLDisplay dpy, + EGLSurface surface); + + "To post a sub-rectangle of the color buffer to a window, call + + EGLBoolean eglPostSubBufferNV(EGLDisplay dpy, + EGLSurface surface, EGLint x, EGLint y, + EGLint width, EGLint height); + + "Where <x> and <y> are pixel offsets from the bottom-left corner of + <surface>. + + "If <surface> is a back-buffered surface, then the requested portion + of the color buffer is copied to the native window associated with + that surface. If <surface> is a single-buffered window, pixmap, or + pbuffer surface, eglSwapBuffers and eglPostSubBufferNV have no + effect. + + "The contents of ancillary buffers are always undefined after calling + eglSwapBuffers or eglPostSubBufferNV. The contents of the color + buffer are unchanged if eglPostSubBufferNV is called, or if + eglSwapBuffers is called and the value of the EGL_SWAP_BEHAVIOR + attribute of <surface> is EGL_BUFFER_PRESERVED. The value of EGL_- + SWAP_BEHAVIOR can be set for some surfaces using eglSurfaceAttrib, as + described in section 3.5.6. + + "Native Window Resizing + + "If the native window corresponding to <surface> has been resized + prior to the swap, <surface> must be resized to match. <surface> will + normally be resized by the EGL implementation at the time the native + window is resized. If the implementation cannot do this transparently + to the client, then eglSwapBuffers and eglPostSubBufferNV must + detect the change and resize <surface> prior to copying its pixels to + the native window. The sub-rectangle defined by <x>, <y>, <width>, and + <height> parameters to eglPostSubBufferNV will be clamped to the + extents of <surface>. If, after clamping, the rectangle contains no + pixels, eglPostSubBufferNV will have no effect." + + Modify the following sentences in Section 3.9.3, page 51 (Posting + Semantics) + + Paragraph 2, first sentence: + + "If <dpy> and <surface> are the display and surface for the calling + thread's current context, eglSwapBuffers, eglPostSubBufferNV, and + eglCopyBuffers perform an implicit flush operation on the context + (glFlush for OpenGL or OpenGL ES context, vgFlush for an OpenVG + context)." + + Paragraph 3, first sentence: + + "The destination of a posting operation (a visible window, for + eglSwapBuffers or eglPostSubBufferNV, or a native pixmap, for + eglCopyBuffers) should have the same number of components and + component sizes as the color buffer it's being copied from." + + Paragraph 6, first two sentences: + + "The function + + EGLBoolean eglSwapInterval(EGLDisplay dpy, EGLint + interval); + + specifes the minimum number of video frame periods per color buffer + post operation for the window associated with the current context. The + interval takes effect when eglSwapBuffers or eglPostSubBufferNV is + first called subsequent to the eglSwapInterval call." + + Modify the following sentences in Section 3.9.4, page 52 (Posting + Errors) + + Paragraph 1, first sentence: + + "eglSwapBuffers, eglPostSubBufferNV, and eglCopyBuffers return + EGL_FALSE on failure." + + Paragraph 1, seventh sentence: + + "If eglSwapBuffers or eglPostSubBufferNV are called and the native + window associated with <surface> is no longer valid, an EGL_BAD_- + NATIVE_WINDOW error is generated. If eglPostSubBufferNV is called + and <x>, <y>, <width>, or <height> are less than zero, EGL_BAD_- + PARAMETER is generated." + +Issues + + 1. Should all surfaces be required to support sub-buffer posts if + this extension is supported? + + RESOLVED: No. Some implementations may support multiple types of + native windows. Support for sub-surface posting is therefore a + per-surface property, so a surface query should be used to determine + which surfaces support sub-surface posts. + + 2. What should this extension be called? + + RESOLVED: Names considered EGL_NV_copy_sub_buffer, EGL_NV_present_sub- + surface, EGL_NV_post_sub_buffer. eglCopySubBuffer() sounded too + similar to eglCopyBuffer(), which operates on different types of + surfaces. EGL_present_sub_surface was originally chosen as it was + sufficiently different than eglCopyBuffer(), but based on internal + feedback, the term "Post" is preferable to "Present" because it is + already used in the EGL spec to describe buffer presentation + operations. "Buffer" was chosen over "surface" at this point as well, + because it is more consistent with the eglSwapBuffers() and + eglCopyBuffer() commands, and eglPostSubBuffer() is still + differentiated enough from eglCopyBuffer() that the two won't be + confused. + +Revision History + +#3 (James Jones, November 5, 2010) + -Renamed from NV_present_sub_surface to NV_post_sub_buffer based on + feedback from internal reviews. + + -Allowed EGL_POST_SUB_BUFFER_SUPPORTED_NV to be used as a hint when + creating window surfaces. + + -Clarified that eglSwapInterval applies to all color-buffer post + operations affecting on-screen surfaces, not just eglSwapBuffers. + +#2 (James Jones, November 1, 2010) + - Fixed a few typos. + +#1 (James Jones, October 22, 2010) + - Initial revision, based on GLX_MESA_copy_sub_buffer diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_eglimage.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_eglimage.txt new file mode 100644 index 0000000..432fdbf --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_eglimage.txt @@ -0,0 +1,367 @@ +Name + + NV_stream_consumer_eglimage + +Name Strings + + EGL_NV_stream_consumer_eglimage + +Contributors + + Mukund Keshava + James Jones + Daniel Kartch + Sandeep Shinde + Pyarelal Knowles + Leo Xu + +Contacts + + Mukund Keshava, NVIDIA (mkeshava 'at' nvidia.com) + +Status + + Draft + +Version + + Version 3 - November 27, 2019 + +Number + + EGL Extension #139 + +Extension Type + + EGL display extension + +Dependencies + + Requires the EGL_KHR_stream extension. + + Requires the EGL_EXT_sync_reuse extension. + + This extension is written against the wording of the EGL 1.5 + Specification + +Overview + + An EGLStream consists of a sequence of image frames. This extension + allows these frames to be acquired as EGLImages. Frames from the + stream would be used as the content for the EGLImage. + +New Procedures and Functions + + EGLBoolean eglStreamImageConsumerConnectNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLint num_modifiers, + const EGLuint64KHR *modifiers, + const EGLAttrib* attrib_list); + + EGLint eglQueryStreamConsumerEventNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLTime timeout, + EGLenum *event, + EGLAttrib *aux); + + EGLBoolean eglStreamAcquireImageNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLImage *pImage, + EGLSync sync); + + EGLBoolean eglStreamReleaseImageNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLImage image, + EGLSync sync); + +New Tokens + + Accepted by the <target> parameter of eglCreateImage: + + EGL_STREAM_CONSUMER_IMAGE_NV 0x3373 + + Returned as an <event> from eglQueryStreamConsumerEventNV: + + EGL_STREAM_IMAGE_ADD_NV 0x3374 + EGL_STREAM_IMAGE_REMOVE_NV 0x3375 + EGL_STREAM_IMAGE_AVAILABLE_NV 0x3376 + +Add to section "3.9 EGLImage Specification and Management" of +the EGL 1.5 Specification, in the description of eglCreateImage: + + "Values accepted for <target> are listed in Table 3.10, below. + + +-------------------------------+-----------------------------------+ + | <target> | Notes | + +-------------------------------+-----------------------------------+ + | EGL_STREAM_CONSUMER_IMAGE_NV | Used with EGLStream objects | + +-------------------------------+-----------------------------------+ + Table 3.10: Legal values for eglCreateImage target parameter. + + If <target> is EGL_STREAM_CONSUMER_IMAGE_NV, a new EGLImage will be + created for the next consumer image frame in the EGLStream + referenced by <buffer> which is not currently bound to an EGLImage. + If the stream's producer reuses memory buffers for multiple image + frames, then an EGLImage obtained in this way will persist for the + next image frame that uses the same buffer, unless destroyed in + the interim. Otherwise, the user must create a new EGLImage for + every frame. Creating the EGLImage does not guarantee that the + image contents will be ready for use. The EGLImage must first be + acquired from the stream after creation. + + If the EGLImage created for a consumer image frame is destroyed via + eglDestroyImage, a new EGLImage needs to be created via + eglCreateImage for the same consumer image frame. + + <dpy> must be a valid initialized display. <ctx> must be + EGL_NO_CONTEXT. <buffer> must be a handle to a valid EGLStream + object, cast into the type EGLClientBuffer. + + Add to the list of error conditions for eglCreateImage: + + "* If <target> is EGL_STREAM_CONSUMER_IMAGE_NV and <buffer> is + not a valid stream handle associated with <dpy>, the error + EGL_BAD_STREAM_KHR is generated. + + * If <target> is EGL_STREAM_CONSUMER_IMAGE_NV, and <ctx> is not + EGL_NO_CONTEXT, the error EGL_BAD_PARAMETER is generated. + + * If <target> is EGL_STREAM_CONSUMER_IMAGE_NV, and there are no + buffers in the <stream> currently or if there are no buffers + associated with the stream that are not already bound to + EGLImages EGL_BAD_ACCESS is generated. + + eglCreateImage needs to be called with EGL_STREAM_CONSUMER_IMAGE_NV + as the <target> for every valid buffer in the EGLStream. + +Add section "3.10.2 Connecting an EGLStream to a consumer" in the +EGL_KHR_stream extension with this: + + 3.10.2.2 EGLImage consumer + + Call + + EGLBoolean eglStreamImageConsumerConnectNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLint num_modifiers, + const EGLuint64KHR *modifiers, + const EGLAttrib* attrib_list); + + to connect the EGLImage consumer to the <stream>. An EGLImage + consumer allows image frames inserted in the stream to be received + as EGLImages, which can then be bound to any other object which + supports EGLImage. For each image frame, an EGLImage must first be + created as described in section "3.9 EGLImage Specification and + Management" of the EGL 1.5 Specification, and then the frame + contents must be latched to the EGLImage as described below. + + In <modifiers> the consumer can advertise an optional list of + supported DRM modifiers as described in + EXT_image_dma_buf_import_modifiers. This information could be + used by the producer to generate consumer supported image frames. + + If not NULL, <attrib_list> points to an array of name/value + pairs, terminated by EGL_NONE. Currently no attributes are + supported. + + On success, EGL_TRUE is returned. + + - <stream> state is set to EGL_STREAM_STATE_CONNECTING_KHR + allowing the producer to be connected. + + On failure, EGL_FALSE is returned and an error is generated. + + - EGL_BAD_DISPLAY is generated if <dpy> is not the handle of a + valid EGLDisplay object. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + valid stream handle associated with <dpy>. + + - EGL_BAD_STATE_KHR is generated if the <stream> state is not + EGL_STREAM_STATE_CREATED_KHR before + eglStreamImageConsumerConnectNV is called. + + Call + + EGLint eglQueryStreamConsumerEventNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLTime timeout, + EGLenum *event, + EGLAttrib *aux); + + to query the <stream> for the next pending event. + eglQueryStreamConsumerEventNV returns in <event> the event type + and returns in <aux> additional data associated with some events. + + If no event is pending at the time eglQueryStreamConsumerEventNV is + called, it will wait up to <timeout> nanoseconds for one to arrive + before returning. If <timeout> is EGL_FOREVER, the function will + not time out and will only return if an event arrives or the stream + becomes disconnected. + + On success, EGL_TRUE is returned. A new event will be returned. + The valid events are as follows: + + - EGL_STREAM_IMAGE_ADD_NV is returned if a buffer is present in + the stream which has not yet been bound to an EGLImage with + eglCreateImage. + + - EGL_STREAM_IMAGE_REMOVE_NV indicates that a buffer has been + removed from the stream and its EGLImage, whose handle is + returned in <aux>, can be destroyed when the consumer + application no longer requires it. + + - EGL_STREAM_IMAGE_AVAILABLE_NV indicates that there is a + new frame available in the stream that can be acquired via + eglStreamAcquireImageNV. + + On failure, EGL_FALSE is returned and an error is generated and + <event> and <aux> are not modified. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + valid stream handle associated with <dpy>. + + EGL_TIMEOUT_EXPIRED is returned if the <timeout> duration is + complete, and there are no valid events that occured in this + duration. The <event> and <aux> parameters are not modified. + + Call + + EGLBoolean eglStreamAcquireImageNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLImage *pImage, + EGLSync sync); + + to "latch" the next image frame in the image stream from <stream> + into an EGLImage. + + If <sync> is not EGL_NO_SYNC, then it must be an EGLSync with a type + of EGL_SYNC_FENCE, and it must be signaled (e.g., created with + EGL_SYNC_STATUS set to EGL_SIGNALED). eglStreamAcquireImageNV will + reset the state of <sync> to unsignaled, and <sync> will be signaled + when the producer is done writing to the frame. + + If <sync> is EGL_NO_SYNC, then eglStreamAcquireImageNV ignores the + sync object. + + On success, EGL_TRUE is returned. + + - <pImage> will have the most recent frame from the <stream> + + On failure, eglStreamAcquireImageNV returns EGL_FALSE, and an error + is generated. + + - EGL_BAD_DISPLAY is generated if <dpy> is not a valid, + initialized EGLDisplay. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + valid stream handle associated with <dpy>. + + - EGL_BAD_ACCESS is generated if there are no frames in the + <stream> that are available to acquire. + + - EGL_BAD_PARAMETER is generated if <sync> is not a valid + EGLSync object or EGL_NO_SYNC. + + - EGL_BAD_ACCESS is generated if <sync> is not EGL_NO_SYNC and is + not a fence sync. + + - EGL_BAD_ACCESS is generated if <sync> is not EGL_NO_SYNC and is + not in the signaled state. + + Call + + EGLBoolean eglStreamReleaseImageNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLImage image, + EGLSync sync); + + to release the <image> frame back to the stream. This takes a + <sync> that indicates when the consumer will be done using the + frame. Before calling eglStreamReleaseImageNV, the <image> + needs to have previously been acquired with + eglStreamAcquireImageNV. + + If <sync> is not EGL_NO_SYNC, then it must be an EGLSync with a + typeof EGL_SYNC_FENCE. eglStreamReleaseImageNV makes a copy of the + sync object, so the caller is free to delete or reuse <sync> as it + chooses. + + If <sync> is EGL_NO_SYNC, then the sync object is ignored. + + On success, EGL_TRUE is returned, and the frame is successfully + returned back to the stream. + + On failure, eglStreamReleaseImageNV returns EGL_FALSE, and an + error is generated. + + - EGL_BAD_DISPLAY is generated if <dpy> is not a valid, + initialized EGLDisplay. + + - EGL_BAD_STATE_KHR is generated if <stream> is not in state + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR or + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + EGLStream created for <dpy>. + + - EGL_BAD_PARAMETER is generated if <image> is either invalid, + or is not held by the consumer. + + - EGL_BAD_PARAMETER is generated if <sync> is not a valid + EGLSync object or EGL_NO_SYNC. + + - EGL_BAD_ACCESS is generated if <sync> is not EGL_NO_SYNC and is + not a fence sync. + + If an acquired EGLImage has not yet released when eglDestroyImage + is called, then, then an implicit eglStreamReleaseImageNV will be + called. + +Add a new subsection 3.10.4.3.1 at the end of section "3.10.4.3 +EGL_STREAM_STATE_KHR Attribute" in the EGL_KHR_stream extension spec: + + 3.10.4.3.1 Interaction with EGL_STREAM_STATE_KHR + + Image frames that have been presented to the stream on the producer + side, but have not been bound to an EGLImage on the consumer side + yet, do not affect the EGLStream state. + + If a new frame is presented to the stream, the stream state goes + into EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR only if this frame is + bound to an EGLImage on the consumer, and if it has not already + been acquired. + + If an EGLImage bound on the consumer side has been destroyed via + eglDestroyImage, then the stream goes into + EGL_STREAM_STATE_EMPTY_KHR if there are no consumer frames left, + that are bound to an EGLImage. + +Issues + + +Revision History + + #5 (December 15, 2021) Kyle Brenneman + - Corrected and clarified the <sync> parameters + + #4 (December 10, 2021) Kyle Brenneman + - Added the missing const modifier for input parameters + + #3 (November 27, 2019) Mukund Keshava + - Refined some subsections with more details + + #2 (November 22, 2019) Mukund Keshava + - Refined some subsections with more details + - Added new subsection 3.10.4.3.1 + + #1 (November 13, 2019) Mukund Keshava + - initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_gltexture_yuv.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_gltexture_yuv.txt new file mode 100644 index 0000000..4aa0a66 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_consumer_gltexture_yuv.txt @@ -0,0 +1,280 @@ +Name + + NV_stream_consumer_gltexture_yuv + +Name Strings + + EGL_NV_stream_consumer_gltexture_yuv + +Contributors + + James Jones + Daniel Kartch + Nikhil Mahale + Daniel Koch + Jeff Gilbert + +Contacts + + James Jones, NVIDIA (jajones 'at' nvidia 'dot' com) + +Status + + Complete + +Version + + Version 4 - November 14, 2017 + +Number + + EGL Extension #94 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_KHR_stream_consumer_gltexture + References EGL_EXT_yuv_surface + +Interactions with EGL_EXT_yuv_surface + + This extension makes use of several tokens defined in the + EGL_EXT_yuv_surface extension spec. However support for this + EGLStream extension does not require the EGLSurface extension, or + vice versa. Only the tokens are shared. + +Overview + + The EGL_KHR_stream_consumer_gltexture extension allows EGLStream + frames to be latched to a GL texture for use in rendering. These + frames are assumed to be stored in RGB format and accessed as such + by shader programs. If the producer uses a different color space, + the stream implementation must perform an implicit conversion. + + In cases where the producer operates in a native YUV color space, it + may be desirable for shaders to directly access the YUV components, + without conversion. This extension adds a new variant of the + function to bind GL textures as stream consumers which allows + attributes to specify the color space. + +New Types + + None + +New Functions + + EGLBoolean eglStreamConsumerGLTextureExternalAttribsNV( + EGLDisplay dpy, + EGLStreamKHR stream, + const EGLAttrib *attrib_list) + +New Tokens + + Accepted as attribute name in <attrib_list> by + eglStreamConsumerGLTextureExternalAttribsNV: + + EGL_YUV_PLANE0_TEXTURE_UNIT_NV 0x332C + EGL_YUV_PLANE1_TEXTURE_UNIT_NV 0x332D + EGL_YUV_PLANE2_TEXTURE_UNIT_NV 0x332E + +Reused Tokens From EGL_EXT_yuv_surface + + Accepted as attribute name in <attrib_list> by + eglStreamConsumerGLTextureExternalAttribsNV: + + EGL_YUV_NUMBER_OF_PLANES_EXT 0x3311 + + Accepted as value for EGL_COLOR_BUFFER_TYPE attribute in + <attrib_list> by eglStreamConsumerGLTextureExternalAttribsNV: + + EGL_YUV_BUFFER_EXT 0x3300 + +Replace entire description of eglStreamConsumerGLTextureExternalKHR in +section "3.10.2.1 GL Texture External consumer" of +EGL_KHR_stream_consumer_gltexture extension. + + Call + + EGLBoolean eglStreamConsumerGLTextureExternalAttribsNV( + EGLDisplay dpy, + EGLStreamKHR stream, + const EGLAttrib *attrib_list) + + to connect one or more texture objects in the OpenGL or OpenGL ES + context current to the calling thread as the consumer(s) of + <stream>. The identity and format of the texture objects used are + determined by <attrib_list> and the current context state. + + <attrib_list> must either be NULL or point to an array of name/value + pairs terminated by EGL_NONE. Valid attribute names are + EGL_COLOR_BUFFER_TYPE, EGL_YUV_NUMBER_OF_PLANES_EXT, and + EGL_YUV_PLANE<n>_TEXTURE_UNIT_NV. + + If the value of EGL_COLOR_BUFFER_TYPE is EGL_RGB_BUFFER (the + default), then the stream will be connected to a single texture + whose contents are available to shaders as RGB values. If the value + of EGL_COLOR_BUFFER_TYPE is EGL_YUV_BUFFER_EXT the stream will be + connected to some number of planar textures, determined by the value + of EGL_YUV_NUMBER_OF_PLANES_EXT, whose contents are available to + shaders as YUV values. The mapping between YUV values and texture + contents is described in table 3.10.2.1. + + If EGL_COLOR_BUFFER_TYPE is EGL_YUV_BUFFER_EXT, the default value of + EGL_YUV_NUMBER_OF_PLANES_EXT is 2. Otherwise it is 0. + + PLANE0 PLANE1 PLANE2 + # Planes Values Fields Values Fields Values Fields + -------------------------------------------------------------- + 1 YUV XYZ unused unused + 2 Y X UV XY unused + 3 Y X U X V X + + Table 3.10.2.1 YUV Planar Texture Mappings + + If EGL_COLOR_BUFFER_TYPE is EGL_RGB_BUFFER, the stream is connected + to the texture object currently bound to the active texture unit's + GL_TEXTURE_EXTERNAL_OES texture target in the current context. + + If EGL_COLOR_BUFFER_TYPE is EGL_YUV_BUFFER_EXT, attribute values + must be specified for EGL_YUV_PLANE<n>_TEXTURE_UNIT_NV for all <n> + less than the number of planes. The value of each attribute must + either be a valid texture unit index or EGL_NONE. No two of these + attributes may specify the same valid texture unit index or + reference separate texture units bound to the same texture object. + Plane <n> of the stream contents will be connected to the texture + object currently bound to the indexed texture unit's + GL_TEXTURE_EXTERNAL_OES texture target in the current context, or + will be left unused if the index is EGL_NONE. + + Once connected, the stream will remain associated with the initial + texture object(s) even if the texture units are bound to new + textures. + + (Note: Before this can succeed a GL_TEXTURE_EXTERNAL_OES texture + must be bound to the appropriate texture units of the GL context + current to the calling thread. To create a GL_TEXTURE_EXTERNAL_OES + texture and bind it to the current context, call glBindTexture() + with <target> set to GL_TEXTURE_EXTERNAL_OES and <texture> set to + the name of the GL_TEXTURE_EXTERNAL_OES (which may or may not have + previously been created). This is described in the + GL_NV_EGL_stream_consumer_external extension.) + + On failure EGL_FALSE is returned and an error is generated. + + - EGL_BAD_DISPLAY is generated if <dpy> is not a valid, + EGLDisplay. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + EGLStreamKHR created for <dpy>. + + - EGL_BAD_STATE_KHR is generated if <stream> is not in state + EGL_STREAM_STATE_CREATED_KHR. + + - EGL_BAD_ATTRIBUTE is generated if any attribute name in + <attrib_list> is not a valid attribute. + + - EGL_BAD_PARAMETER is generated if the value of + EGL_COLOR_BUFFER_TYPE is not EGL_RGB_BUFFER or + EGL_YUV_BUFFER_EXT. + + - EGL_BAD_MATCH is generated if EGL_COLOR_BUFFER_TYPE is + EGL_RGB_BUFFER and EGL_YUV_NUMBER_OF_PLANES_EXT is not 0, or + if EGL_COLOR_BUFFER_TYPE is EGL_YUV_BUFFER_EXT and + EGL_YUV_NUMBER_OF_PLANES_EXT is not 1, 2, or 3. + + - EGL_BAD_MATCH is generated if any + EGL_YUV_PLANE<n>_TEXTURE_UNIT_NV is not specified for any <n> + less than EGL_YUV_NUMBER_OF_PLANES_EXT, or if it is specified + for any <n> greater than or equal to + EGL_YUV_NUMBER_OF_PLANES_EXT. + + - EGL_BAD_ACCESS is generated if any + EGL_YUV_PLANE<n>_TEXTURE_UNIT_NV is set to anything other than + a valid texture unit index or EGL_NONE. + + - EGL_BAD_ACCESS is generated if there is no GL context + current to the calling thread. + + - EGL_BAD_ACCESS is generated unless nonzero texture object + names are bound the GL_TEXTURE_EXTERNAL_OES texture target + of each of the appropriate texture units of the GL context + current to the calling thread. + + - EGL_BAD_ACCESS is generated if more than one planar surface + would be bound to the same texture object. + + - EGL_BAD_ACCESS is generated if the implementation cannot + support the requested planar arrangement. + + On success the texture(s) are connected to the <stream>, <stream> + is placed in the EGL_STREAM_STATE_CONNECTING_KHR state, and EGL_TRUE + is returned. + + When a producer is later connected, if it cannot support the planar + arrangement of the GL texture connection, it will fail with an + EGL_BAD_ACCESS error. + + If any texture is later deleted, connected to a different + EGLStream, or connected to an EGLImage, then <stream> will be + placed into the EGL_STREAM_STATE_DISCONNECTED_KHR state. + + If the <stream> is later destroyed then the textures will be + "incomplete" until they are connected to a new EGLStream, connected + to a new EGLImage, or deleted. + + The function + + EGLBoolean eglStreamConsumerGLTextureExternalKHR( + EGLDisplay dpy, + EGLStreamKHR stream) + + is equivalent to eglStreamConsumerGLTextureExternalAttribsNV with + <attrib_list> list set to NULL. + +In the remainder of section "3.10.2.1 GL Texture External consumer", +replace all singular references to "texture" with "textures" and make +appropriate grammatical modifications. + +Issues + + 1. This competes with GL_EXT_yuv_target as a means for specifying + how YUV values can be directly accessed by a texture shader + without conversion to RGB. However, that extension also requires + a means to render to YUV surfaces in addition to using them as + textures. Should we go with the approach used here or create a + GL extension which defines a subset GL_EXT_yuv_target? + + RESOLVED: The extension as is serves immediate needs. Conflicts + and overlap with other extensions will be addressed if and when + there is a need to promote to EXT. + + 2. This also contradicts how previous extensions for EXTERNAL GL + textures bind multiplanar surfaces, using separate texture + objects rather than a single virtual texture object which + requires multiple texture units. This allows the application + greater control of the planar arrangement, and the ability to + leave planes unbound, which may reduce overhead for the + producer. But it makes applications less portabile if the + desired arrangement isn't supported. + + RESOLVED: The extension as is serves immediate needs. Conflicts + and overlap with other extensions will be addressed if and when + there is a need to promote to EXT. + +Revision History + + #4 (November 14, 2017) Mozilla Corporation + - Const-qualify attrib_list. + + #3 (August 19, 2015) NVIDIA Corporation + - Added enum values. + - Cleaned up and added contact info for publication. + + #2 (May 6, 2015) NVIDIA Corporation + - Consolidated error codes to make GL interaction simpler. + + #1 (April 15, 2015) NVIDIA Corporation + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_dma.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_dma.txt new file mode 100644 index 0000000..16716b0 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_dma.txt @@ -0,0 +1,137 @@ +Name + + NV_stream_dma + +Name Strings + + EGL_NV_stream_dma + +Contributors + + Santanu Thangaraj + Daniel Kartch + Arihant Jejani + +Contacts + + Santanu Thangaraj, NVIDIA (sthangaraj 'at' nvidia.com) + Arihant Jejani, NVIDIA (ajejani 'at' nvidia.com) + +Status + + Draft + +Version + + Version 1 - April 15, 2019 + +Number + + 135 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_NV_stream_remote extension. + + Requires EGL_NV_stream_cross_system extension. + + Interacts with EGL_NV_stream_socket extensions. + +Overview: + + This extension provides the framework for performing DMA transfers + between opposite ends of a single stream, if there is no shared + memory available between them. + + In case of cross system streams the buffer contents of one end of + the stream is transferred to other end using sockets by + EGL_NV_stream_socket extension. Transferring buffer contents + through sockets is slower compared to DMA transfers. Since DMA + transfers have higher throughput compared to sockets, using + EGL_NV_stream_dma extension, applications can request EGL to + utilize DMA channels to perform buffer copies. + +New types + + None + +New Procedures and functions + + None + +New Tokens + + Accepted as attribute names in eglCreateStreamKHR, + eglCreateStreamAttribKHR, eglQueryStreamKHR, and + eglQueryStreamAttribKHR: + + EGL_STREAM_DMA_NV 0x3371 + EGL_STREAM_DMA_SERVER_NV 0x3372 + +Add to list of failures in section "3.10.1 Creating an EGLStream" in +EGL_KHR stream: + - EGL_BAD_MATCH is generated if the value of EGL_STREAM_DMA_NV is + neither EGL_TRUE nor EGL_FALSE. + - EGL_BAD_MATCH is generated if the value of + EGL_STREAM_DMA_SERVER_NV is not EGL_DONT_CARE or a valid + DMA server identifier as defined by the platform. + +Add to "Table 3.10.4.4 EGLStream Attributes" in EGL_KHR_stream: + + Attribute Read/Write Type Section + ------------------------ ----------- ------ ---------- + EGL_STREAM_DMA_NV io EGLint 3.10.4.x + EGL_STREAM_DMA_SERVER_NV io platform dependent 3.10.4.x+1 + +Add new subsections to the end of section "3.10.4 EGLStream Attributes" +in EGL_KHR_stream: + + 3.10.4.x EGL_STREAM_DMA_NV Attribute + + The EGL_STREAM_DMA_NV attribute may be set when the stream is + created, and indicates whether the DMA channels have to be used to + transfer the buffer contents from producer to consumer. Legal + values are EGL_TRUE or EGL_FALSE. The default value is EGL_FALSE. + + A value of EGL_TRUE indicates that EGL has to use DMA channels to + transfer buffers from producer to consumer. + + If EGL_FALSE is specified, DMA channels will not be utilized for + buffer transfers. + + 3.10.4.x+1 EGL_STREAM_DMA_SERVER_NV Attribute + + The EGL_STREAM_DMA_SERVER_NV attribute is a platform dependent + identifier which may be set when the stream is created and it + indicates the server, which must be contacted to handle DMA + transfers, if that server is not local. Legal values, aside from + EGL_DONT_CARE, are determined by the implementation. The default + value is EGL_DONT_CARE. + +Issues + + 1. What happens when application requests DMA copy using + EGL_STREAM_DMA_NV attribute in eglCreateStreamKHR or + eglCreateStreamAttribKHR API, but the system does not support + access to DMA channels? + + RESOLVED: The functions return EGL_NO_STREAM_KHR and + EGL_BAD_ATTRIBUTE error is set. + + 2. What happens when application requests DMA copy using + EGL_STREAM_DMA_NV attribute in eglCreateStreamKHR or + eglCreateStreamAttribKHR API, and the system supports DMA + channels, but currently none of the channels are available for + use? + + RESOLVED: The functions return EGL_NO_STREAM_KHR and + EGL_BAD_ATTRIBUTE error is set. + +Revision History + + #1 (April 15, 2019) Santanu Thangaraj + - Initial version diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_next.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_next.txt new file mode 100644 index 0000000..8199487 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_next.txt @@ -0,0 +1,105 @@ +Name + + NV_stream_fifo_next + +Name Strings + + EGL_NV_stream_fifo_next + +Contributors + + Daniel Kartch + Miguel A. Vico + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 3 - October 27, 2016 + +Number + + EGL Extension #110 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_KHR_stream_fifo + +Overview + + When operating on a FIFO stream, a consumer may need to know the + timestamp associated with the next frame in the stream before + deciding whether to acquire it or reuse the previous frame. In the + case of a FIFO size of 1, the EGL_STREAM_TIME_PRODUCER_KHR attribute + is sufficient to determine this. However, when the size is greater + than 1, there may be frames available with earlier time stamps than + the one most recently inserted by the producer. This extension + enables querying of the next pending frame in a stream. + +New Types + + None + +New Functions + + None + +New Tokens + + Accepted as the <attribute> parameter of eglQueryStreamu64KHR + + EGL_PENDING_FRAME_NV 0x3329 + + Accepted as the <attribute> parameter of eglQueryStreamTimeKHR + + EGL_STREAM_TIME_PENDING_NV 0x332A + +Add to "Table 3.10.4.4 EGLStream Attributes" in the EGL_KHR_stream +extension spec: + + Attribute Read/Write Type Section + -------------------------- ---------- ------------ -------- + EGL_PENDING_FRAME_NV ro EGLuint64KHR 3.10.4.x + EGL_STREAM_TIME_PENDING_NV ro EGLTimeKHR 3.10.4.y + +Add new subsections to section "3.10.4 EGLStream Attributes" in the +EGL_KHR_stream extension spec + + 3.10.4.x EGL_PENDING_FRAME_NV Attribute + + The EGL_PENDING_FRAME_NV attribute indicates the frame number of the + image frame that would be obtained if an acquire operation were + performed at the time of the query. This is the value that + EGL_PRODUCER_FRAME_KHR contained just after this image frame was + inserted into the stream. + + 3.10.4.y EGL_STREAM_TIME_PENDING_NV Attribute + + The EGL_STREAM_TIME_PENDING_NV attribute indicates the timestamp of + the image frame that would be obtained if an acquire operation were + performed at the time of the query. + +Issues + + None + +Revision History + + #3 (October 27, 2016) Daniel Kartch + - Clean up for publication + + #2 (April 2nd, 2015) Miguel A. Vico + - Assigned enumerated values for constants. + + #1 (March 20th, 2015) Daniel Kartch + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_synchronous.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_synchronous.txt new file mode 100644 index 0000000..f34804f --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_fifo_synchronous.txt @@ -0,0 +1,211 @@ +Name + + NV_stream_fifo_synchronous + +Name Strings + + EGL_NV_stream_fifo_synchronous + +Contributors + + Daniel Kartch + Adam Cheney + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 4 - October 27, 2016 + +Number + + EGL Extension #111 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_KHR_stream_fifo + +Interactions with EGL_NV_stream_sync and +EGL_KHR_stream_consumer_gltexture + + This extension affects implementations of stream synchronization and + GL texture consumer extensions in that it alters when functions + waiting for new frames will be unblocked. However, as these waits + are still tied to transitions to the + EGL_STREAM_STATE_NEW_FRAME_AVAILALBLE_KHR state, no changes are + required to the wording of those specifications. + +Overview + + On platforms which support asynchronous rendering, frames may be + inserted into a stream by the producer and become available to the + consumer before rendering of the images has completed. When this + happens, commands issued by the consumer which read from the image + must implicitly wait before they can be executed. In many use cases, + this is desirable behavior. Rendering pipelines are kept full, and + frames are created and processed as fast as possible. + + However, in the case of a compositor which is consuming frames from + multiple producers at once, combining them into a single output + image, this can slow the compositor to the frame rate of the slowest + producer. If the application acquires and uses an image from one + producer which requires a long time to finish rendering, it will be + prevented from presenting new frames from faster producers in a + timely fashion. In this case, the compositor would prefer to reuse + an older frame from the slower producer until the new one is ready. + + This could be handled with existing interfaces by the producer + issuing appropriate Finish call before inserting the frame into the + stream. However this requires the producer to have knowledge of the + consumer's use case, and also introduces undesirable bubbles into + the producer's pipeline which will slow it even further. + + This extension allows streams to be configured to defer the + availability of new frames inserted by the producer until they are + ready to be used. The producer proceeds as normal, but the frames + visible to the consumer through query and acquire operations do not + update immediately. + + Interactions of this feature with a stream operating in mailbox mode + would be hard to define. Because newly inserted frames replace + previous unacquired ones, it is possible that the consumer would + never see a completed frame become available. Therefore this feature + is only available for streams operating in FIFO mode. + +New Types + + None + +New Functions + + None + +New Tokens + + Accepted as an attribute name in the <attrib_list> parameter of + eglCreateStreamKHR and a the <attribute> parameter of + eglQueryStreamKHR: + + EGL_STREAM_FIFO_SYNCHRONOUS_NV 0x3336 + +Add new entry to table "3.10.4.4 EGLStream Attributes" in the +EGL_KHR_stream extension + + Attribute Read/Write Type Section + ------------------------------ ---------- ---------- -------- + EGL_STREAM_FIFO_SYNCHRONOUS_NV io EGLBoolean 3.10.4.y + +Add new subsection to section "3.10.4 EGLStream Attributes" in the +EGL_KHR_stream extension + + 3.10.4.y EGL_STREAM_FIFO_SYNCHRONOUS_NV Attribute + + The EGL_STREAM_FIFO_SYNCHRONOUS_NV attribute controls whether frames + inserted by the producer become available to the consumer + synchronously or asynchronously. If set to EGL_FALSE, then when a + present operation for a new frame successfully completes, the state + will immediately become EGL_STREAM_NEW_FRAME_AVAILABLE_KHR, queries + of the most recently produced frame will indicate this frame, and + acquire operations will be able to retrieve this frame. If set to + EGL_TRUE, then until any asynchronous rendering for this frame + completes, the state will not update, any queries of the most + recently produced frame will only indicate the frame whose rendering + most recently completed, and acquire operations will only obtain + older completed frames. + + The default value is EGL_FALSE. If set to EGL_TRUE, the value of + EGL_STREAM_FIFO_LENGTH_KHR must be non-zero, or an EGL_BAD_MATCH + error will be generated. + +Replace first two sentences of section "3.10.4.4 EGL_PRODUCER_FRAME +Attribute" in the EGL_KHR_stream extension + + The EGL_PRODUCER_FRAME_KHR attribute indicates how many image + frames have become available for the consumer to acquire. This is + also known as the "frame number" of the most recent ready frame + (where the first frame inserted has a frame number of 1). In + asynchronous operation, this is the frame most recently inserted by + the producer. In synchronous operation, this is the frame whose + image content generation has most recently finished. + +Replace contents of section "3.10.4.x+3 EGL_STREAM_TIME_PRODUCER_KHR" in +the EGL_KHR_stream_fifo extension + + This indicates the timestamp of the most recent ready frame in the + EGLStream (i.e. frame number EGL_PRODUCER_FRAME_KHR). + +Replace the second through fifth paragraphs of "3.10.5.2 EGLStream operation +in fifo mode" in the EGL_KHR_stream_fifo extension. + + In fifo mode the EGLStream conceptually operates as a fifo. An image + frame in the fifo is considered "ready" if all operations on the + image scheduled prior to its insertion in the stream have completed, + or if the value of EGL_STREAM_FIFO_SYNCHRONOUS_NV is EGL_FALSE. + + When the consumer wants to consume a new image frame, behavior + depends on the state of the EGLStream. If the state is + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR then the image frame at the + tail of the fifo is ready, and is removed from the fifo. If the + state is EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR then the fifo has + no ready image frames and the consumer consumes the same frame that + it most recently consumed. Otherwise there are no image frames + available to consume (behavior in this case is described in the + documentation for each type of consumer - see section "3.10.2 + Connecting an EGLStream to a consumer"). + + When EGL_STREAM_FIFO_SYNCHRONOUS_NV is EGL_FALSE, any consumer + operations which read from the image frame must implicitly wait for + any producer operations used to generate the image contents to + complete. Apart from the assumption that any such operations will + eventually finish, there are no guaranteed bounds on the time + required, and therefore no guaranteed bounds on when the consumer's + operations will complete. In cases where reusing a previous frame is + preferable to unknown latency between the time a consumer acquires a + new frame and the time its processing of that frame is done, + EGL_STREAM_FIFO_SYNCHRONOUS_NV should be set to EGL_TRUE. + + If there is no new ready frame at the tail of the fifo when the + consumer is finished consuming an image frame then the consumer + holds on to the image frame in case it needs to be consumed again + later (this happens if the consumer wants to consume another image + frame before the producer has inserted a new image frame into the + fifo, or before any such frame has finished rendering in the case of + synchronous operation). In this case the state of the EGLStream + will be EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR until a new image + frame is ready (or until the state becomes + EGL_STREAM_STATE_DISCONNECTED_KHR). + + The producer inserts image frames at the head of the fifo. If the + fifo is full (already contains <L> image frames, where <L> is the + value of the EGL_STREAM_FIFO_LENGTH_KHR attribute) then the producer + is stalled until the fifo is no longer full. When there is at + least one ready frame at the tail of the fifo, the EGLStream state + is EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR. + +Issues + + None + +Revision History + + #4 (October 27, 2016) Daniel Kartch + - Clean up for publication + + #3 (September 30, 2015) Daniel Kartch + - Reserve enum. + + #2 (March 30, 2015) Daniel Kartch + - Fix grammatical and typographical errors. + + #1 (March 27, 2015) Daniel Kartch + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_flush.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_flush.txt new file mode 100644 index 0000000..0b26508 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_flush.txt @@ -0,0 +1,132 @@ +Name + + NV_stream_flush + +Name Strings + + EGL_NV_stream_flush + +Contributors + + Santanu Thangaraj + Daniel Kartch + +Contacts + + Santanu Thangaraj, NVIDIA (sthangaraj 'at' nvidia.com) + +Status + + Draft + +Version + + Version 3 - April 11, 2018 + +Number + + 127 + +Extension Type + + EGL display extension + +Dependencies + + Requires the EGL_KHR_stream extension. + + Requires either the EGL_KHR_stream_cross_process_fd or + EGL_NV_stream_remote extensions. + + This extension is written based on the wording of version 27 of + the EGL_KHR_stream extension. + +Overview: + + The EGL_KHR_stream_cross_process_fd and EGL_NV_stream_remote + extensions do not guarantee that when the state of the EGLStream + object representing one endpoint of the stream changes, + the state of the other endpoint will immediately reflect + that change. Depending on the implementation, there may be some + latency in the propagation of state changes. + + This latency will not affect any applications which rely solely + on the stream itself for communication. State changes made on + one side will eventually be visible on the other side, + and can then be responded to. + + This only affects applications which use some additional means of + communication outside of the stream itself, which may encounter + race conditions. In particular, if an application inserts a frame + into a stream, then sends a message to the other side indicating + that the frame is ready, the other side may encounter an error if + it tries to acquire the frame and it is not yet available. + + One solution is to force all operations that change state of one + endpoint to behave synchronously, and not return until the change + is reflected on the other endpoint. However this adds undesirable + delays for the majority of applications and operations where such + synchronization is not required. This extension instead provides + a means for applications to explicitly invoke such + synchronization only where required. + +New types + + None + +New Procedures and functions + + EGLBoolean eglStreamFlushNV( + EGLDisplay dpy, + EGLStreamKHR stream); + +New Tokens + + None + +Add a new subsection "3.10.x EGLStream flush" at the end of section +"3.10 EGLStreams" in EGL_KHR_stream extension. + + The command + + EGLBoolean eglStreamFlushNV( + EGLDisplay dpy, + EGLStreamKHR stream); + + When called with either producer or consumer endpoint of the + stream, will block until any state changes made to this endpoint + prior to the call are visible on the EGLStream object of the other + endpoint. + + On success, EGL_TRUE will be returned. On failure, EGL_FALSE will + be returned and an error will be generated. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + EGLStream. + + - EGL_BAD_STATE_KHR is generated if <stream> is in + EGL_STREAM_STATE_DISCONNECTED_KHR state. + + - EGL_BAD_DISPLAY is generated if <dpy> is not a valid + EGLDisplay. + + - EGL_NOT_INITIALIZED is generated if <dpy> is not initialized. + +Issues + + 1. When both producer and consumer are connected to a single + EGLStream object, what happens when eglStreamFlushNV is called? + + RESOLVED: The function returns without any blocking. + +Revision History + + #3 (April 11, 2018) Jon Leech + - Add missing NV suffix to eglStreamFlushNV + + #2 (April 2, 2018) Santanu Thangaraj + - Update based on comments from Daniel Kartch + - General cleanup + + #1 (March 26, 2018) Santanu Thangaraj + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_frame_limits.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_frame_limits.txt new file mode 100644 index 0000000..75c0e49 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_frame_limits.txt @@ -0,0 +1,152 @@ +Name + + NV_stream_frame_limits + +Name Strings + + EGL_NV_stream_frame_limits + +Contributors + + Daniel Kartch + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 4 - October 27, 2016 + +Number + + EGL Extension #113 + +Dependencies + + Requires EGL_KHR_stream + + Interacts with EGL_EXT_stream_consumer_egloutput + +Overview + + Some stream consumers may allow more than one frame to be acquired + at a time, so that applications can operate on sequences of images + rather than individual images. This in turn may lead to producers + allocating additional buffers to keep the fifo full while fulfilling + the consumer's needs. Applications may wish to limit the resources + allocated for a given stream, and some stream implementations may be + able to operate more efficiently if they know in advance how many + buffers will be used. + + This extension defines two new stream attributes which provide hints + as to how many frames the application will require, allowing the + implementation to plan accordingly. + +New functions + + None + +New tokens + + Accepted as an attribute name in the <attrib_list> parameter of + eglCreateStreamKHR and as the <attribute> parameter of + eglQueryStreamKHR. + + EGL_PRODUCER_MAX_FRAME_HINT_NV 0x3337 + EGL_CONSUMER_MAX_FRAME_HINT_NV 0x3338 + + +Add to "Table 3.10.4.4 EGLStream Attributes" + + Attribute Read/Write Type Section + ------------------------------ ---------- ------ ---------- + EGL_PRODUCER_MAX_FRAME_HINT_NV io EGLint 3.10.4.x + EGL_CONSUMER_MAX_FRAME_HINT_NV io EGLint 3.10.4.x+1 + +Add new subsections to section "3.10.4 EGLStream Attributes" + + 3.10.4.x EGL_PRODUCER_MAX_FRAME_HINT_NV Attribute + + The EGL_PRODUCER_MAX_FRAME_HINT_NV attribute indicates a limit on how + many outstanding frames the producer application intends to have at + any given time. This includes all frames currently being generated, + waiting in in the stream's mailbox or FIFO, and held by the consumer. + Its default value is EGL_DONT_CARE. + + The implementation may make use of this hint to determine how many + buffers or other resources to allocate for the stream. It is not + necessarily an error for an application to attempt to insert more + than this many frames into the stream at once. However, exceeding + available resources may cause a producer to block or return an error, + as per its specification. + + 3.10.4.x+1 EGL_CONSUMER_MAX_FRAME_HINT_NV Attribute + + The EGL_CONSUMER_MAX_FRAME_HINT_NV attribute indicates a limit on how + many frames the consumer application intends to acquire at the same + time. Its default value EGL_DONT_CARE. + + The implementation may make use of this hint to determine how many + buffers or other resources to allocate for the stream. It is not + necessarily an error for an application to attempt to acquire more + than this many frames at once. However, exceeding available resources + may cause the consumer or producer to block or return an error, as per + their specifications. + +Add to the description of eglStreamConsumerOutputEXT in the +EGL_KHR_stream_consumer_egloutput extension + + When the producer generates frames faster than the output device can + display them, <stream>'s EGL_CONSUMER_MAX_FRAME_HINT_NV attribute can + be used to throttle the output. No more than the specified number of + frames will be scheduled for display at a time. If specified, the value + should be set to at least 2, to allow one frame to be displayed while + another is acquired and scheduled for display. + +Issues + + 1. Is a generic stream extension really necessary, or can such + limits instead be imposed in the producer and consumer + interfaces? + + RESOLVED: Yes, it is necessary. There are several use cases + where an application may need to impose limits and cannot do so + through the producer and consumer interfaces: + a) The producer and client interfaces are already published and + do not allow room for extension to impose limits. + b) The stream is cross-process, and one process needs to impose + limits on the endpoint provided by the other process. + In addition, a common method for imposing such limits simplifies + programming of large application suites which make use of + multiple types of producers and consumers, and allows the limits + on producer and consumer endpoints to be set to compatible + values. + + 2. Should the attributes be hints or hard limits? + + RESOLVED: Hints. The variety of possible producers and consumers + makes it difficult to specify what the behavior should be if a + hard limit is exceeded. The goal here is to allow the application + to coordinate its resource requirements with the implementation. + If it fails to limit itself to the hinted values, we allow + producers or consumers to block or fail as appropriate for their + interfaces, but do not require it. + +Revision History + + #4 (October 27, 2016) Daniel Kartch + - Clean up for publication + + #3 (September 14, 2106) Daniel Kartch + - Switched from hard limits to hints + + #2 (January 8, 2016) Daniel Kartch + - Assigned enum values + + #1 (October 30, 2015) Daniel Kartch + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_metadata.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_metadata.txt new file mode 100644 index 0000000..d5a613e --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_metadata.txt @@ -0,0 +1,335 @@ +Name + + NV_stream_metadata + +Name Strings + + EGL_NV_stream_metadata + +Contributors + + Daniel Kartch + Gajanan Bhat + Laszlo Weber + Lawrence Ibarria + Miguel A. Vico + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia 'dot' com) + +Status + + Complete + +Version + + Version 8 - July 31, 2015 + +Number + + EGL Extension #93 + + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_KHR_stream + + Interacts with EGL_EXT_device_base + +Overview + + Application suites which make use of streams to transmit images may + need to communicate additional data between the producer and + consumer, synchronized with the frame updates. This data may change + infrequently, such as a movie title and track number to be displayed + to the user, or every frame, such as a focal length and exposure + time used to process the image. Transmitting this data outside the + scope of the stream may be inconvenient, particularly in the case of + cross-process streams. But the nature of the data is highly + application-dependent, so it is not feasible for an EGL + implementation to define specific extensions for a broad range of + application data. + + This extension provides a means for an application (or application + suite in the cross-process case) to associate arbitrary metadata + with a stream. Multiple metadata fields are available, allowing them + to be updated and used independently by separate subcomponents of + producers and consumers, respectively. The format of the data is + determined by the application, which is responsible for writing and + reading it correctly. + +New Types + + None + +New Functions + + EGLBoolean eglQueryDisplayAttribNV( + EGLDisplay dpy, + EGLint attribute, + EGLAttrib* value); + + EGLBoolean eglSetStreamMetadataNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLint n, + EGLint offset, + EGLint size, + const void* data); + + EGLBoolean eglQueryStreamMetadataNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLenum name, + EGLint n, + EGLint offset, + EGLint size, + void* data); + +New Tokens + + Accepted as <attribute> by eglQueryDisplayAttribNV: + + EGL_MAX_STREAM_METADATA_BLOCKS_NV 0x3250 + EGL_MAX_STREAM_METADATA_BLOCK_SIZE_NV 0x3251 + EGL_MAX_STREAM_METADATA_TOTAL_SIZE_NV 0x3252 + + Accepted as <name> by eglQueryStreamMetatdataNV: + + EGL_PRODUCER_METADATA_NV 0x3253 + EGL_CONSUMER_METADATA_NV 0x3254 + EGL_PENDING_METADATA_NV 0x3328 + + Accepted in <attrib_list> by eglCreateStreamKHR and as <attribute> + by eglQueryStreamKHR: + + EGL_METADATA0_SIZE_NV 0x3255 + EGL_METADATA1_SIZE_NV 0x3256 + EGL_METADATA2_SIZE_NV 0x3257 + EGL_METADATA3_SIZE_NV 0x3258 + + EGL_METADATA0_TYPE_NV 0x3259 + EGL_METADATA1_TYPE_NV 0x325A + EGL_METADATA2_TYPE_NV 0x325B + EGL_METADATA3_TYPE_NV 0x325C + + +Add to section "3.3 EGL Queries" + + To query attributes of an initialized display, call + + EGLBoolean eglQueryDisplayAttribNV( + EGLDisplay dpy, + EGLint attribute, + EGLAttrib* value) + + On success, EGL_TRUE is returned, and the value associated with + attribute <name> is returned in <value>. + + If <name> is EGL_MAX_STREAM_METADATA_BLOCKS_NV, the total number + of independent metadata blocks supported by each stream is returned. + If <name> is EGL_MAX_STREAM_METADATA_BLOCK_SIZE_NV, the maximum size + supported for an individual metadata block is returned. If <name> is + EGL_MAX_STREAM_METADATA_TOTAL_SIZE_NV, the maximum combined size of + all metadata blocks supported by a single stream is returned. + + On failure, EGL_FALSE is returned. An EGL_BAD_DISPLAY error is + generated if <dpy> is not a valid initialized display. An + EGL_BAD_ATTRIBUTE error is generated if <name> is not a valid + attribute name. + +If EGL_EXT_device_base is present, eglQueryDisplayAttribNV is equivalent +to eglQueryDisplayAttribEXT, and calls to either will return the same +values. + +Add to table "3.10.4.4 EGLStream Attributes" in EGL_KHR_stream + + Attribute Read/Write Type Section + ------------------------ ---------- ------ ---------- + EGL_METADATA<n>_SIZE_NV io EGLint 3.10.4.x + EGL_METADATA<n>_TYPE_NV io EGLint 3.10.4.x+1 + +Add new subsections to section "3.10.4 EGLStream Attributes" of +EGL_KHR_stream + + 3.10.4.x EGL_METADATA<n>_SIZE_NV + + The EGL_METADATA<n>_SIZE_NV attribute indicates the size of the + <n>th metadata block associated with a stream. If <n> is not less + than the value of EGL_MAX_STREAM_METADATA_BLOCKS_NV for the parent + EGLDisplay, the attribute is treated as unknown. + + These attributes may only be set when the stream is created. The + default value is 0. The value may not exceed that of + EGL_MAX_STREAM_METADATA_BLOCK_SIZE_NV for the parent EGLDisplay. + Furthermore, the total size of all metadata blocks may not exceed + the value of EGL_MAX_STREAM_METADATA_TOTAL_SIZE_NV. If either of + these restrictions are exceeded, an EGL_BAD_PARAMETER error is + generated. + + 3.10.4.x+1 EGL_METADATA<n>_TYPE_NV + + The EGL_METADATA<n>_TYPE_NV attribute indicates an optional + application-defined type associated with the stream's <n>th metadata + block. If <n> is not less than the value of + EGL_MAX_STREAM_METADATA_BLOCKS_NV for the parent EGLDisplay, the + attribute is treated as unknown. + + These attributes may only be set when the stream is created. The + default value is 0. It is not required that a type be provided for + every metadata block for which a size has been specified. These may + be used to help separate application components coordinate their use + of the stream's metadata blocks. + +Add new section to "3.10 EGLStreams" of EGL_KHR_stream + + 3.10.y EGLStream metadata + + An application may associate arbitrary blocks of additional data + with the stream, to be updated in sync with the frames. The contents + and format of these data blocks are left to the application, subject + to size restrictions imposed by the implementation. The application + must specify the sizes of its metadata blocks at the time the stream + is created. The contents may be completely or partially modified + every frame or less frequently, as the application chooses. When a + new frame is inserted into the stream, a snapshot of the current + metadata contents are associated with the frame, and may then be + queried from the stream. + + The contents of all metadata blocks of non-zero size are initialized + to zeroes. To modify the contents of a portion of a metadata block, + call + + EGLBoolean eglSetStreamMetadataNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLint n, + EGLint offset, + EGLint size, + const void* data) + + On success, EGL_TRUE is returned and the first <size> bytes pointed + to by <data> will be copied to the <n>th metadata block of <stream>, + starting at <offset> bytes from the beginning of the block. This + data will be associated with all subsequent frames inserted into the + stream until the contents are next modified. + + On failure, EGL_FALSE is returned + - An EGL_BAD_DISPLAY error is generated if <dpy> is not a valid + display. + - An EGL_BAD_STREAM_KHR error is generated if <stream> is not a + valid stream associated with <dpy>. + - An EGL_BAD_STATE_KHR error is generated if the state of + <stream> is not EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR, + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR, or + EGL_STREAM_STATE_EMPTY_KHR. + - An EGL_BAD_ACCESS error is generated if the producer and + consumer endpoints of the stream are represented by separate + EGLStream objects, and the producer is not attached to + <stream>. + - An EGL_BAD_PARAMETER error is generated if <n> is negative or + is equal to or greather than the value of + EGL_MAX_STREAM_METADATA_BLOCKS_NV for <dpy>. + - An EGL_BAD_PARAMETER error is generated if <offset> or <size> + are negative, or if <offset>+<size> is greater than the value + of EGL_METADATA<n>_SIZE_NV for <stream>. + + If <data> does not point to valid readable memory of at least <size> + bytes, undefined behavior will result. If the value of <size> is + zero, no error will occur, but the function will have no effect. + + To query the contents of a metadata block for a frame, call + + EGLBoolean eglQueryStreamMetadataNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLenum name, + EGLint n, + EGLint offset, + EGLint size, + void* data) + + On success, EGL_TRUE is returned and <size> bytes starting from the + <offset>th byte of the <n>th metadata block of <stream> will be + copied into the memory pointed to by <data>. If <name> is + EGL_PRODUCER_METADATA_NV, the metadata will be taken from the frame + most recently inserted into the stream by the producer. If <name> is + EGL_CONSUMER_METADATA_NV, the metadata will be taken from the frame + most recently acquired by the consumer. If <name> is + EGL_PENDING_METADATA_NV, the metadata will be taken from the frame + which would be obtained if an acquire operation were performed at + the time of the query. + + On failure, EGL_FALSE is returned + - An EGL_BAD_DISPLAY error is generated if <dpy> is not a valid + display. + - An EGL_BAD_STREAM_KHR error is generated if <stream> is not a + valid stream associated with <dpy>. + - An EGL_BAD_STATE_KHR error is generated if the state of + <stream> is not EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR or + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR. + - An EGL_BAD_ATTRIBUTE error is generated if <name> is not + EGL_PRODUCER_METADATA_NV, EGL_CONSUMER_METADATA_NV, or + EGL_PENDING_METADATA_NV. + - An EGL_BAD_PARAMETER error is generated if <n> is negative or + is equal to or greater than the value of + EGL_MAX_STREAM_METADATA_BLOCKS_NV for <dpy>. + - An EGL_BAD_PARAMETER error is generated if <offset> or <size> + are negative, or if <offset>+<size> is greater than the value + of EGL_METADATA<n>_SIZE_NV for <stream>. + + If <data> does not point to valid writeable memory of at least + <size> bytes, undefined behavior will result. If the value of <size> + is zero, no error will occur, but the function will have no effect. + +Issues + + 1. What happens if multiple calls are made to + eglSetStreamMetadataNV without presenting a new frame? + + RESOLVED: If the calls specify overlapping ranges of the same + metadata block, the earlier data in the overlapped portion is + overwritten. Only the most recent values are associated with + the next frame when it is inserted into the stream. + + 2. What happens if multiple frames are presented without calling + eglSetStreamMetadataNV? + + RESOLVED: The most recently provided data is reused. + +Revision History + + #8 (July 31, 2015) Daniel Kartch + - Cleaned up and added contact info for publication. + + #7 (April 2, 2015) Miguel A. Vico + - Assigned enumerated value for metadata of pending frame. + + #6 (March 20, 2015) Daniel Kartch + - Add query for metadata of pending frame. + + #5 (January 15, 2015) Daniel Kartch + - Add paragraph of supported attributes to description of + eglQueryDisplayAttribNV. + - Added/updated error conditions to set/query functions. + - Fixed errors in prototypes. + + #4 (January 6, 2015) Daniel Kartch + - Fixed errors in prototypes. + - Added enum values. + + #3 (December 12, 2014) Daniel Kartch + - Clarified language on how metadata becomes associated with + frames inserted into the stream. + - Fixed typos. + + #2 (December 12, 2014) Daniel Kartch + - Added offset and size to Set and Query functions. + + #1 (December 11, 2014) Daniel Kartch + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_origin.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_origin.txt new file mode 100644 index 0000000..5f56646 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_origin.txt @@ -0,0 +1,298 @@ +Name + + NV_stream_origin + +Name Strings + + EGL_NV_stream_origin + +Contributors + + Miguel A. Vico + James Jones + Daniel Kartch + +Contacts + + Miguel A. Vico (mvicomoya 'AT' nvidia.com) + +Status + + Complete. + +Version + + Version 5 - May 20, 2019 + +Number + + 134 + +Extension Type + + EGL display extension + +Dependencies + + Requires the EGL_KHR_stream extension. + + This extension is written based on the wording of version 26 of the + EGL_KHR_stream extension. + +Overview + + EGL does not define a frame orientation. However, window systems or + rendering APIs might. + + Ideally, when using EGL streams, frame orientation is agreed upon by + both the connected consumer and producer and appropriate handling is + performed within EGL to satisfy both endpoints needs. Thus, + applications will rarely have to worry about frame orientation. + + However, in some cases consumer applications such as compositors + might still need to access the frame data as provided by the + consumer. Hence, they need to know what orientation was set for the + stream frames. This will allow applications to adjust the way they + access the frame data. + + Similarly, producer applications might need to adjust how rendering + commands are issued depending on the orientation set for the stream + frames. + + This extension provides new attributes to allow EGL stream users to + query frame orientation and whether it is handled automatically by + the producer or consumer endpoints so that clients are not required + to take further actions. + +New Functions + + None. + +New Tokens + + Accepted as the <attribute> parameter of eglQueryStreamKHR and + eglQueryStreamAttribKHR: + + EGL_STREAM_FRAME_ORIGIN_X_NV 0x3366 + EGL_STREAM_FRAME_ORIGIN_Y_NV 0x3367 + EGL_STREAM_FRAME_MAJOR_AXIS_NV 0x3368 + + EGL_CONSUMER_AUTO_ORIENTATION_NV 0x3369 + EGL_PRODUCER_AUTO_ORIENTATION_NV 0x336A + + Returned by eglQueryStreamKHR and eglQueryStreamAttribKHR when + attribute is EGL_STREAM_FRAME_ORIGIN_X_NV: + + EGL_LEFT_NV 0x336B + EGL_RIGHT_NV 0x336C + + Returned by eglQueryStreamKHR and eglQueryStreamAttribKHR when + attribute is EGL_STREAM_FRAME_ORIGIN_Y_NV: + + EGL_TOP_NV 0x336D + EGL_BOTTOM_NV 0x336E + + Returned by eglQueryStreamKHR and eglQueryStreamAttribKHR when + attribute is EGL_STREAM_FRAME_MAJOR_AXIS_NV: + + EGL_X_AXIS_NV 0x336F + EGL_Y_AXIS_NV 0x3370 + +Add to table "3.10.4.4 EGLStream Attributes" + + Attribute Read/Write Type Section + --------------------------------- ---------- ---------- ----------- + EGL_STREAM_FRAME_ORIGIN_X_NV ro EGLint 3.10.4.x + EGL_STREAM_FRAME_ORIGIN_Y_NV ro EGLint 3.10.4.x+1 + EGL_STREAM_FRAME_MAJOR_AXIS_NV ro EGLint 3.10.4.x+2 + EGL_CONSUMER_AUTO_ORIENTATION_NV ro EGLBoolean 3.10.4.x+3 + EGL_PRODUCER_AUTO_ORIENTATION_NV ro EGLBoolean 3.10.4.x+4 + +Add new subsections to the end of section "3.10.4 EGLStream Attributes" +in EGL_KHR_stream: + + 3.10.4.x EGL_STREAM_FRAME_ORIGIN_X_NV + + EGL_STREAM_FRAME_ORIGIN_X_NV is a read-only attribute that + indicates the position on the X axis of the origin relative to the + stream images surface as agreed upon by consumer and producer. + + The relative position on X may be one of the following: + + - EGL_LEFT_NV - Coordinates on the X axis will be 0 on the left + border and increase towards the right border until <frame + width> is reached. + + - EGL_RIGHT_NV - Coordinates on the X axis will be <frame width> + on the left border and decrease towards the right border until + 0 is reached. + + - EGL_DONT_CARE - No orientation on the X axis was set by the EGL + implementation. Applications must coordinate what they are + doing. + + EGL_STREAM_FRAME_ORIGIN_X_NV will not be defined until a consumer + and a producer are connected to the stream. Querying it before that + will generate an EGL_BAD_STATE_KHR error. + + + 3.10.4.x+1 EGL_STREAM_FRAME_ORIGIN_Y_NV + + EGL_STREAM_FRAME_ORIGIN_Y_NV is a read-only attribute that + indicates the position on the Y axis of the origin relative to the + stream images surface as agreed upon by consumer and producer. + + The relative position on Y may be one of the following: + + - EGL_TOP_NV - Coordinates on the Y axis will be 0 on the top + border and increase towards the bottom border until <frame + height> is reached. + + - EGL_BOTTOM_NV - Coordinates on the Y axis will be <frame + height> on the top border and decrease towards the bottom + border until 0 is reached. + + - EGL_DONT_CARE - No orientation on the Y axis was set by the EGL + implementation. Applications must coordinate what they are + doing. + + EGL_STREAM_FRAME_ORIGIN_Y_NV will not be defined until a consumer + and a producer are connected to the stream. Querying it before that + will generate an EGL_BAD_STATE_KHR error. + + + 3.10.4.x+2 EGL_STREAM_FRAME_MAJOR_AXIS_NV + + EGL_STREAM_FRAME_MAJOR_AXIS_NV is a read-only attribute that + indicates whether the stream images are X-major or Y-major. + + The major axis may be one of the following: + + - EGL_X_AXIS_NV - Frames are laid out such that consecutive + pixels with same Y coordinate reside next to each other in + memory. + + - EGL_Y_AXIS_NV - Frames are laid out such that consecutive + pixels with same X coordinate reside next to each other in + memory. + + - EGL_DONT_CARE - No major axis was set by the EGL + implementation. Applications must coordinate what they are + doing. + + EGL_STREAM_FRAME_MAJOR_AXIS_NV will not be defined until a consumer + and a producer are connected to the stream. Querying it before that + will generate an EGL_BAD_STATE_KHR error. + + + 3.10.4.x+3 EGL_CONSUMER_AUTO_ORIENTATION_NV + + EGL_CONSUMER_AUTO_ORIENTATION_NV is a read-only attribute that + indicates whether the consumer endpoint will handle frame orientation + automatically so that the consumer application is not required to + take further actions. + + The following values can be returned: + + - EGL_TRUE - The consumer application can read frames as normal. + The consumer will flip images as needed if the expected + orientation does not match. + + - EGL_FALSE - The consumer application is expected to query the + frame orientation and process images accordingly if it does not + match with the expected orientation. + + EGL_CONSUMER_AUTO_ORIENTATION_NV will not be defined until a consumer + and a producer are connected to the stream. Querying it before that + will generate an EGL_BAD_STATE_KHR error. + + + 3.10.4.x+4 EGL_PRODUCER_AUTO_ORIENTATION_NV + + EGL_PRODUCER_AUTO_ORIENTATION_NV is a read-only attribute that + indicates whether the producer endpoint will handle frame orientation + automatically so that the producer application is not required to + take further actions. + + The following values can be returned: + + - EGL_TRUE - The producer application can generate frames as + normal. The producer will flip images as needed if the + expected orientation does not match. + + - EGL_FALSE - The producer application is expected to query the + frame orientation and generate images accordingly if it does + not match with the expected orientation. + + EGL_PRODUCER_AUTO_ORIENTATION_NV will not be defined until a consumer + and a producer are connected to the stream. Querying it before that + will generate an EGL_BAD_STATE_KHR error. + + +Add to the error list in section "3.10.4.2 Querying EGLStream +Attributes": + + - EGL_BAD_STATE_KHR is generated if <attribute> is any of + EGL_STREAM_FRAME_ORIGIN_X_NV, EGL_STREAM_FRAME_ORIGIN_Y_NV, + EGL_STREAM_FRAME_MAJOR_AXIS_NV, EGL_CONSUMER_AUTO_ORIENTATION_NV, + or EGL_PRODUCER_AUTO_ORIENTATION_NV and the stream is in + EGL_STREAM_STATE_CREATED_KHR or EGL_STREAM_STATE_CONNECTING_KHR + state. + +Issues + + 1. Frame orientation is only needed for and relevant to specific + consumers and producers. What should the query of either + EGL_STREAM_FRAME_ORIGIN_X_NV, EGL_STREAM_FRAME_ORIGIN_Y_NV, + EGL_STREAM_FRAME_MAJOR_AXIS_NV when consumers or producers that do + not define a frame orientation are connected to the stream? + + RESOLVED: If the consumer or producer connected to the stream does + not define a frame orientation, the queries will return + EGL_DONT_CARE and applications must coordinate what they do. + + 2. What should the query return when the connected consumer or + producer defines a frame orientation but can actually handle any? + + RESOLVED: Quering EGL_STREAM_FRAME_ORIGIN_X_NV, + EGL_STREAM_FRAME_ORIGIN_Y_NV, or EGL_STREAM_FRAME_MAJOR_AXIS_NV + will return the default frame orientation. + + Querying EGL_CONSUMER_AUTO_ORIENTATION_NV or + EGL_PRODUCER_AUTO_ORIENTATION_NV will return whether the consumer + or producer can handle any orientation automatically so that + applications do not need to worry about it. + + If querying EGL_CONSUMER_AUTO_ORIENTATION_NV or + EGL_PRODUCER_AUTO_ORIENTATION_NV returns EGL_FALSE, the + corresponding application is expected to query the frame + orientation and take the appropriate action if that does not match + the expected orientation. + +Revision History + + #5 (May 20th, 2019) Miguel A. Vico + - Allocate extension number + - Mark extension as complete + + #4 (January 30th, 2019) Miguel A. Vico + - Allocate values for added enumerants + - Minor fixes to the major axis attribute description + + #3 (October 8th, 2018) Miguel A. Vico + - Collapsed producer and consumer orientation attributes + - Added major axis attribute to fully define orientation + - Added two new attributes to indicate whether the producer or + consumer can handle orientation automatically. + - Rewritten issue #1 + - Added issue #2 and its resolution + - Overall spec changes to reflect the above points + + #2 (August 19th, 2016) Miguel A. Vico + - Rename newly added attributes as consumer and producer + attributes + - Added both issue #1 and its resolution + - Overall spec changes to reflect the above points + + #1 (August 1st, 2016) Miguel A. Vico + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_remote.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_remote.txt new file mode 100644 index 0000000..c8eb464 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_remote.txt @@ -0,0 +1,472 @@ +Name + + NV_stream_remote + NV_stream_cross_object + NV_stream_cross_display + NV_stream_cross_process + NV_stream_cross_partition + NV_stream_cross_system + +Name Strings + + EGL_NV_stream_remote + +Contributors + + Daniel Kartch + Bogdan Naodovic + James Jones + Zander Clucas + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 4 - June 01, 2016 + +Number + + EGL Extension #114 + +Extension Type + + EGL display extension + +Dependencies + + Requires EGL_KHR_stream + + Interacts with EGL_KHR_stream_cross_process_fd + + All EGL_NV_stream_cross_* extensions require EGL_NV_stream_remote, + but are independent of each other. + +Overview + + This extension provides a generic framework for establishing stream + connections when the producer and consumer endpoints are not + associated with the same EGLStream object. The cross-process streams + allowed by the EGL_KHR_stream_cross_process_fd extension are one + example of such a connection. Other potential examples include + streams between objects associated with different EGLDisplays in a + single process, streams between processes residing in separate + virtual machine partitions on a single system, or streams between + entirely separate systems connected via the internet. + + The approach used by EGL_KHR_stream_cross_process_fd has several + drawbacks: + - It creates a new pair of stream creation and query functions + which are specific to both the type of stream and the method + used for communicating the stream's identity. Extending this + methodology would require new pairs of functions for every new + type of stream connection. + - It allows creation of the connected stream objects without any + indication of which side will be the consumer and which will be + the producer. It even allows, although this was probably not + intended, a cross-process stream to be established, but have + both producer and consumer exist in the same process, with the + other process acting as a voyeur that can observe state and + perhaps modify attributes, but not operate on frames. + - The use of file descriptors generated by EGL in one process + and accessed by EGL in another to establish communication has + potential security flaws, and may not be available at all on + some real-time operating systems. + + Rather than implement new connection types using this model, we + propose a more generic approach that does not require a + proliferation of new interfaces and avoids any ambiguities in how + the stream will be used. These extensions can coexist with + EGL_KHR_stream_cross_process_fd, but allow for more control of + stream communication by the applications. + + These extensions provide the framework with which arbitrary stream + object pairs can be established, but by themselves are insufficient + to create such pairs. In addition, a separate extension must be + used to determine the protocol by which the two objects will + communicate. See for example the EGL_NV_stream_socket extension. + + Several optional types of separate stream objects are defined, + with successive levels of remoteness. It should be assumed that + a more remote type will be less efficient in transfering images, + and therefore applications should choose the least remote type + available that is compatible with their use cases. + +New Types + + None + +New Functions + + None + +New Tokens + + Returned by eglQueryStreamKHR and eglQueryStreamAttribKHR when + attribute is EGL_STREAM_STATE_KHR: + + EGL_STREAM_STATE_INITIALIZING_NV 0x3240 + + Accepted as attribute names in eglCreateStreamKHR, + eglCreateStreamAttribKHR, eglQueryStreamKHR, and + eglQueryStreamAttribKHR: + + EGL_STREAM_TYPE_NV 0x3241 + EGL_STREAM_PROTOCOL_NV 0x3242 + EGL_STREAM_ENDPOINT_NV 0x3243 + + Accepted by eglCreateStreamKHR and eglCreateStreamAttribKHR, and + returned by eglQueryStreamKHR and eglQueryStreamAttribKHR, as value + when attribute is EGL_STREAM_TYPE_NV, EGL_STREAM_PROTOCOL_NV or + EGL_STREAM_ENDPOINT_NV: + + EGL_STREAM_LOCAL_NV 0x3244 + + When EGL_NV_stream_cross_object is present, accepted by + eglCreateStreamKHR and eglCreateStreamAttribKHR and returned by + eglQueryStreamKHR and eglQueryStreamAttribKHR as value for + attribute EGL_STREAM_TYPE_NV: + + EGL_STREAM_CROSS_OBJECT_NV 0x334D + + When EGL_NV_stream_cross_display is present, accepted by + eglCreateStreamKHR and eglCreateStreamAttribKHR and returned by + eglQueryStreamKHR and eglQueryStreamAttribKHR as value for + attribute EGL_STREAM_TYPE_NV: + + EGL_STREAM_CROSS_DISPLAY_NV 0x334E + + When EGL_NV_stream_cross_process is present, accepted as + value for attribute EGL_STREAM_TYPE_NV by eglCreateStreamKHR + and eglCreateStreamAttribKHR. When either + EGL_NV_stream_cross_process or EGL_KHR_stream_cross_process_fd + is present, returned by eglQueryStreamKHR and + eglQueryStreamAttribKHR for attribute EGL_STREAM_TYPE_NV: + + EGL_STREAM_CROSS_PROCESS_NV 0x3245 + + When EGL_NV_stream_cross_partition is present, accepted by + eglCreateStreamKHR and eglCreateStreamAttribKHR and returned by + eglQueryStreamKHR and eglQueryStreamAttribKHR as value for + attribute EGL_STREAM_TYPE_NV: + + EGL_STREAM_CROSS_PARTITION_NV 0x323F + + When EGL_NV_stream_cross_system is present, accepted by + eglCreateStreamKHR and eglCreateStreamAttribKHR and returned by + eglQueryStreamKHR and eglQueryStreamAttribKHR as value for + attribute EGL_STREAM_TYPE_NV: + + EGL_STREAM_CROSS_SYSTEM_NV 0x334F + + If EGL_KHR_stream_cross_process_fd is present, returned by + eglQueryStreamKHR and eglQueryStreamAttribKHR when attribute is + EGL_STREAM_PROTOCOL_NV: + + EGL_STREAM_PROTOCOL_FD_NV 0x3246 + + Accepted by eglCreateStreamKHR and eglCreateStreamAttribKHR, and + returned by eglQueryStreamKHR and eglQueryStreamAttribKHR when + attribute is EGL_STREAM_ENDPOINT_NV: + + EGL_STREAM_PRODUCER_NV 0x3247 + EGL_STREAM_CONSUMER_NV 0x3248 + +Add to "Glossary" of EGL_KHR_stream: + + Local stream + A stream implemented with both consumer and producer attached to a + single EGLStream object. + + Remote stream + A stream implemented with two EGLStream objects that communicate + with each other, with the consumer attached to one object and the + producer attached to the other. + +Add to section "3.10.1 Creating an EGLStream" in EGL_KHR_stream: + + If a remote EGLStream is created, as described in section "3.10.5.x + Remote streams", and is paired with an EGLStream object which has + conflicting values for some attributes, creation will succeed, but + the stream will enter state EGL_STREAM_STATE_DISCONNECTED_KHR once + communication is established. + +Add to list of failures in section "3.10.1 Creating an EGLStream" in +EGL_KHR stream: + + - EGL_BAD_MATCH is generated if the value of any one of the + EGL_STREAM_TYPE_NV, EGL_STREAM_PROTOCOL_NV, or + EGL_STREAM_ENDPOINT_NV attributes is EGL_STREAM_LOCAL_NV and + any other of these attributes is neither EGL_STREAM_LOCAL_NV + nor EGL_DONT_CARE. + +Add to section "3.10.2 Connecting an EGLStream to a consumer" in +EGL_KHR_stream: + + Any function which connects a consumer to an EGLStream will fail and + generate an EGL_BAD_ACCESS error if the value of the EGLStream's + EGL_STREAM_ENDPOINT_NV attribute is EGL_STREAM_PRODUCER_NV. + +Add to section "3.10.3 Connecting an EGLStream to a producer" in +EGL_KHR_stream: + + Any function which connects a producer to an EGLStream will fail and + generate an EGL_BAD_ACCESS error if the value of the EGLStream's + EGL_STREAM_ENDPOINT_NV attribute is EGL_STREAM_CONSUMER_NV. + +Add to "Table 3.10.4.4 EGLStream Attributes" in EGL_KHR_stream: + + Attribute Read/Write Type Section + -------------------------- ---------- ------ ---------- + EGL_STREAM_TYPE_NV io EGLint 3.10.4.x + EGL_STREAM_PROTOCOL_NV io EGLint 3.10.4.x+1 + EGL_STREAM_ENDPOINT_NV io EGLint 3.10.4.x+2 + +Add to beginning of state list in section "3.10.4.3 EGL_STREAM_STATE_KHR +Attribute" in EGL_KHR_stream: + + - EGL_STREAM_STATE_INITIALIZING_NV - The EGLStream object + represents one endpoint of a remote stream and has not yet + established communication with the opposite endpoint. + +Replace the first entry in the state transition table in section +"3.10.4.3 EGL_STREAM_STATE_KHR Attribute" in EGL_KHR_stream: + + -> EGL_STREAM_STATE_INITIALIZING_NV + A new remote EGLStream is created in this state. + + EGL_STREAM_STATE_INITIALIZING_NV -> + EGL_STREAM_STATE_CREATED_KHR + Occurs when a remote EGLStream object establishes communication with + the opposite endpoint. + + -> EGL_STREAM_STATE_CREATED_KHR + A new local EGLStream or EGLStream of undetermined type is created + in this state. + +Add new subsections to the end of section "3.10.4 EGLStream Attributes" +in EGL_KHR_stream: + + 3.10.4.x EGL_STREAM_TYPE_NV Attribute + + The EGL_STREAM_TYPE_NV attribute may be set when the stream + is created, and indicates the type of connection between the + EGLStream objects to which the consumer and producer are attached. + Legal values are EGL_DONT_CARE and EGL_STREAM_LOCAL_NV. The + default value is EGL_DONT_CARE. + + A value of EGL_STREAM_LOCAL_NV indicates that this is a local + stream with both consumer and producer connected to a single + EGLStream object. + + If EGL_DONT_CARE is initially specified, the value of the attribute + will automatically be changed to the appropriate value once both + consumer and producer are attached, depending on the functions used. + + Other possible values for EGL_STREAM_TYPE_NV may be defined by + additional extensions to indicate a remote stream. Where used, + the EGL_STREAM_PROTOCOL_NV attribute must also be set to a + communication protocol compatible with the stream type. + + 3.10.4.x+1 EGL_STREAM_PROTOCOL_NV Attribute + + The EGL_STREAM_PROTOCOL_NV attribute may be set when the stream is + created, and indicates the manner in which communication is + established between the EGLStream objects to which the consumer + and producer are attached. Legal values are EGL_DONT_CARE and + EGL_STREAM_LOCAL_NV. The default value is EGL_DONT_CARE. + + A value of EGL_STREAM_LOCAL_NV indicates that this is a local + stream with both consumer and producer connected to a single + EGLStream object, so no communication protocol is required. + + If EGL_DONT_CARE is initially specified, the value of the attribute + will automatically be changed to the appropriate value once both + consumer and producer are attached, depending on the functions used. + + Other possible values for EGL_STREAM_PROTOCOL_NV may be defined by + additional extensions to indicate the communication protocol to be + used for a remote stream. Not all communication protocols are + compatible with all stream types, and vice versa. If incompatible + types and protocols are specified, an EGL_BAD_MATCH error will be + generated. + + 3.10.4.x+2 EGL_STREAM_ENDPOINT_NV Attribute + + The EGL_STREAM_ENDPOINT_NV attribute may be set when the stream is + created, and indicates the endpoints which will be attached to the + EGLStream object. Legal values are EGL_DONT_CARE, + EGL_STREAM_LOCAL_NV, EGL_STREAM_CONSUMER_NV, and + EGL_STREAM_PRODUCER_NV. The default value is EGL_DONT_CARE. + + A value of EGL_STREAM_LOCAL_NV indicates that this is a local + stream with both consumer and producer connected to a single + EGLStream object. + + A value of EGL_STREAM_CONSUMER_NV indicates that the EGLStream + object represents the consumer side of a remote stream. + + A value of EGL_STREAM_PRODUCER_NV indicates that the EGLStream + object represents the producer side of a remote stream. + + If EGL_DONT_CARE is initially specified, the value of the attribute + will automatically be changed to the appropriate value once both + consumer and producer are attached, depending on the functions used. + +If EGL_NV_stream_cross_object is present, in section 3.10.4.x above, +add EGL_STREAM_CROSS_OBJECT_NV to the list of legal values, and insert + + A value of EGL_STREAM_CROSS_OBJECT_NV indicates that the stream + object represents one endpoint of a remote stream whose other + endpoint is obtained from the same EGLDisplay. + +If EGL_NV_stream_cross_display is present, in section 3.10.4.x above, +add EGL_STREAM_CROSS_DISPLAY_NV to the list of legal values, and insert + + A value of EGL_STREAM_CROSS_DISPLAY_NV indicates that the stream + object represents one endpoint of a remote stream whose other + endpoint may be obtained from a different EGLDisplay in the same + process. + +If EGL_NV_stream_cross_process or EGL_NV_stream_cross_process_fd is +present, in section "3.10.4.x" above, add EGL_STREAM_CROSS_PROCESS_NV +to the list of legal values, and insert + + A value of EGL_STREAM_CROSS_PROCESS_NV indicates that the stream + object represents one endpoint of a remote stream whose other + endpoint may reside in a separate process. + +If EGL_NV_stream_cross_partition is present, in section 3.10.4.x +above, add EGL_STREAM_CROSS_PARTITION_NV to the list of legal values, +and insert + + A value of EGL_STREAM_CROSS_PARTITION_NV indicates that the stream + object represents one endpoint of a remote stream whose other + endpoint may reside in a separate virtual machine partition on + the same system. The partitions are not required to be using the + same operating systems, but must support compatible communication + protocols. + +If EGL_NV_stream_cross_system is present, in section 3.10.4.x above, +add EGL_STREAM_CROSS_SYSTEM_NV to the list of legal values, and insert + + A value of EGL_STREAM_CROSS_SYSTEM_NV indicates that the stream + object represents one endpoint of a remote stream whose other + endpoint may reside on an independent hardware system with no + directly sharable memory resources. + +If EGL_KHR_stream_cross_process_fd is present, in section 3.10.4.x+1 +above, add EGL_STREAM_PROTOCOL_FD_NV to the list of legal values, and +insert + + A value of EGL_STREAM_PROTOCOL_FD_NV indicates that the stream is + a remote stream whose communication is established using a file + descriptor. The details of what this file descriptor represents + are implementation dependent. If the EGL_STREAM_PROTOCOL_NV + attribute is initialized with this value, the EGL_STREAM_TYPE_NV + attribute must specify a value of EGL_STREAM_CROSS_PROCESS_NV or + an EGL_BAD_MATCH failure is generated. + + If an initial value of EGL_DONT_CARE is specified and a file + descriptor is subsequently obtained with + eglGetStreamFileDescriptorKHR, the value will be automatically + changed to EGL_STREAM_PROTOCOL_FD_NV. + +Add a new subsection to the end of "3.10.5 EGLStream operation": + + 3.10.5.x Remote streams + + An EGLStream object may be created as the endpoint of a remote + stream by specifying EGL_STREAM_PRODUCER_NV or + EGL_STREAM_CONSUMER_NV as the value for its EGL_STREAM_ENDPOINT_NV + attribute. Valid and compatible EGL_STREAM_TYPE_NV and + EGL_STREAM_PROTOCOL_NV values other than EGL_DONT_CARE or + EGL_STREAM_LOCAL_NV must also be specified. + + If a value for EGL_STREAM_ENDPOINT_NV is not specified, the stream + is assumed to be local, but other extensions (see for example + EGL_KHR_stream_cross_process_fd) may allow it to be converted to a + remote stream before the producer has been attached. + + When an EGLStream object is created as remote, any unspecified + attribute will be initially set to a value of EGL_DONT_CARE. Pairs + of EGLStream objects representing opposite endpoints of a stream are + not required to specify the same attribute lists, but their + attributes must be compatible. When communication is established + between the endpoints, they will exchange attribute settings: + - If both endpoints have a value of EGL_DONT_CARE for an + attribute, the default value will be assigned. + - If one endpoint has a value of EGL_DONT_CARE for an attribute, + it will be set to the other endpoint's value. + - If neither endpoint has a value of EGL_DONT_CARE for an + attribute, their values must agree. In most cases, this means + the values must be identical, but this may not be true for all + attributes. In particular, one endpoint must specify an + EGL_STREAM_ENDPOINT_NV value of EGL_STREAM_CONSUMER_NV, and + the other must specify a value of EGL_STREAM_PRODUCER_NV. + If the values for any attribute are not compatible, the stream will + transition to the EGL_STREAM_STATE_DISCONNECTED_KHR state. + + Additionally, if the two EGLStream objects representing a remote + stream are created for EGLDisplays which cannot share resources, + the stream will transition to the EGL_STREAM_STATE_DISCONNECTED_KHR + state. + + When using remote streams, there may be latency in communicating + state changes between the EGLStream objects representing the two + endpoints. For instance, when a new frame is inserted into the + stream by the producer, the consumer endpoint may not immediately + transition to EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR. Similarly, + when a frame is acquired by the consumer, the producer endpoint may + not immediately transition to + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR. Applications should rely + only on the state of the endpoint on which they are operating to + determine the expected results of that operation. + +In section "3.10.1.1 Duplicating an EGLStream from a file descriptor" of +the EGL_KHR_stream_cross_process_fd extension, add to the failure list +for eglGetStreamFileDescriptor + + - EGL_BAD_ACCESS is generated if the EGL_STREAM_TYPE_NV + attribute of <stream> is anything other than EGL_DONT_CARE or + EGL_STREAM_CROSS_PROCESS_NV. + + - EGL_BAD_ACCESS is generated if the EGL_STREAM_PROTOCOL_NV + attribute of <stream> is anything other than EGL_DONT_CARE or + EGL_STREAM_PROTOCOL_FD_NV. + + - EGL_BAD_ACCESS is generated if the EGL_STREAM_ENDPOINT_NV + attribute of <stream> is EGL_STREAM_LOCAL_NV. + +Issues + + None + +Revision History + + #4 (June 01, 2016) + - Removed sync object definition. It will be provided by a + separate extension. + - Folded in cross-partition extension. + - Added types for cross-object, cross-display, and + cross-system streams. + - General cleanup in preparation for publication. + + #3 (September 16, 2015) Zander Clucas + - Removed dependence of the CROSS_PROCESS type on the + EGL_NV_cross_process_fd extension + - Added CROSS_PROCESS to the list of STREAM_TYPE legal values + - Added CROSS_PROCESS requirement for cross_process_fd protocol + + #2 (December 11, 2014) Daniel Kartch + - Rewrote as NV draft for earlier release. + - Added section for creation of sync object. + - Reserved enum values. + + #1 (October 10, 2014) Daniel Kartch + - Initial EXT draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_reset.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_reset.txt new file mode 100644 index 0000000..1cb0d06 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_reset.txt @@ -0,0 +1,306 @@ +Name + + NV_stream_reset + +Name Strings + + EGL_NV_stream_reset + +Contributors + + Daniel Kartch + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 6 - October 27, 2016 + +Number + + EGL Extension #112 + +Extension Type + + EGL display extension + +Dependencies + + Requires the EGL_KHR_stream extension. + + Modifies the EGL_KHR_stream_fifo extension. + + Modifies the EGL_KHR_stream_consumer_gltexture extension. + + Modifies the EGL_EXT_stream_consumer_egloutput extension. + + Interacts with the EGL_KHR_stream_cross_process_fd and + EGL_NV_stream_remote extensions. + + This extension is written based on the wording of version 26 of the + EGL_KHR_stream extension. + +Overview + + The base stream extension requires that, once the producer inserts + the first frame into the stream, at least one frame is always + available to be acquired by the consumer until the stream + disconnects. However, there are some use cases in which the producer + or the consumer may wish to allow the stream to empty without + permanently disconnecting. + + An example of a use case where the producer may wish to empty the + stream is a security or rear-view camera which temporarily stops + producing new frames, perhaps due to a hardware reset. Continuing to + display the last frame available would produce a false impression of + the current state, and should be avoided for safety reasons. A + better solution would be to let the consumer know there was no + available image, so that it could take appropriate actions, and then + recover when the camera begins streaming again. + + This use case could be handled with existing functionality by + disconnecting and destroying the stream and then recreating and + reconnecting it when new frames are available. However, this can be + burdensome, particularly when the producer and consumer reside in + separate processes. + + An example of a use case where the consumer may wish to empty the + stream is an image processer which operates on each frame exactly + once. After processing, it will not waste resources operating on the + same frame a second time. This use case can be handled by carefully + monitoring the availability of a new frame before performing an + acquire operation. But returning the buffer(s) as soon as they are + no longer needed allows for better resource management. + + This extension allows a stream to be completely drained of existing + frames by the consumer or flushed of existing frames by the producer + without disconnecting, so that processing may continue again when + new frames are produced. + +New Functions + + EGLBoolean eglResetStreamNV( + EGLDisplay dpy, + EGLStreamKHR stream); + +New Tokens + + Accepted as an attribute in the <attrib_list> parameter of + eglCreateStreamKHR and the <attrib> parameter of eglQueryStreamKHR: + + EGL_SUPPORT_RESET_NV 0x3334 + EGL_SUPPORT_REUSE_NV 0x3335 + +To table "3.10.4.4 EGLStream Attributes", add entry + + Attribute Read/Write Type Section + -------------------------- ---------- ------ ---------- + EGL_SUPPORT_RESET_NV io EGLint 3.10.4.x + EGL_SUPPORT_REUSE_NV io EGLint 3.10.4.x+1 + +Modify entries in the list of state transitions in "3.10.4.3 +EGL_STREAM_STATE_KHR Attribute" + + EGL_STREAM_STATE_EMPTY_KHR -> + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR + Occurs when the producer inserts the first image frame and any + subsequent frame after the stream has been drained. + + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR -> + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR + Occurs when the producer inserts a new image frame and only + previously consumed frames are available. + + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR -> + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR + Occurs when the consumer begins examining the last unconsumed + frame and reuse of old frames is enabled. + +Add entries to the list of state transitions in "3.10.4.3 +EGL_STREAM_STATE_KHR Attribute" + + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR -> + EGL_STREAM_STATE_EMPTY_KHR + Occurs when the stream is reset. + + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR -> + EGL_STREAM_STATE_EMPTY_KHR + Occurs when the stream is reset or, if reuse of old frames is + disabled, when the consumer begins examining the last unconsumed + frame. + +Add new sections at the end of section "3.10.4 EGLStream Attributes" + + 3.10.4.x EGL_SUPPORT_RESET_NV Attribute + + The EGL_SUPPORT_RESET_NV attribute may only be set when the stream + is created. By default, it is EGL_FALSE. If set to EGL_TRUE, the + stream will allow restoration of the stream state back to + EGL_STREAM_STATE_EMPTY_KHR state from + EGL_STREAM_STATE_OLD_FRAME_AVAILABLE_KHR or + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR, releasing existing frames, + as described in section 3.10.5.x. + + Not all consumers are required to support stream resets. Attempting + to attach a consumer which does not support resets to a stream with + EGL_SUPPORT_RESET_NV set to EGL_TRUE will fail with an + EGL_BAD_MATCH error. + + Not all producers will provide a means to reset streams themselves, + but any producer may be connected to a stream which supports resets + and may be used with the eglStreamResetNV function. + + 3.10.4.x+1 EGL_SUPPORT_REUSE_NV Attribute + + The EGL_SUPPORT_REUSE_NV attribute may only be set when the stream + is created. By default, it is EGL_TRUE. If EGL_TRUE, then when the + consumer acquires the last available image frame from the stream, it + will be held for reuse until a new frame is inserted to replace it. + If EGL_FALSE, no frames will be available to the consumer until the + producer inserts a new one. + +Modify third paragraph of "3.10.5.1 EGLStream operation in mailbox mode" + + The consumer retrieves the image frame from the mailbox and + examines it. When the consumer is finished examining the image + frame it is either placed back in the mailbox (if the mailbox is + empty, supports reuse of frames, and has not been reset) or + discarded (otherwise). + +If EGL_KHR_stream_fifo is present, insert at beginning of fourth paragraph +of "3.10.5.2 EGLStream operation in fifo mode" + + If the EGL_SUPPORT_REUSE_NV attribute is EGL_TRUE and the stream has + not been reset since the image frame was consumed, then if the fifo + is empty ... + +Insert a new paragraph after the above + + If the EGL_SUPPORT_REUSE_NV attribute is EGL_FALSE or the stream has + been reset, then if the fifo is empty when the consumer is finished + consuming an image frame, the frame is discarded and the stream is + left in the EGL_STREAM_STATE_EMPTY_KHR state until new frames are + produced. + +Add a new section to "3.10.5 EGLStream operation" + + 3.10.5.x EGLStream reset + + For resource management or safety reasons, it may be necessary to + invalidate and reclaim frames pending in the stream. This is only + possible if the stream's EGL_SUPPORT_RESET_NV attribute is set to + EGL_TRUE. + + Stream resets cause any unconsumed image frames waiting in the + stream to be immediately discarded, and place the stream in the + EGL_STREAM_STATE_EMPTY_KHR state. Frames currently held by the + consumer are not immediately affected, but will be discarded once + released, even if the stream would normally hold old frames for + reuse. After the reset, new frames inserted by the producer are + processed normally. + + Stream resets may be issued by some producers as described in their + specifications, and may also be triggered by the application calling + + EGLBoolean eglResetStreamNV( + EGLDisplay dpy, + EGLStreamKHR stream) + + On success, EGL_TRUE is returned and a reset of the stream is + initiated. On failure, EGL_FALSE is returned and an error is + generated. + + - EGL_BAD_DISPLAY is generated if <dpy> is not a valid + EGLDisplay. + + - EGL_NOT_INITIALIZED is generated if <dpy> is not initialized. + + - EGL_BAD_STREAM_KHR is generated if <stream> is not a valid + EGLStream created for <dpy>. + + - EGL_BAD_STATE_KHR is generated if <stream> is in + EGL_STREAM_STATE_CREATED_KHR, EGL_STREAM_STATE_CONNECTING_KHR, + or EGL_STREAM_STATE_DISCONNECTED_KHR state. + + - EGL_BAD_ACCESS is generated if <stream>'s + EGL_SUPPORT_RESET_NV attribute is not EGL_TRUE. + + If a stream is already in the EGL_STREAM_STATE_EMPTY_KHR state, a + reset will have no effect. + +If EGL_KHR_stream_cross_process_fd or EGL_NV_stream_remote is present, +add to the list of errors above + + - EGL_BAD_ACCESS is generated if <stream> represents the + consumer endpoint of a stream whose producer endpoint is + represented by a different EGLStreamKHR handle (e.g. for + cross-process streams). + +If EGL_KHR_stream_consumer_gltexture is supported, modify the first +sentence of the fifth paragraph of the description of +eglStreamConsumerAcquireKHR + + If the producer has not inserted any new image frames since the + last call to eglStreamConsumerAcquireKHR, and the stream has been + reset or does not support reuse of frames, then + eglStreamConsumerAcquireKHR will fail. If it has not been reset and + reuse is supported, then eglStreamConsumerAcquireKHR will "latch" + the same image frame it latched last time + eglStreamConsumerAcquireKHR was called. + +If EGL_EXT_stream_consumer_egloutput is supported, add to the +description if eglStreamConsumerOutputEXT + + If the stream is reset to the EGL_STREAM_STATE_EMPTY_KHR state, any + currently displayed frame will be released, and the displayed image + will be reset to some default state determined by the display + hardware and the implementation. Possible behavior includes, but is + not limited to, displaying a black screen, displaying a default + splash screen, displaying a "no input" message, or powering off the + display. If and when the stream again enters the + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR state, processing of frames + will resume as described above. + +Issues + + 1. When this extension is present, should all streams automatically + support resetting? + + RESOLVED: No. Applications which are not aware of this extension + may not be prepared to handle an unexpected return to the EMPTY + state. Therefore support for this feature must be explicitly + requested. + +Revision History + + #6 (October 27, 2016) Daniel Kartch + - Clean up for publication + + #5 (July 23rd, 2015) Daniel Kartch + - Added interaction with cross-process streams. + + #4 (July 22nd, 2015) Daniel Kartch + - Added enum values. + + #3 (July 20th, 2015) Daniel Kartch + - Changed to NV specification + - Removed flush option from eglResetStream. Resetting will + always flush pending frames. + - Added EGL_SUPPORT_REUSE_NV flag to control whether released + frames are saved or discarded immediately. + - Removed reference to unpublished stream_sequence extension. + + #2 (August 21th, 2014) Daniel Kartch + - Added paragraph to indicate that producers do not impose + restrictions on use of reset. + - Clarified consumer behavior on reset. + - Added interactions with GL texture and EGLOutput consumers. + + #1 (August 12th, 2014) Daniel Kartch + - Initial draft diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_socket.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_socket.txt new file mode 100644 index 0000000..2d5e209 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_socket.txt @@ -0,0 +1,229 @@ +Name + + NV_stream_socket + NV_stream_socket_unix + NV_stream_socket_inet + +Name Strings + + EGL_NV_stream_socket + EGL_NV_stream_socket_unix + EGL_NV_stream_socket_inet + +Contributors + + Daniel Kartch + Bogdan Naodovic + James Jones + Zander Clucas + Tarun Bansal + +Contacts + + Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) + +Status + + Draft + +Version + + Version 6 - October 27, 2016 + +Number + + EGL Extension #115 + +Extension Type + + EGL display extension + +Dependencies + + EGL_NV_stream_socket requires EGL_NV_stream_remote. + + EGL_NV_stream_socket_unix requires EGL_NV_stream_socket. + + EGL_NV_stream_socket_inet requires EGL_NV_stream_socket. + +Overview + + These extensions build on the framework for remote streams provided + in EGL_NV_stream_remote to define a means for two EGLStream objects + representing opposite ends of a single stream to establish + communication using a socket. The application is expected to create + and connnect both ends of the socket before creating the stream + objects. + + The base EGL_NV_stream_socket extension defines most of the + attributes required to initialize the stream objects. The + EGL_NV_stream_socket_unix and EGL_NV_stream_socket_inet extensions + indicate support for UNIX domain and internet protocol socket types, + respectively. Additional extensions may provide support for other + socket types. The type of socket is important, as certain operations + are only available with certain types, which may influence how the + streams are implemented. For instance, UNIX domain sockets allow + file descriptors to be passed between processes, while internet + protocol sockets do not. This ability may allow more efficient + sharing of resources between the socket endpoints. + + An application using this extension will bear some similarity to the + example code from the EGL_KHR_stream_cross_process_fd extension, + which also uses sockets to establish the communication between two + processes and then create a pair of EGLStream objects. The key + difference is that in that case, the sockets are merely a temporary + means to an end to pass a file descriptor between the processes. + Once that is accomplished, the sockets are discarded. + + The file descriptor used by that extension may represent an + underlying object such as shared memory which allows more efficient + communication than the sockets themselves. However, there is nothing + preventing an implementation of EGL_NV_stream_socket from creating + and passing such a file descriptor as well, gaining the same + efficiency. Therefore, a protocol based on sockets will work at + least as well as one based on file descriptors, with the added + benefit of being more portable. + +New Types + + None + +New Functions + + None + +New Tokens for EGL_NV_stream_socket + + Accepted by eglCreateStreamKHR and returned by eglQueryStreamKHR + when attribute is EGL_STREAM_PROTOCOL_NV: + + EGL_STREAM_PROTOCOL_SOCKET_NV 0x324B + + Accepted as attribute names by eglCreateStreamKHR and + eglQueryStreamKHR functions + + EGL_SOCKET_HANDLE_NV 0x324C + EGL_SOCKET_TYPE_NV 0x324D + +New Tokens for EGL_NV_stream_socket_unix + + Accepted by eglCreateStreamKHR and returned by eglQueryStreamKHR + when attribute is EGL_SOCKET_TYPE_NV: + + EGL_SOCKET_TYPE_UNIX_NV 0x324E + +New Tokens for EGL_NV_stream_socket_inet + + Accepted by eglCreateStreamKHR and returned by eglQueryStreamKHR + when attribute is EGL_SOCKET_TYPE_NV: + + EGL_SOCKET_TYPE_INET_NV 0x324F + +Add to list of failures in section "3.10.1 Creating an EGLStream" in EGL_KHR stream: + + - EGL_BAD_MATCH is generated if the value of EGL_STREAM_PROTOCOL_NV + is EGL_STREAM_PROTOCOL_SOCKET_NV and values are not provided for + EGL_SOCKET_HANDLE_NV and EGL_SOCKET_TYPE_NV. + +Add to "Table 3.10.4.4 EGLStream Attributes" in EGL_KHR_stream: + + Attribute Read/Write Type Section + -------------------------- ---------- ------ ---------- + EGL_SOCKET_HANDLE_NV io EGLint 3.10.4.y + EGL_SOCKET_TYPE_NV io EGLint 3.10.4.y+1 + +In section "3.10.4.x+1 EGL_STREAM_PROTOCOL_NV Attribute" of +EGL_NV_stream_remote, add EGL_STREAM_PROTOCOL_SOCKET_NV to the list of +legal values and add + + A value of EGL_STREAM_PROTOCOL_SOCKET_NV indicates that the stream + is a remote stream whose communication is established using a socket + connection provided by the application. The details of the messages + passed through the socket are implementation dependent, and may be + influenced by the stream and socket types. This value for the + EGL_STREAM_PROTOCOL_NV attribute is compatible with values of + EGL_STREAM_CROSS_OBJECT_NV, EGL_STREAM_CROSS_DISPLAY_NV, + EGL_STREAM_CROSS_PROCESS_NV, and EGL_STREAM_CROSS_PARTITION_NV for + the EGL_STREAM_TYPE_NV attribute. + +Add new subsections to the end of section "3.10.4 EGLStream Attributes" +in EGL_KHR_stream: + + 3.10.4.y EGL_SOCKET_HANDLE_NV Attribute + + The EGL_SOCKET_HANDLE_NV attribute may be set when the stream + is created, and provides the handle to a blocking socket which will + be used to communicate with the other endpoint of the stream. If the + value of EGL_STREAM_PROTOCOL_NV is not EGL_STREAM_PROTOCOL_SOCKET_NV, + this attribute is ignored. + + The type of this value is operating system dependent, and the + default value will be an invalid socket handle for the operating + system. In particular, for unix-like operating systems, the value is + a socket file descriptor as returned by socket() and related + functions, and the default value is -1. + + Prior to creating the EGLStream object, the application may use the + socket handle as it wishes. But once the EGLStream object has been + successfully created, it assumes full ownership of this socket. If + the application subsequently writes to, reads from, or closes the + socket, undefined behavior will result. Furthermore, if any data + sent over the socket prior to creating the EGLStream object is not + consumed before the opposite EGLStream object is created, undefined + behavior will result. + + When the EGLStream object is deleted, the socket handle will be + closed by the stream. + + 3.10.4.y+1 EGL_SOCKET_TYPE_NV Attribute + + The EGL_SOCKET_TYPE_NV attribute may be set when the stream is + created, and indicates the type of the socket provided by the + EGL_STREAM_SOCKET_HANDLE_NV attribute. If the value of + EGL_STREAM_PROTOCOL_NV is not EGL_STREAM_PROTOCOL_SOCKET_NV this + attribute is ignored. + + The default value is EGL_NONE. + +If EGL_NV_stream_socket_unix is present, add to section "3.10.4.y+1 +EGL_SOCKET_TYPE_NV Attribute" above: + + A value of EGL_SOCKET_TYPE_UNIX_NV indicates that the socket handle + represents a Unix domain socket, created with SOCK_STREAM type. + +If EGL_NV_stream_socket_inet is present, add to section "3.10.4.y+1 +EGL_SOCKET_TYPE_NV Attribute" above: + + A value of EGL_SOCKET_TYPE_INET_NV indicates that the socket handle + represents an internet protocol socket, created with SOCK_STREAM + type. + +Issues + + None + +Revision History + + #6 (October 27, 2016) Daniel Kartch + - Indicate that the socket handle provided should represent + a blocking socket. + + #5 (June 7, 2016) Daniel Kartch + - Add contact and clean up in preparation for publication. + + #4 (September 16, 2015) Zander Clucas + - Indicated STREAM_SOCKET_PROTOCOL as compatible with socket + type CROSS_PROCESS. + + #3 (December 16, 2014) Daniel Kartch + - Refined overview to clarify comparison with + EGL_KHR_cross_process_fd. + - Indicated SOCK_STREAM as a requirement for the socket types. + + #2 (December 11, 2014) Daniel Kartch + - Rewrote as NV draft for earlier release. + - Reserved enum values. + + #1 (October 10, 2014) Daniel Kartch + - Initial EXT draft + diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_sync.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_sync.txt new file mode 100644 index 0000000..5604c4d --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_stream_sync.txt @@ -0,0 +1,198 @@ +Name + + NV_stream_sync + +Name Strings + + EGL_NV_stream_sync + +Contributors + + Acorn Pooley + Marcus Lorentzon + +Contacts + + Ian Stewart, NVIDIA (istewart 'at' nvidia.com) + +Status + + Complete + +Version + + Version 6, June 5, 2012 + +Number + + EGL Extension #56 + +Dependencies + + Requires EGL 1.2. + Requires EGL_KHR_stream extension + Requires EGL_KHR_reusable_sync + + This extension is written based on the wording of the EGL 1.2 + specification. + +Overview + + This extension defines a new type of reusable sync object. This + sync object will be signaled each time a new image frame becomes + available in an EGLStream for the consumer to consume. + +New functions + + EGLSyncKHR eglCreateStreamSyncNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLenum type, + const EGLint *attrib_list); + +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_NEW_FRAME_NV 0x321F + + +Add a new paragraph to section "3.8.1 Sync Objects" in the +EGL_KHR_reusable_sync extension, just before the paragraph that +mentions the eglClientWaitSyncKHR function: + + The command + + EGLSyncKHR eglCreateStreamSyncNV( + EGLDisplay dpy, + EGLStreamKHR stream, + EGLenum type, + const EGLint *attrib_list); + + creates a sync object of the specified <type> associated with the + specified display <dpy> and the specified EGLStream <stream>, and + returns a handle to the new object. <attrib_list> is an + attribute-value list specifying other attributes of the sync + object, terminated by an attribute entry EGL_NONE. Attributes not + specified in the list will be assigned their default values. The + state of <stream> must not be EGL_STREAM_STATE_CREATED_KHR or + EGL_STREAM_STATE_DISCONNECTED_KHR. + + If <type> is EGL_SYNC_NEW_FRAME_NV, a stream-new-frame reusable + sync object is created. In this case <attrib_list> must be NULL or + empty (containing only EGL_NONE). Attributes of the reusable + stream-new-frame sync object are set as follows: + + Attribute Name Initial Attribute Value(s) + --------------- -------------------------- + EGL_SYNC_TYPE_KHR EGL_SYNC_NEW_FRAME_NV + EGL_SYNC_STATUS_KHR EGL_UNSIGNALED_KHR + + Any time the state of <stream> transitions to + EGL_STREAM_STATE_NEW_FRAME_AVAILABLE_KHR (from any other state), + the returned stream-new-frame reusable sync object is signaled. + (This effectively means the sync object will become signaled + whenever the producer inserts a new image frame into the + EGLStream.) + + EGL does not automatically unsignal the stream-new-frame reusable + sync object. Generally applications will want to unsignal the + sync object after it has been signaled so that the availability + of the next frame can + be detected. + + 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 <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 <stream> is not a valid EGLStream created for <dpy>, + EGL_NO_SYNC_KHR is returned and an EGL_BAD_STREAM error is + generated. + * If <stream>'s state is EGL_STREAM_STATE_CREATED_KHR or + EGL_STREAM_STATE_DISCONNECTED_KHR then EGL_NO_SYNC_KHR is + returned and an EGL_BAD_ACCESS error is generated. + * If a sync object of <type> has already been created for + <stream> (and not destroyed), EGL_NO_SYNC_KHR is returned and + an EGL_BAD_ACCESS error is generated. + * If <type> is not a supported type of stream sync object, + EGL_NO_SYNC_KHR is returned and an EGL_BAD_ATTRIBUTE error is + generated. + +Issues + 1. Is this extension useful, or does the built in blocking + behavior of the consumer described by the + EGL_NV_stream_consumer_gltexture extension render this + un-useful? + + RESOLVED: Yes. It is useful to have a thread waiting on the + signal. + + 2. Does EGL automatically unsignal the sync object? + + RESOLVED: No. After the sync object has been signaled, it is + up to the application to unsignal it before waiting on it + again. It is important to check for the availability of + another frame by querying EGL_PRODUCER_FRAME_KHR after + unsignaling the sync object and before waiting on the sync + object to prevent a race condition. This can be done using + the following code: + + void ConsumeFrames(EGLDisplay dpy, EGLStreamKHR stream) + { + EGLuint64KHR last_frame = 0; + EGLuint64KHR new_frame = 0; + EGLSyncKHR sync; + + sync = eglCreateStreamSyncNV(dpy, + stream, + EGL_SYNC_NEW_FRAME_NV, + 0); + + for(;;) { + eglSignalSyncKHR(dpy, sync, EGL_UNSIGNALED_KHR); + eglQueryStreamu64KHR(dpy, + stream, + EGL_PRODUCER_FRAME_KHR, + &new_frame); + if (new_frame != last_frame) { + last_frame = new_frame; + ConsumeNewFrame(stream); + } else { + eglClientWaitSyncKHR(dpy, sync, 0, EGL_FOREVER_KHR); + } + } + } + +Revision History + + #7 (July 10, 2013) Jon Leech + - Fix spelling of 'signalled' -> 'signaled' and assign extension + number for publication. + + #6 (June 5, 2012) Acorn Pooley + - Add error if stream is in state EGL_STREAM_STATE_CREATED_KHR + or EGL_STREAM_STATE_DISCONNECTED_KHR when sync is created. + + #5 (September 30, 2011) Acorn Pooley + - Change eglCreateStreamSyncKHR to eglCreateStreamSyncNV + + #4 (September 28, 2011) Acorn Pooley + - Add issue 2 + - Fix return type of eglCreateStreamSyncNV + + #3 (September 27, 2011) Acorn Pooley + - Assign enum values (bug 8064) + + #2 (July 6, 2011) Acorn Pooley + - Rename EGL_KHR_image_stream to EGL_KHR_stream + + #1 (June 30, 2011) Acorn Pooley + - Initial draft + diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_sync.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_sync.txt new file mode 100644 index 0000000..0bf0077 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_sync.txt @@ -0,0 +1,554 @@ +Name + + NV_sync + +Name Strings + + EGL_NV_sync + +Contributors + + Gary King + Gregory Prisament + Acorn Pooley + Jon Leech + +Contacts + + Acorn Pooley, NVIDIA Corporation (apooley 'at' nvidia.com) + Gary King, NVIDIA Corporation (gking 'at' nvidia.com) + +Status + + Complete + +Version + + Version 7, July 27, 2010 + +Number + + EGL Extension #19 + +Dependencies + + Requires EGL 1.1 + + This extension is written against the wording of the EGL 1.2 + Specification. + +Overview + + This extension introduces the concept of "sync objects" into EGL. + Sync objects are a synchronization primitive, representing events + whose completion can be tested or waited upon. This extension + borrows heavily from the GL_ARB_sync extension, and like that + extension, introduces only a single type of sync object, the + "fence sync object." Additional types of sync objects may be + introduced in later extensions. + + Fence sync objects have corresponding fences, which are inserted + into client API command streams. A sync object can be queried + for a given condition, such as completion of the corresponding + fence. Fence completion allows applications to request a partial + Finish of an API command stream, wherein all commands issued in + a particular client API context will be forced to complete before + control is returned to the calling thread. + + This extension is nearly identical to NVIDIA's original proposal for the + EGL_KHR_sync extension, which some minor differences outlined in Issue 7 + below. + +New Types + + /* + * EGLSyncNV is an opaque handle to an EGL sync object + */ + typedef void* EGLSyncNV; + + /* + * EGLTimeNV is a 64-bit unsigned integer representing intervals in + * nanoseconds (unadjusted standard time). A type defined in the + * standard Khronos <KHR/khrplatform.h> header is used instead of + * a less-portable native C type. + */ + #include <KHR/khrplatform.h> + typedef khronos_utime_nanoseconds_t EGLTimeNV; + +New Procedures and Functions + + EGLSyncNV eglCreateFenceSyncNV( EGLDisplay dpy, + EGLenum condition, + const EGLint *attrib_list ); + + EGLBoolean eglDestroySyncNV( EGLSyncNV sync ); + + EGLBoolean eglFenceNV( EGLSyncNV sync ); + + EGLint eglClientWaitSyncNV( EGLSyncNV sync, + EGLint flags, EGLTimeNV timeout ); + + EGLBoolean eglSignalSyncNV( EGLSyncNV sync, EGLenum mode ); + + EGLBoolean eglGetSyncAttribNV( EGLSyncNV sync, EGLint attribute, + EGLint *value ); + + +New Tokens + + Accepted in the <condition> parameter of eglCreateFenceSyncNV, and + returned in <value> when eglGetSyncAttribNV is called with <attribute> + EGL_SYNC_CONDITION_NV: + + EGL_SYNC_PRIOR_COMMANDS_COMPLETE_NV 0x30E6 + + Accepted as an attribute name in the <attrib_list> parameter of + eglCreateFenceSyncNV, and by the <attribute> parameter of + eglGetSyncAttribNV: + + EGL_SYNC_STATUS_NV 0x30E7 + + Accepted as an attribute value in the <attrib_list> parameter of + eglCreateFenceSyncNV for the EGL_SYNC_STATUS_NV attribute, by + the <mode> parameter of eglSignalSyncNV and returned in <value> + when eglGetSyncAttribNV is called with <attribute> + EGL_SYNC_STATUS_NV: + + EGL_SIGNALED_NV 0x30E8 + EGL_UNSIGNALED_NV 0x30E9 + + Accepted in the <flags> parameter of eglClientWaitSyncNV: + + EGL_SYNC_FLUSH_COMMANDS_BIT_NV 0x0001 + + Accepted in the <timeout> parameter of eglClientWaitSyncNV: + + EGL_FOREVER_NV 0xFFFFFFFFFFFFFFFFull + + Returned by eglClientWaitSyncNV: + + EGL_ALREADY_SIGNALED_NV 0x30EA + EGL_TIMEOUT_EXPIRED_NV 0x30EB + EGL_CONDITION_SATISFIED_NV 0x30EC + + Accepted in the <attribute> parameter of eglGetSyncAttribNV: + + EGL_SYNC_TYPE_NV 0x30ED + EGL_SYNC_CONDITION_NV 0x30EE + + Returned in <value> when eglGetSyncAttribNV is called with + <attribute> EGL_SYNC_TYPE_NV: + + EGL_SYNC_FENCE_NV 0x30EF + + Returned by eglCreateFenceSyncNV in the event of an error: + + EGL_NO_SYNC_NV ((EGLSyncNV)0) + + + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add a new subsection at the end of Section 3.8, page 43 + (Synchronization Primitives) + + "3.8.1 Sync Objects + In addition to the aforementioned synchronization functions, which + provide an efficient means of serializing client and native API + operations within a thread, "Sync Objects" are provided to enable + synchronization of client API operations between threads and/or between + API contexts. Sync objects may be tested or waited upon by application + threads. + + Sync objects have a status with two possible states: <signaled> and + <unsignaled>. Events may be associated with a sync object. When an + event is initially associated with a sync object, the object is + unsignaled (its status is set to unsignaled). Once a sync object has + been created, EGL may be asked to wait for a sync object to become + signaled. Sync objects may also be signaled or unsignaled explicitly. + Sync objects are associated with an EGLDisplay; this association + is made when the sync object is created. + + Only one type of sync object is defined, the fence sync object, whose + associated events are triggered by fence commands which are inserted + into the command streams of client API contexts. Fence sync objects may + be used to wait for partial completion of a client API command stream, + as a more flexible form of glFinish / vgFinish. + + The command + + EGLSyncNV eglCreateFenceSyncNV( EGLDisplay dpy, + enum condition, + EGLint *attrib_list ); + + creates a fence sync object for the specified display <dpy> and returns + a handle to the new object. The sync object is assigned a type of + EGL_SYNC_FENCE_NV. <condition> must be + EGL_SYNC_PRIOR_COMMANDS_COMPLETE_NV. <attrib_list> is an attribute-value + list specifying other attributes of the sync object, terminated by an + attribute entry EGL_NONE. Attributes not specified in the list will be + assigned their default values. Attributes accepted by fence sync objects + are listed in table 3.aa + + Attribute Name Attribute Value(s) Default Value + --------------- ------------------------------------ -------------- + EGL_SYNC_STATUS_NV EGL_SIGNALED_NV, EGL_UNSIGNALED_NV EGL_SIGNALED_NV + + Table 3.aa Fence Sync Object Attributes + + * If <dpy> is not the name of a valid, initialized EGLDisplay, + EGL_NO_SYNC_NV is returned and an EGL_BAD_DISPLAY error is generated. + + * If <condition> is not EGL_SYNC_PRIOR_COMMANDS_COMPLETE_NV, + EGL_NO_SYNC_NV is returned and an EGL_BAD_PARAMETER error is generated. + + * If any attribute not appearing in table 3.?? is specified in + <attrib_list>, EGL_NO_SYNC_NV is returned and an EGL_BAD_ATTRIBUTE error is + generated. + + + The command + + EGLBoolean eglFenceNV( EGLSyncNV sync ); + + inserts a fence command into the command stream of the bound API's current + context (i.e., the context returned by eglGetCurrentContext), and + assoicates it with sync object <sync>. <sync> must be a sync object + created with eglCreateFenceSyncNV, and the display associated with <sync> + must match the current display (i.e., the display returned by + eglGetCurrentDisplay). Calling eglFenceNV unsignals <sync>. + + When the condition of <sync> is satisfied by the fence command, <sync> is + signaled by the associated client API context, causing any + eglClientWaitSyncNV commands (see below) blocking on <sync> to unblock. + The condition EGL_SYNC_PRIOR_COMMANDS_COMPLETE_NV 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. <sync> + 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. + + Multiple fence commands may be inserted in any client API command stream + for a single sync object. The sync object is unsignaled every time a new + fence command is issued, and signaled every time a previous fence command + completes, so its status is indeterminate until all fence commands + associated with the sync object have completed. However, each time a fence + command completes (signaling the sync object), at least one + eglClientWaitSyncNV command blocking on that sync object will unblock. + + EGL_TRUE is returned upon successful insertion of the fence command. + + * If <sync> is not a valid sync object with a type of EGL_SYNC_FENCE_NV, + EGL_FALSE is returned and an EGL_BAD_PARAMETER error is generated. + + * If the display associated with <sync> does not match the current + display, EGL_FALSE is returned and an EGL_BAD_MATCH error is generated. + + * If no context is current for the bound API (i.e., eglGetCurrentContext + returns EGL_NO_CONTEXT), EGL_FALSE is returned and an EGL_BAD_MATCH error + is generated. + + The command + + EGLint eglClientWaitSyncNV( EGLSyncNV sync, uint flags, + EGLTimeNV timeout ); + + blocks the calling thread until the specified sync object <sync> is + signaled, or until a specified timeout value expires. If <sync> is + signaled at the time eglClientWaitSyncNV is called then eglClientWaitSyncNV + will not block. If <sync> is unsignaled at the time eglClientWaitSyncNV is + called then eglClientWaitSyncNV will wait up to <timeout> nanoseconds for + <sync> to become signaled. + + If the value of <timeout> is zero, then eglClientWaitSyncNV will never + block and simply tests the current status of <sync>. If the value of + <timeout> is the special value EGL_FOREVER_NV then eglClientWaitSyncNV + does not time out. + + eglClientWaitSyncNV returns one of three status values describing the + reason for returning. A return value of EGL_ALREADY_SIGNALED_NV will + always be returned if <sync> was signaled when eglClientWaitSyncNV was + called, even if <timeout> is zero. A return value of + EGL_TIMEOUT_EXPIRED_NV indicates that indicates that the specified + timeout period expired before <sync> was signaled. A return value of + EGL_CONDITION_SATISFIED_NV indicates that <sync> was signaled before + the timeout expired. + + Note that a fence sync object can be in the signaled state because one of + three events has occured: + + 1. A previously inserte fence has completed and has signaled the sync + object. + 2. The sync object was created. Creation of a sync object sets it in the + signaled state by default, unless the attribute EGL_SYNC_STATUS_NV + is set to EGL_UNSIGNALED_NV in the attribute list. + 3. The sync object was signaled by a previously issued + eglSignalSyncNV(sync, EGL_SIGNALED_NV) command. + + If the sync object being blocked upon will not be signaled in finite time + (for example, by an associated fence command issued previously, but not + yet flushed to the graphics pipeline), then eglClientWaitSyncNV may + wait forever. To help prevent this behavior (footnote1), if the + EGL_SYNC_FLUSH_COMMANDS_BIT_NV bit is set in <flags>, and <sync> is + unsignaled when eglClientWaitSyncNV is called, then the equivalent of + Flush() will be performed for the current API context (i.e., the context + returned by eglGetCurrentContext()) before blocking on <sync>. If no + context is current for the bound API, the EGL_SYNC_FLUSH_COMMANDS_BIT_NV + bit is ignored. + + (footnote 1): The simple Flush behavior defined by + EGL_SYNC_FLUSH_COMMANDS_BIT_NV will not help when waiting for a fence + command issued in a different context's command stream. Applications + which block on a fence sync object must take additional steps to ensure + that the context from which the associated fence command was issued + has flushed that command to the graphics pipeline. + + If a sync object is deleted when an eglClientWaitSyncNV is blocking on + that object, the behavior of eglClientWaitSyncNV is undefined. Some + possible behaviors are to return immediately, to wait for fence commands + associated with the deleted sync to complete, or to not return until the + timeout period expires. + + * If <sync> is not a valid sync object, EGL_FALSE is returned and an + EGL_BAD_PARAMETER error is generated. + + + The command + + EGLBoolean eglSignalSyncNV( EGLSyncNV sync, enum mode ); + + signals or unsignals the sync object <sync> by changing its status to + <mode>, which must be one of the values in table 3.bb. If, as a + result of calling eglSignalSyncNV, the status of <sync> transitions + from unsignaled to signaled, then at least one eglClientWaitSyncNV + commands blocking on <sync> will unblock. + + Assuming no errors are generated, EGL_TRUE is returned. + + Mode Effect + ------------------ ------------- + EGL_SIGNALED_NV Set the status of <sync> to signaled + EGL_UNSIGNALED_NV Set the status of <sync> to unsignaled + + Table 3.bb Modes Accepted by eglSignalSyncNV Command + + * If <sync> is not a valid sync object, EGL_FALSE is returned and an + EGL_BAD_PARAMETER error is generated. + + + The command + + EGLBoolean eglGetSyncAttribNV( EGLSyncNV sync, EGLint attribute, + EGLint *value ); + + is used to query attributes of the sync object <sync>. Legal values for + <attribute> depend on the type of sync object; these are listed in table 3.cc. + Assuming no errors are generated, EGL_TRUE is returned and the value of + the queried attribute is returned in <value>. + + Attribute Description Supported Sync Objects + ----------------- ----------------------- --------------------- + EGL_SYNC_TYPE_NV Type of the sync object All + EGL_SYNC_STATUS_NV Status of the sync object All + EGL_SYNC_CONDITION_NV Signaling condition EGL_SYNC_FENCE_NV + + * If <sync> is not a valid sync object, EGL_FALSE is returned and an + EGL_BAD_PARAMETER error is generated. + + The command + + EGLBoolean eglDestroySyncNV( EGLSyncNV sync ); + + is used to destroy an existing sync object. If any eglClientWaitSyncNV + commands are blocking on <sync> when eglDestroySyncNV is called, their + behavior is undefined. After calling eglDestroySyncNV, <sync> is no + longer a valid sync object. Assuming no errors are generated, EGL_TRUE + is returned. + + * If <sync> is not a valid sync object, EGL_FALSE is returned and an + EGL_BAD_PARAMETER error is generated. + +Issues + + 1. Explain the key choices made in this extension. + + RESPONSE: This extension has been written to enable adoption to be as wide + as possible, and to behave as similarly as possible to synchronization + primitives available in desktop OpenGL (e.g., NV_fence, ARB_sync). + + In the interest of enabling widespread adoption, this extension (following + the ARB_sync model) has foregone the inclusion of synchronization primitives + and synchronization tests which may be performed entirely inside client + API command streams, instead performing synchronization tests + (eglClientWaitSyncNV) inside the application & host CPU. + + In the interest of maintaining similarity with previous synchronization + primitives, this extension attempts to copy the ARB_sync specification + wherever possible (both functionally and stylistically), only making + changes where needed to operate inside EGL (rather than a client API + context) and match EGL naming conventions. + + 2. Why place this behavior in EGL, rather than in the client APIs? + + RESPONSE: Ultimately, synchronization between multiple asynchronous client + API contexts (potentially executing in different threads) is a problem + which affects or will affect all EGL client APIs. Rather than creating + separate synchronization primitives in each of the client APIs (and then + wrapping them in an EGL container), in the interest of developer simplicity + & consistency this behavior is being placed inside EGL. + + 3. What does this extension provide that can not be accomplished with the + existing, more efficient eglWaitClient and eglWaitNative API functions? + + RESPONSE: eglWaitClient and eglWaitNative may be implemented in extremely + lightweight manners, in some cases not blocking the calling thread at + all; however, they can not be used to synchronize between client API + contexts and native APIs executing in separate threads (or simply between + client API contexts executing in separate threads), such as between a + thread with an active OpenGL context and a second thread performing + video decode. + + 4. What does this extension provide that could not be accomplished with + native platform synchronization primitives and the existing client API + Finish commands? + + RESPONSE: This extension provides a lighter-weight mechanism for + synchronizing an application with client API command streams than the + all-or-nothing Finish commands, enabling applications to block until + a subset of issued client API commands have completed. + + 5. Should integration with native platform synchronization objects be + included in this extension, or reserved for future (platform-specific) + extensions? + + RESOLVED: Integration with native platform synchronization objects should + not be part of this extension, but can be added as future layered + extensions if needed. These layered extensions can be platform-specific, + or perhaps OpenKODE based. + + Originally, this extension included the ability to create native platform + synchronization objects from EGLSync objects. This feature was removed + for a few reasons: + + i) The proposed mechanism suggested mapping EGLSync objects to pthread + conditional variables on platforms with pthread support. However, + pthread conditional variables require an associated mutex and there + was no mechanism to relay this associated mutex to the application. + + ii) On certain platforms support for converting to native platform + synchronization objects adds great complexity to the implementation. + + iii) Now that OpenKODE is more mature, it would be better to allow + conversion from EGLSyncNV objects to OpenKODE synchronization + primitives rather than platform-specific ones. We suggest that this + functionality, if needed, be added as a layered extension instead of + being included here. This way, EGL_NV_sync remains minimal and easy + to implement on a variety of platforms. + + 6. Please provide a more detailed description of how ClientWaitSyncNV + behaves. + + RESPONSE: Issue 18 in the ARB_sync specification includes a very + detailed description of ClientWaitSyncARB (the ARB_sync equivalent of + ClientWaitSyncNV). This is provided (unmodified) below: + + Does ClientWaitSyncARB wait on an event, or on sync object + status? What is the meaning of sync object status? + + RESOLVED: ClientWaitSyncARB blocks until the status of the sync + object transitions to the signaled state. Sync object status is + either signaled or unsignaled. More detailed rules describing + signalling follow (these need to be imbedded into the actual + spec language): + + R1) A sync object has two possible status values: signaled or + unsignaled (corresponding to SYNC_STATUS_ARB values of + SIGNALED_ARB or UNSIGNALED_ARB, respectively). + + R2) When created, the state of the sync object is signaled by + default, but may be explicitly set to unsignaled. + + R3) A fence command is inserted into a command stream. A sync + object is not. + + R4) When a fence command is inserted into a command stream using + FenceARB(), the status of the sync object associated with + that fence command is set to the unsignaled state. + + R5) Multiple fence commands can be associated with the same sync + object. + + R6) A fence command, once its condition has been met, will set + its associated sync object to the signaled state. The only + condition currently supported is + SYNC_PRIOR_COMMANDS_COMPLETE_ARB. + + R7) A wait function, such as ClientWaitSyncARB, waits on a sync + object, not on a fence. + + R8) A wait function, such as ClientWaitSyncARB, called on a sync + object in the unsignaled state will block. It unblocks + (note, not "returns to the application") when the sync + object transitions to the signaled state. + + Some of the behaviors resulting from these rules are: + + B1) Calling ClientWaitSyncARB with a timeout of 0 will return + TRUE if the sync object is in the signaled state. Note that + calling ClientWaitSyncARB with a timeout of 0 in a loop can + miss state transitions. + B2) Stacking fences is allowed. Each fence, once its condition + has been met, will set its associated sync object to the + signaled state. If the sync object is already in the + signaled state, it stays in that state. + B3) ClientWaitSyncARB could take a timeout parameter and return + a boolean. If the timeout period has expired, + ClientWaitSyncARB will unblock and return FALSE to the + caller. If ClientWaitSyncARB unblocks because the sync + object it was waiting on is in the signaled state, it will + return TRUE. + B4) We could define a FinishMultipleSync() command that will + unblock once all (or any) of the sync objects passed to it + are in the signaled state (also see issue 12). + B5) We could define a set/resetSyncObject function to manually + set the sync object in the signaled or unsignaled state. + This makes it easy for apps to reuse a sync object in the + multi-context case, so the sync object can be blocked upon + before a fence command is associated with it in the command + stream. + B6) We could define an API to convert a sync object into an OS + specific synchronization primitive (Events on Windows, file + descriptors or X-events or semaphores on Unix?) + + 7) How does this extension differ from (relate to) EGL_KHR_sync: + + RESPONSE: + As of the time of writing this, the EGL_KHR_sync specification has not + been finalized by Khronos and continues to undergo revision. However, + NVIDIA has the functionality outlined in this specification implemented + and has decided to make it available to developers immediately. + + For the most part, EGL_KHR_sync is identical to revision 5 of EGL_KHR_sync + with the following changes: + + a) Enum values are different + b) EGLTimeNV is unsigned long long instead of uint64_t. + c) Behaviour when there are multiple waiting threads is undefined. + +Revision History + +#7 (Jon Leech, July 27, 2010) + - Redefine EGLTimeNV type to use a typedef from the standard + Khronos headers instead of a native C type, for portability. +#6 (Greg Prisament, May 28, 2009) + - Branch spec & turn it into an _NV extension. +#5 (Greg Prisament, July 22, 2008) + - Removed NativeSyncKHR, CreateNativeSyncKHR, and corresponding wording. + - Correct EGLuint to EGLint (EGLuint doesn't exist). +#4 (Jon Leech, November 20, 2007) + - Corrected 'enum' to 'EGLenum' in prototypes. +#3 (Jon Leech, April 5, 2007) + - Added draft Status and TBD Number +#2 (November 27, 2006) + - Changed OES token to KHR + diff --git a/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_system_time.txt b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_system_time.txt new file mode 100644 index 0000000..2f45147 --- /dev/null +++ b/engine-ocean/External/glew/auto/EGL-Registry/extensions/NV/EGL_NV_system_time.txt @@ -0,0 +1,99 @@ +Name + + NV_system_time + +Name Strings + + EGL_NV_system_time + +Contact + + Jason Allen, NVIDIA Corporation (jallen 'at' nvidia.com) + +Status + + TBD + +Version + + Version 1, July 7, 2011 + +Number + + EGL Extension #31 + +Dependencies + + Requires EGL 1.2 + +Overview + + This extension exposes an alternative method of querying the system time + from the driver instead of the operating system. + +Issues + + Add 64 bit types? + + Yes, EGL doesn't support any 64 bit types so this extension adds int64 + and uint64 types. + +New Types + + EGLint64NV: 64bit signed integer + EGLuint64NV: 64bit unsigned integer + +New Procedures and Functions + + EGLuint64NV eglGetSystemTimeFrequencyNV(void); + EGLuint64NV eglGetSystemTimeNV(void); + +New Tokens + + None + +Description + + The command: + + EGLuint64NV eglGetSystemTimeFrequencyNV(void); + + returns the frequency of the system timer, in counts per second. The + frequency will not change while the system is running. + + The command: + + EGLuint64NV eglGetSystemTimeNV(void); + + returns the current value of the system timer. The system time in seconds + can be calculated by dividing the returned value by the frequency returned + by the eglGetSystemTimeFrequencyNV command. + + Multiple calls to eglGetSystemTimeNV may return the same values, applications + need to be careful to avoid divide by zero errors when using the interval + calculated from successive eglGetSystemTimeNV calls. + +Usage Example + + EGLuint64NV frequency = eglGetSystemTimeFrequencyNV(); + + loop + { + EGLuint64NV start = eglGetSystemTimeNV() / frequency; + + // draw + + EGLuint64NV end = eglGetSystemTimeNV() / frequency; + + EGLuint64NV interval = end - start; + if (interval > 0) + update_animation(interval); + + eglSwapBuffers(dpy, surface); + } + +Revision History + +#1 (Jon Leech, 2011/07/07) + - Add missing fields, assign extension number, and publish in the registry. + |