| Name |
| |
| EXT_external_objects |
| |
| Name Strings |
| |
| GL_EXT_memory_object |
| GL_EXT_semaphore |
| |
| Contributors |
| |
| Carsten Rohde, NVIDIA |
| Dave Airlie, Red Hat |
| James Jones, NVIDIA |
| Jan-Harald Fredriksen, ARM |
| Jeff Juliano, NVIDIA |
| Michael Worcester, Imagination Technologies |
| |
| Contact |
| |
| James Jones, NVIDIA (jajones 'at' nvidia.com) |
| |
| Status |
| |
| Complete |
| |
| Version |
| |
| Last Modified Date: June 28, 2017 |
| Revision: 12 |
| |
| Number |
| |
| 503 |
| OpenGL ES Extension #280 |
| |
| Dependencies |
| |
| Written against the OpenGL 4.5 and OpenGL ES 3.2 specifications. |
| |
| GL_EXT_memory_object requires ARB_texture_storage or a version of |
| OpenGL or OpenGL ES that incorporates it. |
| |
| GL_EXT_semaphore requires OpenGL 1.0. |
| |
| ARB_direct_state_access (OpenGL) interacts with GL_EXT_memory_object |
| when OpenGL < 4.5 is used. |
| |
| ARB_sparse_texture (OpenGL) interacts with GL_EXT_memory_object |
| |
| EXT_sparse_texture (OpenGL ES) interacts with GL_EXT_memory_object |
| |
| EXT_protected_textures (OpenGL ES) interacts with GL_EXT_memory_object |
| |
| Overview |
| |
| The Vulkan API introduces the concept of explicit memory objects and |
| reusable synchronization objects. This extension brings those |
| concepts to the OpenGL API via two new object types: |
| |
| Memory objects |
| Semaphores |
| |
| Rather than allocating memory as a response to object allocation, |
| memory allocation and binding are two separate operations in Vulkan. |
| This extension allows an OpenGL application to import a Vulkan |
| memory object, and to bind textures and/or buffer objects to it. |
| |
| No methods to import memory objects are defined here. Separate |
| platform-specific extensions are defined for this purpose. |
| |
| Semaphores are synchronization primitives that can be waited on and |
| signaled only by the GPU, or in GL terms, in the GL server. They |
| are similar in concept to GL's "sync" objects and EGL's "EGLSync" |
| objects, but different enough that compatibilities between the two |
| are difficult to derive. |
| |
| Rather than attempt to map Vulkan semaphores on to GL/EGL sync |
| objects to achieve interoperability, this extension introduces a new |
| object, GL semaphores, that map directly to the semantics of Vulkan |
| semaphores. To achieve full image and buffer memory coherence with |
| a Vulkan driver, the commands that manipulate semaphores also allow |
| external usage information to be imported and exported. |
| |
| New Procedures and Functions |
| |
| The following commands are added if either of the GL_EXT_memory_object |
| or GL_EXT_semaphore strings are reported: |
| |
| void GetUnsignedBytevEXT(enum pname, |
| ubyte *data); |
| |
| void GetUnsignedBytei_vEXT(enum target, |
| uint index, |
| ubyte *data); |
| |
| If the GL_EXT_memory_object string is reported, the following |
| commands are added: |
| |
| void DeleteMemoryObjectsEXT(sizei n, |
| const uint *memoryObjects); |
| |
| boolean IsMemoryObjectEXT(uint memoryObject); |
| |
| void CreateMemoryObjectsEXT(sizei n, |
| uint *memoryObjects); |
| |
| void MemoryObjectParameterivEXT(uint memoryObject, |
| enum pname, |
| const int *params); |
| |
| void GetMemoryObjectParameterivEXT(uint memoryObject |
| enum pname, |
| int *params); |
| |
| void TexStorageMem2DEXT(enum target, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| uint memory, |
| uint64 offset); |
| |
| void TexStorageMem2DMultisampleEXT(enum target, |
| sizei samples, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| boolean fixedSampleLocations, |
| uint memory, |
| uint64 offset); |
| |
| void TexStorageMem3DEXT(enum target, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| sizei depth, |
| uint memory, |
| uint64 offset); |
| |
| void TexStorageMem3DMultisampleEXT(enum target, |
| sizei samples, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| sizei depth, |
| boolean fixedSampleLocations, |
| uint memory, |
| uint64 offset); |
| |
| void BufferStorageMemEXT(enum target, |
| sizeiptr size, |
| uint memory, |
| uint64 offset); |
| |
| [[ The following are added if direct state access is supported ]] |
| |
| void TextureStorageMem2DEXT(uint texture, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| uint memory, |
| uint64 offset); |
| |
| void TextureStorageMem2DMultisampleEXT(uint texture, |
| sizei samples, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| boolean fixedSampleLocations, |
| uint memory, |
| uint64 offset); |
| |
| void TextureStorageMem3DEXT(uint texture, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| sizei depth, |
| uint memory, |
| uint64 offset); |
| |
| void TextureStorageMem3DMultisampleEXT(uint texture, |
| sizei samples, |
| enum internalFormat, |
| sizei width, |
| sizei height, |
| sizei depth, |
| boolean fixedSampleLocations, |
| uint memory, |
| uint64 offset); |
| |
| void NamedBufferStorageMemEXT(uint buffer, |
| sizeiptr size, |
| uint memory, |
| uint64 offset); |
| |
| [[ The following are available in OpenGL only ]] |
| |
| void TexStorageMem1DEXT(enum target, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| uint memory, |
| uint64 offset); |
| |
| [[ The following are availble in OpenGL only, and only when |
| direct state access is available ]] |
| |
| void TextureStorageMem1DEXT(uint texture, |
| sizei levels, |
| enum internalFormat, |
| sizei width, |
| uint memory, |
| uint64 offset); |
| |
| If the GL_EXT_semaphore string is reported, the following |
| commands are added: |
| |
| void GenSemaphoresEXT(sizei n, |
| uint *semaphores); |
| |
| void DeleteSemaphoresEXT(sizei n, |
| const uint *semaphores); |
| |
| boolean IsSemaphoreEXT(uint semaphore); |
| |
| void SemaphoreParameterui64vEXT(uint semaphore, |
| enum pname, |
| const uint64 *params); |
| |
| void GetSemaphoreParameterui64vEXT(uint semaphore, |
| enum pname, |
| uint64 *params); |
| |
| void WaitSemaphoreEXT(uint semaphore, |
| uint numBufferBarriers, |
| const uint *buffers, |
| uint numTextureBarriers, |
| const uint *textures, |
| const GLenum *srcLayouts); |
| |
| void SignalSemaphoreEXT(uint semaphore, |
| uint numBufferBarriers, |
| const uint *buffers, |
| uint numTextureBarriers, |
| const uint *textures, |
| const GLenum *dstLayouts); |
| |
| New Tokens |
| |
| If the GL_EXT_memory_object string is reported, the following tokens are |
| added: |
| |
| Accepted by the <pname> parameter of TexParameter{ifx}{v}, |
| TexParameterI{i ui}v, TextureParameter{if}{v}, TextureParameterI{i ui}v, |
| GetTexParameter{if}v, GetTexParameterI{i ui}v, GetTextureParameter{if}v, |
| and GetTextureParameterI{i ui}v: |
| |
| TEXTURE_TILING_EXT 0x9580 |
| |
| Accepted by the <pname> parameter of MemoryObjectParameterivEXT, and |
| GetMemoryObjectParameterivEXT: |
| |
| DEDICATED_MEMORY_OBJECT_EXT 0x9581 |
| |
| [[ The following are available when GL_EXT_protected_textures is |
| available ]] |
| |
| PROTECTED_MEMORY_OBJECT_EXT 0x959B |
| |
| Accepted by the <pname> parameter of GetInternalFormativ or |
| GetInternalFormati64v: |
| |
| NUM_TILING_TYPES_EXT 0x9582 |
| TILING_TYPES_EXT 0x9583 |
| |
| Returned in the <params> parameter of GetInternalFormativ or |
| GetInternalFormati64v when the <pname> parameter is TILING_TYPES_EXT, |
| returned in the <params> parameter of GetTexParameter{if}v, |
| GetTexParameterI{i ui}v, GetTextureParameter{if}v, and |
| GetTextureParameterI{i ui}v when the <pname> parameter is |
| TEXTURE_TILING_EXT, and accepted by the <params> parameter of |
| TexParameter{ifx}{v}, TexParameterI{i ui}v, TextureParameter{if}{v}, |
| TextureParameterI{i ui}v when the <pname> parameter is |
| TEXTURE_TILING_EXT: |
| |
| OPTIMAL_TILING_EXT 0x9584 |
| LINEAR_TILING_EXT 0x9585 |
| |
| The following tokens are added if either of the GL_EXT_memory_object or |
| GL_EXT_semaphore strings are reported: |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetDoublev, GetFloatv, |
| GetIntegerv, GetInteger64v, GetUnsignedBytevEXT, and the <target> |
| parameter of GetBooleani_v, GetIntegeri_v,GetFloati_v, GetDoublei_v, |
| GetInteger64i_v, and GetUnsignedBytei_vEXT: |
| |
| NUM_DEVICE_UUIDS_EXT 0x9596 |
| DEVICE_UUID_EXT 0x9597 |
| DRIVER_UUID_EXT 0x9598 |
| |
| Constant values: |
| |
| UUID_SIZE_EXT 16 |
| |
| If the GL_EXT_semaphore string is reported, the following tokens are |
| added: |
| |
| Accepted by the <dstLayouts> parameter of SignalSemaphoreEXT and the |
| <srcLayouts> parameter of WaitSemaphoreEXT: |
| |
| LAYOUT_GENERAL_EXT 0x958D |
| LAYOUT_COLOR_ATTACHMENT_EXT 0x958E |
| LAYOUT_DEPTH_STENCIL_ATTACHMENT_EXT 0x958F |
| LAYOUT_DEPTH_STENCIL_READ_ONLY_EXT 0x9590 |
| LAYOUT_SHADER_READ_ONLY_EXT 0x9591 |
| LAYOUT_TRANSFER_SRC_EXT 0x9592 |
| LAYOUT_TRANSFER_DST_EXT 0x9593 |
| |
| Additions to Chapter 2 of the OpenGL 4.5 Specification (OpenGL |
| Fundamentals) |
| |
| Add two new sections after 2.6.13 (Sync Objects) |
| |
| 2.6.14 Semaphore Objects |
| |
| A /semaphore object/ is a synchronization primitive similar to a |
| /sync object/, but with semantics based on Vulkan semaphores. |
| |
| Semaphore objects may be shared. They are described in detail in |
| section XXX. |
| |
| 2.6.15 Memory Objects |
| |
| Many GL objects have some associated data stored in GL server |
| memory. /Memory objects/ are an abstract representation of GL |
| server memory suitable for use as the backing store of a |
| /buffer object/, a /texture object/, or both, depending on how |
| the memory referred to by the object was allocated. Memory |
| objects can not be created directly within the GL. They must be |
| imported from an API capable of allocating abstract memory, such |
| as Vulkan. |
| |
| Memory objects may be shared. They are described in detail in |
| Chapter 6 (Memory Objects). |
| |
| Additions to Chapter 4 of the OpenGL 4.5 Specification (Event Model) |
| |
| Add a new section between sections 4.1, "Sync Objects and Fences" |
| and section 4.2, "Query Objects and Asynchronous Queries" |
| |
| 4.2 Semaphore Objects |
| |
| Like sync objects, a semaphore object acts as a /synchronization |
| primitive/. However, semaphore objects differ from sync objects |
| in several ways: |
| |
| * They may only be created by importing an external semaphore |
| handle into the GL. |
| |
| * They are reusable. |
| |
| * As a corollary to the above behavior, separate commands are |
| provided to create and signal semaphore objects. |
| |
| * Their state is reset upon completion of a wait operation. |
| |
| * As a corollary to the above behavior, only a single waiter may |
| be associated with a unique signal command. |
| |
| * There is no way to wait for a semaphore to become signaled in |
| the GL client. All waits operations execute in the GL server, |
| and semaphores have no queryable state. |
| |
| The command |
| |
| void GenSemaphoresEXT(sizei n, |
| uint *semaphores); |
| |
| returns <n> previous unused semaphore names in <semaphores>. |
| These names are marked as used, for the purposes of |
| GenSemaphoresEXT only, but they are associated with semaphore |
| state only when an external semaphore handle is imported to |
| them. |
| |
| Semaphore objects are deleted by calling |
| |
| void DeleteSemaphoresEXT(sizei n, |
| const uint *semaphores); |
| |
| <semaphores> contains <n> names of semaphores to be deleted. |
| After a semaphore is deleted, it unreferences any external |
| semaphore state it referenced, and its name is again unused. |
| Unused names in <semaphores> are silently ignored, as is the |
| value zero. |
| |
| The command |
| |
| boolean IsSemaphoreEXT(uint semaphore); |
| |
| returns TRUE if <semaphore> is the name of a semaphore. If |
| <semaphore> is zero, or if <semaphore> is a non-zero value that |
| is not the name of a semaphore, IsSemaphore returns FALSE. |
| |
| 4.2.1 Importing External Semaphore Handles into Semaphores |
| |
| A semaphore is created by importing an external semaphore object |
| via a reference to its associated external handle. The |
| supported set of external handle types and associated import |
| functions are listed in table 4.2. |
| |
| Table 4.2: Commands for importing external semaphore handles. |
| |
| | Handle Type | Import command | |
| +-------------+----------------+ |
| +-------------+----------------+ |
| |
| Applications must only import external semaphore handles exported |
| from the same device or set of devices used by the current context, |
| and from compatible driver versions. To determine which devices are |
| used by the current context, first call GetIntegerv with <pname> set |
| to NUM_DEVICE_UUIDS_EXT, then call GetUnsignedBytei_vEXT with <target> |
| set to DEVICE_UUID_EXT, <index> set to a value in the range [0, |
| <number of device UUIDs>), and <data> set to point to an array of |
| UUID_SIZE_EXT unsigned bytes. To determine the driver ID of the |
| current context, call GetUnsignedBytevEXT with <pname> set to |
| DRIVER_UUID_EXT and <data> set to point to an array of UUID_SIZE_EXT |
| unsigned bytes. |
| |
| These device and driver ID values can be used to correlate devices |
| and determine driver compatibility across process and API boundaries. |
| |
| External handles are often defined using platform-specific |
| types. Therefore, the base GL specification defines no methods |
| to import an external handle. |
| |
| 4.2.2 Semaphore Parameters |
| |
| Semaphore parameters control how semaphore wait and signal |
| operations behave. Table 4.3 defines which parameters are available |
| for a semaphore based on the external handle type from which it was |
| imported. Semaphore parameters are set using the command |
| |
| void SemaphoreParameterui64vEXT(uint semaphore, |
| enum pname, |
| const uint64 *params); |
| |
| <semaphore> is the name of the semaphore object on which the |
| parameter <pname> will be set to the value(s) in <pname>. |
| |
| Table 4.3: Semaphore parameters |
| |
| | Name | External Handle Types | Legal Values | |
| +------+-----------------------+--------------+ |
| +------+-----------------------+--------------+ |
| |
| Parameters of a semaphore object may be queried with the command |
| |
| void GetSemaphoreParameterui64EXT(uint semaphore, |
| enum pname, |
| uint64 *params); |
| |
| <semaphore> is the semaphore object from with the parameter <pname> |
| is queried. The value(s) of the parameter are returned in <params>. |
| <pname> may be any value in table 4.3. |
| |
| 4.2.3 Waiting for Semaphores |
| |
| The command |
| |
| void WaitSemaphoreEXT(uint semaphore, |
| uint numBufferBarriers, |
| const uint *buffers, |
| uint numTextureBarriers, |
| const uint *textures, |
| const GLenum *srcLayouts); |
| |
| Returns immediately but causes GL server to block until |
| <semaphore> is signaled. If an error occurs, WaitSemaphore |
| generates a GL error as specified below, and does not cause the |
| GL server to block. |
| |
| After completion of the semaphore wait operation, the semaphore |
| will be returned to the unsignaled state. Calling WaitSemaphore on |
| a semaphore that has not previously had a signal operation flushed |
| to the GL server or submitted by an external semaphore signaler |
| since the semaphore was created or last waited on results in |
| undefined behavior. |
| |
| Following completion of the semaphore wait operation, memory will |
| also be made visible in the specified buffer and texture objects. |
| Since texture layout state is managed internally by the GL, but may |
| have been modified by an external API, the current layout of the |
| textures must be specified to initialize internal GL state prior to |
| using the textures after an external access. The valid layouts |
| correspond to those specified by the Vulkan API, as described in |
| table 4.3. However, the layouts do not necessarily correspond to an |
| optimal state for any particular GL operation. The GL will simply |
| perform appropriate transitions internally as necessary based on the |
| specified current layout of the texture. |
| |
| Table 4.4: Texture layouts and corresponding Vulkan Image Layouts |
| |
| | Texture Layout | Equivalent Vulkan Image Layout | |
| +----------------------------------------+-------------------------------------------------+ |
| | GL_NONE | VK_IMAGE_LAYOUT_UNDEFINED | |
| | GL_LAYOUT_GENERAL_EXT | VK_IMAGE_LAYOUT_GENERAL | |
| | GL_LAYOUT_COLOR_ATTACHMENT_EXT | VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL | |
| | GL_LAYOUT_DEPTH_STENCIL_ATTACHMENT_EXT | VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT | |
| | GL_LAYOUT_DEPTH_STENCIL_READ_ONLY_EXT | VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL | |
| | GL_LAYOUT_SHADER_READ_ONLY_EXT | VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL | |
| | GL_LAYOUT_TRANSFER_SRC_EXT | VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL | |
| | GL_LAYOUT_TRANSFER_DST_EXT | VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL | |
| +------------------------------------------------------------------------------------------+ |
| |
| 4.2.4 Signaling Semaphores |
| |
| The command |
| |
| void SignalSemaphoreEXT(uint semaphore, |
| uint numBufferBarriers, |
| const uint *buffers, |
| uint numTextureBarriers, |
| const uint *textures, |
| const GLenum *dstLayouts); |
| |
| will insert a semaphore signaling operation in the GL command |
| stream. |
| |
| Prior to signaling the semaphore, memory used by the specified |
| buffer objects and textures will be made visible, and textures |
| can be transitioned to a specified internal layout to allow |
| applications to access the textures using a consistent layout in |
| an external API or process. Possible layouts are specified in |
| table 4.3, along with their corresponding layout in the Vulkan |
| API. |
| |
| Add a new Chapter, "Memory Objects", between Chapter 5 (Shared Objects |
| and Multiple Contexts) and Chapter 6 (Buffer Objects) |
| |
| Memory objects reference a fixed-size allocation of abstract server |
| memory. The memory may not be accessed directly, but may be bound |
| to other objects that require a data store in server memory. The |
| memory itself is allocated outside the scope of the GL, and is |
| merely referenced by a memory object. |
| |
| The command |
| |
| void CreateMemoryObjectsEXT(sizei n, uint *memoryObjects); |
| |
| returns <n> previously unused memory object names in <memoryObjects>. |
| The memory objects named contain default state, but initially have no |
| external memory associated with them. |
| |
| Memory objects are deleted by calling |
| |
| void DeleteMemoryObjectsEXT(sizei n, const uint *memoryObjects); |
| |
| <memoryObjects> contains <n> names of memory objects to be deleted. |
| After a memory object is deleted, it references no server memory, |
| and its name is again unused. |
| |
| Unused names in <memoryObjects> are silently ignored, as is the |
| value zero. |
| |
| The command |
| |
| boolean IsMemoryObjectEXT(uint memoryObject); |
| |
| returns TRUE if <memoryObject> is the name of a memory object. If |
| <memoryObject> is zero, or if <memoryObject> is a non-zero value |
| that is not the name of a memory object, IsMemoryObjectEXT returns |
| FALSE. |
| |
| 6.1 Importing Abstract Memory into a Memory Object |
| |
| A memory object is associated with external memory by importing an |
| externally-allocated abstract memory region via a reference to an |
| associated external handle. The supported set of external handle types |
| and their corresponding import functions are listed in table 6.1. |
| |
| Table 6.1: Commands for importing external memory handles. |
| |
| | Handle Type | Import command | |
| +-------------+----------------+ |
| +-------------+----------------+ |
| |
| Applications must only import external semaphore handles exported |
| from the same device or set of devices used by the current context. |
| Refer to section 4.2.1 for methods to determine which devices are |
| used by the current context. |
| |
| External handles are often defined using platform-specific types. |
| Therefore, the base GL specification defines no methods to import an |
| external handle. |
| |
| 6.2 Memory object parameters |
| |
| Memory object parameters are set using the command |
| |
| void MemoryObjectParameterivEXT(uint memoryObject, |
| enum pname, |
| const int *params); |
| |
| <memoryObject> is the name of the memory object on which the parameter |
| <pname> will be set to the value(s) in <params>. The possible values for |
| <pname> are specified in table 6.2. |
| |
| Table 6.2: Memory Object Parameters. |
| |
| | Name | Legal Values | |
| +-----------------------------+--------------+ |
| | DEDICATED_MEMORY_OBJECT_EXT | FALSE, TRUE | |
| | PROTECTED_MEMORY_OBJECT_EXT | FALSE, TRUE | |
| +-----------------------------+--------------+ |
| |
| The parameter DEDICATED_MEMORY_OBJECT_EXT must be set to TRUE when the |
| external memory handle from which the object's memory will be imported |
| was created as a dedicated allocation. |
| |
| The parameter PROTECTED_MEMORY_OBJECT_EXT must be set to TRUE when the |
| external memory handle from which the object's memory will be imported |
| refers to a protected resource. The definition of a protected resource |
| is outside the scope of this extension. |
| |
| Memory object parameters become immutable once the object is associated |
| with external memory by an import operation. An INVALID_OPERATION error |
| is generated if <memoryObject> is immutable. |
| |
| The parameters of a memory object may be queried with the command: |
| |
| void GetMemoryObjectParameterivEXT(uint memoryObject |
| enum pname, |
| int *params); |
| |
| The value(s) of the parameter <pname> from the memory object |
| <memoryObject> are returned in <params>. |
| |
| Additions to Chapter 6 of the OpenGL 4.5 Specification (Buffer Objects) |
| |
| Modify the list of commands described in 6.2 "Creating and Modifying |
| Buffer Object Data Stores" to add the following: |
| |
| void BufferStorageMemEXT(enum target, |
| sizeiptr size, |
| uint memory, |
| uint64 offset); |
| |
| void NamedBufferStorageMemEXT(uint buffer, |
| sizeiptr size, |
| uint memory, |
| uint64 offset); |
| |
| Replace the two paragraphs after the above list of commands with the |
| following: |
| |
| "For BufferStorage and BufferStorageMemEXT, the buffer object is |
| that bound to <target>, which must be one of the values listed |
| in table 6.1. For NamedBufferStroage and |
| NamedBufferStorageMemEXT, <buffer> is the name of the buffer |
| object. For all the above commands, <size> is the size of the |
| data store in basic machine units. For BufferStorageMemEXT and |
| NamedBufferStorageMemEXT, <memory> and <offset> define a region |
| of abstract memory that will be used as the data store for |
| <buffer>. The implementation may restrict which values of |
| <offset> are valid for a given memory object and buffer |
| parameter combination. These restrictions are outside the scope |
| of this extension and must be determined by querying the API or |
| mechanism which created the resource which <memory> refers to. |
| If an invalid offset is specified an INVALID_VALUE error is |
| generated. |
| |
| "The data store of the buffer object is allocated or referenced |
| as a result of these commands, and cannot be de-allocated or |
| unreferenced until the buffer is deleted with a call to |
| DeleteBuffers." |
| |
| Replace the paragraph that beings "BufferStorage and |
| NamedBufferStorage delete..." with the following: |
| |
| "BufferStorage, BufferStorageMemEXT, NamedBufferStorage, and |
| NamedBufferStorageMemEXT delete any existing data store, and set |
| the values of the buffer object's state variables as shown in |
| table 6.3." |
| |
| Add the following to the list of errors for the BufferStorage |
| functions" |
| |
| "An INVALID_VALUE error is generated by BufferStorageMemEXT and |
| NamedBufferStorageMemEXT if <memory> is 0, or if <offset> + |
| <size> is greater than the size of the specified |
| memory object. |
| |
| "An INVALID_VALUE error is generated if <offset> is not a valid |
| value for <memory> or the texture." |
| |
| "An INVALID_OPERATION error is generated if <memory> names a valid |
| memory object which has no associated memory." |
| |
| Modify the header for the third column in table 6.2 to read |
| "Value for *BufferStorage*", and update the table description to |
| include the new memory object buffer storage commands. |
| |
| Modify the first sentence of section 6.3, "Mapping and Unmapping |
| Buffer Data", to read as follows: |
| |
| "If the data store for a buffer object is not a reference to a |
| memory object, all or part of the data store may be mapped into |
| the client's address space with the commands:" |
| |
| Add the following to the list of errors for the MapBufferRange and |
| MapNamedBufferRange commands: |
| |
| An INVALID_OPERATION error is generated by Map*BufferRange if |
| the specified buffer is referencing a memory object as its data |
| store. |
| |
| Additions to Chapter 8 of the OpenGL 4.5 Specification (Textures and |
| Samplers) |
| |
| For each list of TexStorage* commands in the 1D, 2D, 3D, |
| 2DMultisample, and 3DMultisample families, add the following |
| variants: |
| |
| void TexStorageMem*EXT(<existing parameters>, |
| uint memory, |
| uint64 offset); |
| |
| void TextureStorageMem*EXT(<existing parameters>, |
| uint memory, |
| uint64 offset); |
| |
| For each family of TexStorage* commands, add appropriate language to |
| the description based on the following template: |
| |
| "Calling TexStorageMem*EXT or TextureStorageMem*EXT is |
| equivalent to calling TexStorage* or TextureStorage* |
| except that rather than allocating new memory for the texture's |
| image data, the memory at <offset> in the memory object |
| specified by <memory> will be used. The implementation may |
| restrict which values of <offset> are valid for a given memory |
| object and texture parameter combination. These restrictions are |
| outside the scope of this extension and must be determined by |
| querying the API or mechanism which created the resource which |
| <memory> refers to. If an invalid offset is specified an |
| INVALID_VALUE error is generated." |
| |
| Add errors based on the following template for each family of |
| TexStorage* commands: |
| |
| "An INVALID_VALUE error is generated if <memory> is 0, or if |
| the memory object is not large enough to contain the specified |
| texture's image data." |
| |
| "An INVALID_VALUE error is generated if <offset> is not a valid |
| value for <memory> or the texture." |
| |
| "An INVALID_OPERATION error is generated if <memory> names a valid |
| memory object which has no associated memory." |
| |
| "An INVALID_OPERATION error is generated if <memory> is a protected |
| memory object and the texture parameter TEXTURE_PROTECTED_EXT is not |
| TRUE." |
| |
| Insert the following before Table 8.17: |
| |
| "If <pname> is TEXTURE_TILING_EXT then the state is stored in the |
| texture, but only takes effect the next time storage is allocated |
| from a memory object for the texture object using TexStorageMem*EXT |
| or TextureStorageMem*EXT. If the value of TEXTURE_IMMUTABLE_FORMAT |
| is TRUE, then TEXTURE_TILING_EXT cannot be changed and an |
| INVALID_OPERATION error is generated." |
| |
| Add the following to table 8.17: Texture parameters and their values. |
| |
| | Name | Type | Legal values | |
| +--------------------+---------+---------------------------------------+ |
| | TEXTURE_TILING_EXT | enum | OPTIMAL_TILING_EXT, LINEAR_TILING_EXT | |
| +--------------------+---------+---------------------------------------+ |
| |
| Additions to Chapter 22 of the OpenGL 4.5 Specification (Context state |
| Queries) |
| |
| Add the following to the end of the first list of functions in section |
| 22.1, Simple Queries: |
| |
| void GetUnsignedBytevEXT(enum pname, |
| ubyte *data); |
| |
| Replace the sentence following that list with: |
| |
| The commands obtain boolean, integer, 64-bit integer, floating- |
| point, double-precision, or unsigned byte state variables. |
| |
| Add the following to the end of the list of indexed simple state query |
| commands: |
| |
| void GetUnsignedBytei_vEXT(enum target, |
| uint index, |
| ubyte *data); |
| |
| |
| |
| Add the following to section 22.3.2, Other Internal Format Queries: |
| |
| NUM_TILING_TYPES_EXT: The number of tiling types that would be |
| returned by querying TILING_TYPES_EXT is returned in <params>. |
| |
| TILING_TYPES_EXT: The tiling type supported when using memory |
| objects to create textures with <internalFormat> and <target> |
| are written to <params>, in the order in which they occur in |
| table 22.3. Possible values are those listed in table 22.3. |
| |
| Table 22.3: Possible tiling types supported by textures using |
| memory objects. |
| |
| | Tiling Type | |
| +--------------------+ |
| | OPTIMAL_TILING_EXT | |
| | LINEAR_TILING_EXT | |
| +--------------------+ |
| |
| Errors |
| |
| New State |
| |
| Issues |
| |
| 1) Should only DSA-style texture and buffer object binding |
| functions be added to keep the number of new functions |
| to a minimum? |
| |
| RESOLVED: No. Both DSA and traditional entry points will be added. |
| |
| 2) Should the type of the memory <size> and <offset> parameters be |
| GLsizeiptr, GLintptr, GLint64, or GLuint64? |
| |
| RESOLVED: GLuint64. This matches the VkDeviceSize semantics. |
| |
| 3) Should there be a way to allocate memory within OpenGL in |
| addition to importing it? |
| |
| RESOLVED: No. This could be covered in a separate extension, but |
| this would involve building up all the memory property |
| infrastructure Vulkan already has. Applications wishing to use |
| memory objects in OpenGL will need to leverage the allocation and |
| memory capability querying mechanisms present in Vulkan to perform |
| the actual allocations, and then map the capabilities to GL |
| equivalents when using them. |
| |
| 4) How are sparse textures handled? |
| |
| RESOLVED: Sparse texture support is deferred to a later extension. |
| Late in the development of this specification, it was discovered |
| that naively extending TexPageCommitmentARB to accept an offset |
| and memory object parameter results in a subtly awkward interface |
| when used to build GL sparse textures equivalent to those of Vulkan |
| sparse images, due to the lack of a defined memory layout ordering |
| for array textures. Developing a better interface would have |
| further delayed release of the basic functionality defined here, |
| which is in higher demand. |
| |
| 5) Do memory objects created as dedicated allocations need special |
| handling? |
| |
| RESOLVED: No. Like other memory regions, these allocations must be |
| bound to GL objects compatible with those they are bound to in |
| Vulkan to avoid aliasing issues, but otherwise no special handling |
| is required. |
| |
| 6) Should the BufferStorage functions still take a flags parameter? |
| |
| RESOLVED: No. The flags are not relevant when the memory has |
| already been allocated externally. |
| |
| 7) Should the Buffer commands be called BufferStorage or BufferData? |
| |
| RESOLVED: BufferStorage. GL has both commands, while GL ES has only |
| BufferData. The difference between the two GL commands is |
| immutability. The naming of the BufferStorage seems more consistent |
| with the usage, since data is not specified with these commands, but |
| a backing store is, and immutability for Vulkan memory-backed buffer |
| objects seems desirable. However, if GLES implementations can not |
| support immutable buffers, BufferData() support can be added in a |
| future extension with some added driver complexity. |
| |
| 8) Can semaphore commands be issued inside of Begin/End, or be |
| included in display lists? |
| |
| RESOLVED: No. |
| |
| 9) Do ownership transfer and memory barrier commands need to be |
| included in the semaphore operations? |
| |
| RESOLVED: Yes, these are needed for proper synchronization on some |
| implementations. Presumably only the source side of the barriers |
| needs to be specified when transitioning from external to GL usage, |
| and only the destination side needs to be specified when |
| transitioning from GL to external usage. That should give the |
| OpenGL driver sufficient knowledge to perform any needed automatic |
| transitions based on subsequent usage within the GL API. |
| |
| Still, it is unclear how much of the Vulkan pipeline barrier API |
| should be explicitly exposed in the GL API: |
| |
| * Should queue ownership be included? There is no equivalent |
| idiom to define this on top of in GL. However, since the |
| external side is the only portion specified by the |
| application, it could be described in Vulkan terms. |
| |
| * Should image layout be included? Similar to the above, there |
| is no GL concept of this, but Vulkan terms could be leveraged. |
| |
| * Should access type be included? This maps relatively well to |
| OpenGL memory barrier bits, but there is not a 1-1 |
| correspondence. |
| |
| * Should the pipeline stage be included? This could be mapped |
| to stages defined in the GL state machine, but such explicit |
| references to the stages are not thus far included in GL |
| language or tokens. |
| |
| Another option is to require the Vulkan driver to put images, |
| buffers, and their memory in a particular state before sharing |
| them with OpenGL. For example, require applications to |
| transition to the GENERAL image layout, dstStageMask of |
| TOP_OF_PIPE or ALL_COMMANDS, dstAccessMask will include |
| MEMORY_WRITE_BIT | MEMORY_READ_BIT or some new "more external" |
| version of these, and the dstQueueFamilyIndex must be IGNORED |
| while srcQueueFamilyIndex must be a valid queue family (a |
| currently illegal situation). |
| |
| 10) Should the barrier functionality be included in the semaphore |
| operation commands? |
| |
| RESOLVED: Yes. The only time such barriers are required in GL is |
| when synchronizing with external memory accesses, which is also the |
| only time semaphores should be used. For internal synchronization, |
| existing GL and EGL commands should be used. Since the use cases |
| align, it makes sense to make them a single command to cut down on |
| the potential for misuse and keep the API footprint as small as |
| possible. |
| |
| 11) Must both Gen[MemoryObjects,Semaphores]EXT commands and |
| Create[MemoryObjects,Semaphores]EXT commands be defined, or is |
| one or the other sufficient? |
| |
| RESOLVED: One variant is sufficient for each object type. |
| |
| 12) Should buffer objects backed by memory objects be mappable? |
| |
| RESOLVED: No. This would complicate the API as interactions between |
| GL and Vulkan cache flushing semantics would need to be defined. |
| |
| 13) Does the usage information provided when creating Vulkan images |
| need to be specified when creating textures on memory objects? |
| If so, how is it specified? |
| |
| RESOLVED: There are a few options for specifying the usage in |
| OpenGL: |
| |
| * Have some sort of GLX/EGL-like attrib list that allows users |
| to specify an arbitrary set of usage parameters. |
| |
| * Allow applications to re-use the Vulkan usage flags directly |
| in GL. |
| |
| * Re-define all the Vulkan image usage flags in GL, and update |
| the list via new GL interop extensions as new Vulkan usage |
| flags are added by Vulkan extensions. |
| |
| None of these are very compelling. They all complicate the OpenGL |
| API significantly and have a high spec maintenance burden as new |
| extensions are added. |
| |
| Other options for resolving the overall issue of GL knowing the |
| usage include: |
| |
| * Disallow Vulkan implementations from utilizing the usage |
| information as input when determining the internal parameters of a |
| Vulkan image used with eternal memory. |
| |
| * Only allow Vulkan implementations to utilize the usage information |
| when using the dedicated allocation path where it can be stored as |
| a form of metadata along with the memory. |
| |
| * Require applications to specify all supported usage flags at image |
| creation time on the Vulkan side for images that are intended to |
| alias with OpenGL textures. |
| |
| The first two options have the downside of potentially limiting the |
| ability of implementations to fully optimize external images |
| regardless of their use case. The last option constrains the |
| limitations to the case of interoperation with OpenGL, making it a |
| less onerous requirement for implementations while still keeping the |
| OpenGL side of the API relatively simple compared to the options |
| involving re-specification of image usage on the OpenGL side. |
| |
| The agreed resolution is to use the final option: Require all |
| supported usage flags be specified by the application on the Vulkan |
| side if the image is intended to alias with an OpenGL texture. |
| |
| 14) Are memory barriers for textures and buffer objects needed with |
| semaphore signal/wait operations, or should a blanket availability/ |
| visibility rule be applied like in Vulkan<->Vulkan semaphore |
| synchronization? |
| |
| RESOLVED: Perhaps extra availability/visibility operations need to |
| be performed to enable external accesses, so it is safest to require |
| explicit specification of the resources that need to be made |
| available and visible as part of a semaphore synchronization |
| operation. |
| |
| 15) Are OpenGL equivalents of the Vulkan image creation flags related to |
| sparse properties needed? |
| |
| RESOLVED: Sparse support is not included in this extension. |
| |
| Prior to this resolution, the proposed resolution was as follows: |
| |
| No. For the purposes of OpenGL, the functionality of all the Vulkan |
| sparse image creation flags is contained in the existing |
| TEXTURE_SPARSE texture parameter. Because OpenGL does not have the |
| same sparse feature granularity as Vulkan, applications wishing to |
| create a sparse image that will alias with an OpenGL sparse texture |
| will be required to set all of the sparse bits. Images not intended |
| to alias with an OpenGL texture without the TEXTURE_SPARSE flag set |
| must have none of the Vulkan sparse bits set. |
| |
| 16) How do Vulkan sparse block sizes and OpenGL virtual page sizes |
| interact? |
| |
| RESOLVED: Sparse support is not included in this extension. |
| |
| Prior to this resolution, the proposed resolution was as follows: |
| |
| The application must use an OpenGL virtual page size with dimensions |
| matching those of the Vulkan sparse block size for any Vulkan images |
| aliasing OpenGL sparse textures. If no such virtual page size exists, |
| such aliasing is not supported. |
| |
| 17) Is an OpenGL equivalent of the mutable format Vulkan image creation |
| parameter needed? |
| |
| RESOLVED: No. However, Vulkan applications will be required to set |
| the mutable format bit when creating an image that will alias with |
| an OpenGL texture on an OpenGL implementation that supports |
| ARB_texture_view, OES_texture_view, EXT_texture_view, or OpenGL 4.3 |
| and above. |
| |
| 18) Is an OpenGL equivalent of the tiling Vulkan image creation |
| parameter needed? |
| |
| RESOLVED: Yes. Further, OpenGL implementations may not support |
| creating textures from Vulkan images using certain tiling types, so |
| a query is needed to determine the types supported. |
| |
| 19) Is a way to specify dedicated allocation semantics needed? |
| |
| RESOLVED: Yes. Importing dedicated allocation-style memory may |
| require the driver to use different paths than importing purely |
| abstract memory. Additionally, textures and buffer objects may need to derive meta-data from their associated memory object if |
| it is a dedicated allocation. Therefore, a dedicated allocation |
| parameter should be added to the memory objects. Additional |
| parameters for textures and buffer objects are not required because |
| unlike Vulkan, OpenGL exposes no application-visible texture or |
| buffer state that would vary depending on whether a dedicated |
| allocation will be used for their storage. Therefore, they can |
| inherit the state from the memory object associated with them at |
| storage specification time. Note that allowing parameters to be |
| specified on a memory object prior to the import operation requires |
| separate memory import from memory object instantiation commands. |
| |
| 20) How should devices be correlated between OpenGL Vulkan, and other |
| APIs? |
| |
| RESOLVED: Device UUID, LUID, and node mask queries are introduced, |
| corresponding to those added to the Vulkan API for external memory/ |
| semaphore purposes. Because contexts may be associated with |
| multiple physical GPUs in some cases, multiple values are returned |
| for device UUIDs and multiple bits are set in the device node masks. |
| It is not expected that a single context will be associated with |
| multiple DXGI adapters, so only one LUID is returned. |
| |
| When sharing with Vulkan device groups, the device UUIDs used by the |
| context must match those of the Vulkan physical devices in the |
| Vulkan device group. Future extensions could relax this |
| requirement. |
| |
| 21) How do applications determine valid values for the <offset> |
| parameter of the new storage allocation/binding functions? |
| |
| RESOLVED: This is outside the scope of this extension. The API or |
| mechanism which allocated the memory must provide this information. |
| However, the GL will generate an error if an invalid offset is used. |
| |
| 22) Are there any interactions with the EXT_protected_textures |
| extension? |
| |
| RESOLVED: Yes. Memory objects can be marked as protected or not |
| protected before import. This state must match that of the |
| imported resource. For all textures bound to a given memory object, |
| the value of the TEXTURE_PROTECTED_EXT parameter of the textures |
| must match the PROTECTED_MEMORY_OBJECT_EXT parameter of the memory |
| object. |
| |
| Revision History |
| |
| Revision 12, 2017-06-08 (Andres Rodriguez) |
| - Fixed parameter name in MemoryObjectParameterivEXT's description. |
| - Fixed missing EXT suffix in some mentions of GetUnsignedByte* |
| |
| Revision 11, 2017-06-02 (James Jones) |
| - Added extension numbers. |
| - Fixed the name of GetSemaphoreParameterui64vEXT. |
| - Clarified which extensions each command and token belongs to. |
| - Marked complete. |
| |
| Revision 10, 2017-05-24 (James Jones) |
| - Added issue 21 and resolution. |
| - Added issue 22 and resolution. |
| - Removed sparse texture support. |
| - Filled in real token values |
| - Further documented the new LAYOUT tokens. |
| |
| Revision 9, 2017-04-05 (James Jones) |
| - Added context device UUID queries. |
| |
| Revision 8, 2017-04-04 (James Jones) |
| - Clarified semaphore semantics |
| |
| Revision 7, 2017-03-28 (James Jones) |
| - Fixed various typos. |
| |
| Revision 6, 2017-03-17 (James Jones) |
| - Renamed from KHR to EXT. |
| - Added texture tiling parameters. |
| - Added semaphore parameter manipulation functions. |
| - Replaced GenMemoryObjectsEXT with CreateMemoryObjectsEXT |
| - Added memory object parameter manipulation functions. |
| - Updated issue 13 with a proposed resolution. |
| - Added issues 15-19 and proposed resolutions. |
| |
| Revision 5, 2016-10-22 (James Jones) |
| - Added proposed memory barrier semantics to the semaphore commands. |
| - Added issue 14. |
| - Added some clarifications to issue 13 |
| |
| Revision 4, 2016-09-28 (James Jones) |
| - Merged in GL_KHR_semaphore to reduce number of specs. |
| - Added spec body describing the new commands. |
| - Added issues 9-13. |
| |
| Revision 3, 2016-08-15 (James Jones and Jeff Juliano) |
| - Clarified overview text. |
| |
| Revision 2, 2016-08-07 (James Jones) |
| - Added non-contiguous sparse binding support via |
| TexPageCommitmentMemKHR(). |
| |
| Revision 1, 2016-08-05 (James Jones) |
| - Initial draft. |
