OpenGL Über Buffers Extension

Transcription

1 1 of 70 OpenGL Über Buffers Extension Revision 0.29 Author Rob Mace Copyright 2002, 2003 ATI Technologies Inc. All rights reserved. This document is being distributed for the sole purpose of soliciting feedback on a possible OpenGL API specification proposal to the OpenGL Architecture Review Board (ARB), and no part of this document may be used, reproduced, or transmitted in any form or by any means for any other purpose without the prior written permission of ATI Technologies Inc.

2 2 of 70 Table of Contents 1 INTRODUCTION MIX AND MATCH PLUG AND PLAY WHY IS THIS INTERESTING? API DESIGN PHILOSOPHY SOME NOTES MEMORY OBJECTS CREATING AND DELETING MEMORY OBJECTS CREATING MEMORY OBJECTS The MATCH Properties When Can Memory Object Creation Fail? When Must Memory Object Creation Fail? When Must Memory Object Creation Succeed? Delayed Memory Object Validation and Attachment Compatibility Sets Proxy Memory Objects Memory Object Info Log MEMORY OBJECT STRUCTURE Structure Properties Assignment Capability Properties Assignment Configuration Properties Assignment Automatic Properties Assignment MEMORY OBJECT PROPERTY COMBINATION RESTRICTIONS CLONING MEMORY OBJECTS WINDOW SYSTEM ALLOCATED MEMORY OBJECTS DELETING MEMORY OBJECTS MEMORY OBJECTS AND MULTIPLE CONTEXTS QUERYING MEMORY OBJECT STATE QUERYING MEMORY OBJECT PROPERTIES QUERYING THE SUB MEMORIES OF A MEMORY OBJECT QUERYING THE BASE MEMORY OBJECT OF A SUB MEMORY OBJECT CHECKING THAT A MEMORY OBJECT EXISTS MANIPULATING MEMORY OBJECTS MEMORY OBJECTS IMAGE SPECIFICATION Memory Objects Image Specification Using glteximage and glcopyteximage COPYING MEMORY OBJECT CONTENTS READING MEMORY OBJECT CONTENTS INVALIDATING MEMORY OBJECT CONTENTS MEMORY OBJECT MIPMAP GENERATION ATTACHING AND BINDING MEMORY OBJECTS... 29

3 3 of ATTACHING MEMORY OBJECTS TO TEXTURE OBJECTS Mipmap Generation Querying The Memory Object Attached to a Texture Object ATTACHING MEMORY OBJECTS TO FRAMEBUFFER OBJECTS Querying The Memory Objects Attached to a Framebuffer Object Framebuffer Objects glswapbuffers USING MEMORY OBJECTS AS VERTEX ARRAYS MEMORY OBJECT CIRCUIT BINDING LIMITATIONS DETACHING MEMORY OBJECTS MEMORY OBJECT PROPERTIES CAPABILITY PROPERTIES STRUCTURE PROPERTIES CONFIGURATION PROPERTIES ALLOCATION PROPERTIES AUTOMATIC PROPERTIES FORMAT QUERIES EXAMPLES RENDER TO 2D TEXTURE RENDER TO 3D TEXTURE RENDER TO CUBE MAP TEXTURE WITH MIPMAPS RENDER TO TEXTURE LOOP CUSTOM MIPMAP GENERATION RENDER TO VERTEX ARRAYS ALLOCATING COMPATIBLE MEMORY OBJECTS AND ATTACHING THEM TO A FRAMEBUFFER OBJECT TESTING FOR FAILURE QUERYING INTERNAL FORMATS ISSUES SHOULD MEMORY OBJECTS BE RESIZABLE? SHOULD SUB MEMORY OBJECTS BE ATTACHABLE/DETACHABLE FROM THEIR BASE MEMORY OBJECT? SHOULD APPLICATIONS BE ABLE TO SPECIFY MEMORY OBJECT HANDLES? SHOULD WE ALLOW AUTOMATIC FIRST SUB MEMORY USE? WHAT SHOULD GLDELETEMEM BEHAVIOR BE IF THE MEM IS STILL ATTACHED? HOW SHOULD MEMORY MANAGEMENT BE DONE? HOW SHOULD ASYNCHRONOUS MEMORY OBJECT MANIPULATION BE DONE? WHAT SHOULD HAPPEN WHEN A GLTEXIMAGE OR GLCOPYTEXIMAGE COMMAND IS CALLED ON A TEXTURE THAT HAS A MEMORY OBJECT ATTACHED TO IT? WHAT SHOULD HAPPEN WHEN GLBUFFERDATAARB IS CALLED ON A BUFFER OBJECT THAT HAS A MEMORY OBJECT ATTACHED TO IT? SHOULD MEMORY OBJECTS BE MAPPABLE?... 59

4 4 of SHOULD MEMORY OBJECTS BE ATTACHABLE AS OVERLAY/UNDERLAY/LAYER PLANES? SHOULD GLMEM BE AN UNSIGNED INTEGER OF THE SAME BIT SIZE AS A POINTER? HOW SHOULD BIT ORDER BE DEFINED WHEN GL_ELEMENT_BITS IS NOT DIVISIBLE BY EIGHT? SHOULD MEMORY OBJECTS WITH GL_SAMPLES > 0 HAVE THEIR MEMORY ORGANIZATION DEFINED? SHOULD MAPPING BETWEEN VERTEX ARRAY INDICES AND 2D ELEMENTS BE BASED ON WIDTH OR PITCH? WHY DOES THE GL_MEMORY_WIDTH, ETC. PROPERTIES USE MEMORY AND NOT MEM? WHY NOT GIVE MORE STRICT RULES FOR HOW MEMORY OBJECTS BEHAVE WHEN SHARED BY MULTIPLE CONTEXTS? SHOULD REQUESTING THE GL_TEXTURE_CUBE_MAP CAPABILITY PROPERTY AUTOMATICALLY IMPLY THE GL_CUBE_MAP STRUCTURE PROPERTY IS GL_TRUE? WHAT SHOULD GLSWAPBUFFERS DO IF THE SOURCE AND DESTINATION BUFFERS DO NOT MATCH SHOULD THIS EXTENSION INCLUDE A SWAP INTERVAL CONTROL? SHOULD THIS EXTENSION INCLUDE A GANG SWAP CONTROL? WHY HAVE BOTH GL_DEPTH_BUFFER AND GL_DEPTH_SAMPLES ATTACHMENT POINTS IN A FRAMEBUFFER OBJECT? WHY USE GL_DEPTH_SLICED INSTEAD OF GL_SLICED? HOW SHOULD FRAMEBUFFER OBJECTS INTERACT WITH SHARING BY MULTIPLE CONTEXTS? SHOULD MAPPING BETWEEN NORMALIZED INTEGER AND REGULAR INTEGER COMPONENTS BE ALLOWED? HOW SHOULD QUERYING OF MEMORY OBJECT COMPONENT DETAILS (BITS AND TYPE) BE SUPPORTED? HOW SHOULD AUTOMATIC MIPMAP GENERATION BE HANDLED? DESIGN NOTES FUTURE EXTENSIBILITY LIMITED SUPPORT DIRECT ATTACHMENT VS. COPY FEATURES THAT WILL NOT BE PART OF BASE ÜBER BUFFERS GL_DISPLAY_BUFFER PROPERTY Attaching Memory Objects to the Context s Display Reason for not including GL_DISPLAY_BUFFER GL_FLUX PROPERTY Flux Memory Objects Reason for not including GL_FLUX GL_MAPPABLE PROPERTY Mapping a Memory Object Memory Organization ATTACHABLE AND DETACHABLE SUB MEMORY OBJECTS FAILURE PROXY MEMORY OBJECTS Reason for not including Failure Proxy Memory Objects... 70

5 5 of 70 Revision History Version Author(s) Comments 0.1 Mace Initial version still in development. 0.2 Mace Added GL_FLUX, GL_STEREO, GL_DISPLAY_BUFFER, GL_MULTISAMPLE_BUFFER, and GL_ACCUMULATION_BUFFER memory object properties. Reorganized some sections and added some more explanations and clarifications. Added Manipulating Memory Objects section Added Examples section. 0.3 Mace Added Resolved Issues section. 0.4 Mace Fixed some typos. Added target parameter to glbindtexmem. Filled in section on Binding Memory Objects to Vertex Arrays. Enhanced Render to Vertex Arrays example. 0.5 Mace Fixed some typos. Added Memory Object Image Specification section. Added Copying Memory Object Contents section. Added an open issue on gldeletemem behavior. Added an open issue on memory management. 0.6 Mace Fixed some typos. Added to Some Notes section 1.5 Added explanation that GLmem is just an unsigned int. Combined all glbind???mem functions into a single glbindmem function. Resolved overlap with buffer object functionality by making memory objects bindable as the memory of a buffer object. Added Reading Memory Object Contents sections. Added an open issue on asynchronous memory object manipulation. 0.7 Mace Fixed GL_TEXTURE_CUBE_MAP requirement in Table 6.1. Fixed DEPTH and STENCIL enums in Table 6.2. Added Render, Swap, and Display Alternate Color Buffer example. Fixed some typos. Added Final Thoughts section. 0.8 Mace Added open issued on what happened when glteximage and glbufferdataarb are called when a memory object is bound. Added GL_MAPPABLE property. Rewrote some of how flux is described. 0.9 Mace Fixed some typos. Changed glgetparentmem to get the root parent. Changed Copyright notice Mace Changed GL_BORDER values to 0/1 instead of GL_TRUE/GL_FALSE. Added glgetmemsubimage#d functions. Combined glmemimage#d functions into a single glmemimage function. Added preserve argument to glbindmem. Added some new open issues. Replaced GL_MULTISAMPLE_BUFFER property with GL_SAMPLES property. Added resolved issue on child attach/detach. Added explanation of property inheritance by child memory objects. Added memory organization properties and section. Added glgetmemproperties. Rewrote Final Thoughts section as a Design Notes section Mace Changed property values to be signed rather then unsigned. Changed preserve argument of bind and map functions a GLenum taking GL_PRESERVE and GL_DISCARD. Changed GL_PITCH to be sized in elements. Clarified element order. Added open issue on bit order for elements that are small. Clarified how GL_SAMPLES > 0 effects memory organization and added an open issue on it. Added section on API Design Philosophy. Added section on features not slated for base über buffer extension. Listed GL_DISPLAY_BUFFER and GL_STEREO properties as not slated for base extension Mace Added ability to allocate sets of memories that are guaranteed to be bindable together. Added ability to clone a memory object. Added GL_PROXY property. Added GL_FAILURE_PROXY property. Added example of allocating a set of memory objects for the framebuffer. Removed GL_DEPTH_STENCIL_BUFFER. Changed references to buffer_object extension to vertex_buffer_object extension.

6 6 of Mace Removed memory object sets. Added GL_BIND_COMPATIBILITY hint property. Added framebuffer objects. Added glswapmem. Added example of Allocating Compatible Memory Objects and Binding them to a Framebuffer Object. Broke GL_TEXTURE_IMAGE property into separate texture target based properties. Combined GL_ARRAY_BUFFER and GL_ELEMENT_ARRAY_BUFFER properties into GL_BUFFER_OBJECT property. Removed some OpenGL 2.0 references. Combined open and closed issue lists into a single list so that issues are not renumbered when they are resolved. Updated some issues Mace Moved GL_FLUX to not in base extension. Renamed GL_CONTEXT_ALLOCATED property to GL_WS_ALLOCATED window system allocated. Renamed child memory objects to be sub memory objects. Removed GL_STEREO property. Reworked framebuffer objects. Added glswapbuffers Mace Added list of memory formats. Added GL_BIND_FRAMEBUFFER framebuffer object target. Made sub memory objects not clonable. Fixed preserve arguments to consistently take GL_PRESERVE and GL_DISCARD. Clarified GL_BIND_COMPATIBILITY description. Fixed Typos Mace Changed glbindmem to glattachmem. Moved GL_MAPPABLE to not in base extension. Added section on attachable and detachable sub memory objects as not in base extension Mace Changed memory object to be directly bindable as vertex arrays, instead of attachable to buffer objects. Removed memory organization (BITS, SHIFT, PITCH) properties since they are no longer needed. Added issue on linearization of 2D memory objects. Allowed 1D memory objects to be attachable to frame buffer objects. Added GL_OPTIMAL setting for the GL_MATCH_SIZE hint property Mace Added array properties to table 3.1. Added GL_MIN_ELEMENTS setting for the GL_MATCH_SIZE hint property. Removed GL_OPTIMAL setting for the GL_MATCH_SIZE hint property. Indicated that memory object allocation for arrays can fail based on width and that apps should use GL_MIN_ELEMENTS or GL_MIN. Broke settable properties into capability and configuration properties Mace Added glgetmeminfolog. Moved failure proxy memory objects to not in base extension. Added GL_WEIGHT_ARRAY property for use with the ARB_vertex_blend extension. Combined the properties and values arguments of glallocmem#d into a single properties argument. Added gldetachmem Mace Fixed glgetmeminfolog to return const GLchar *. Stated that glmemcopy#d does not use the pixel path, and that src and dst must have the same format. Clarified that memories are attached to the currently bound object, and not to the target. Added glismem Changed gldeletemem behavior to be more object oriented and follow that of the gl2_shader_object extension. Removed glgetmemproperties. Added section on memory objects and multiple contexts. Replaced preserve argument of glattachmem with glinvalidatemem Mace Changed glattachmem to return GLvoid. Added GL_MATCH_COMPONENT_TYPE hint property. Reworded parts of section 2. Renamed GL_SUB_MEM to GL_IS_SUB_MEM. Noted more error conditions for glmemcopy#d. Added issue on use of MEMORY vs. MEM. Added issue on defining more multi context behavior. gldetachmem only detaches from objects, not from binding points. Added attachment argument to glattachmem and glgetmem. Removed GL_ATTACH_FRAMEBUFFER binding point. Changed GL_ATTACH_COMPATIBILITY to be set a target. Added some comments to some examples. Added structure properties group with GL_MIPMAP, GL_CUBE_MAP and GL_3D_DEPTH_SLICE Mace Changed glmemcopy#d to allow overlapped copies. Added new section on Memory Object Structure. Changed capability properties to take a mask that defines what sub memory objects have what capabilities. Changed GL_IS_SUB_MEM to GL_IS_BASE_MEM. Added issue on GL_TEXTURE_CUBE_MAP implying GL_CUBE_MAP.

7 7 of 70 Added Custom Mipmap Generation example. Fixed some typos Mace Added figure showing memory object structure for mipmapped cube map memory object. Added figure showing memory object structure for mipmapped depth sliced 3D memory object. Added section on Restrictions To Memory Object Property Combinations Removed properties beyond capability properties that are required for attachments Mace Rewrote Memory Object Property Combination Restrictions section and tables. Removed gldeletemems to match change to ARB_shader_objects extension. Reworked glgetmeminfolog to match changes to ARB_shader_objects extension. Changed glswapbuffers to return GLvoid. Made several clarification changes. Corrected resolution of gldeletemem detach behavior issue. Resolved issue on glteximage and glcopyteximage behavior. Added issue and resolution on what glswapbuffers returns. Added issue and resolution on whether a swap interval control should be part of this extension. Added issue and resolution on whether a gang swap control should be part of this extension Mace Renamed glnewframebuffer to glcreateframebuffer. Added framebuffer parameter commands. Replaced preserve argument to glswapbuffers with the GL_SWAP_PRESERVE parameter. Replaced glswapinterval with the GL_SWAP_SYNC and GL_SWAP_INTERVAL parameters Mace Redefined glswapbuffers behavior for non-matching source and destination. Added GL_WS_ALLOCATED parameter to framebuffer objects. Added _BIT designators to capability property bit mask value defines Mace Renamed Hint Properties to Allocation Properties. Added GL_COLOR_SAMPLES, GL_DEPTH_SAMPLES and GL_STENCIL_SAMPLES attachment points Added an issue explaining why there are both GL_DEPTH_SAMPLES and GL_DEPTH_BUFFER attachment points. Clarified how GL_SAMPLES property works. Removed unsized memory object formats. Added a few missing memory object formats. Fixed some issues in framebuffer allocation example. Added When Must Memory Object Creation Fail? section. Added When Must Memory Object Creation Succeed? section. Renamed GL_3D_DEPTH_SLICE property to GL_DEPTH_SLICED. Changed GL_GENERIC_ARRAY to GL_VERTEX_ATTRIB_ARRAY. Added note that pixel ownership test will always pass when rendering to an application allocated framebuffer object. Added glcopymemsubimage3d. Added several clarifications. Expanded component mapping tables in Vertex Array section. Changed GL_FOG_COORDINATE_ARRAY to GL_FOG_COORD_ARRAY to match OpenGL 1.5 change. Added Format Queries section. Added issue on how component bits and type should be queried. Fixed some typos Mace Added GL_FLAGGED_FOR_DELETION automatic property. Changed attachment method to be attachment by direct reference. Replaced glattachmem with glattachtexturemem and glattachframebuffermem. Replaced glgetmem with glgettexturemem and glgetframebuffermem. Added glmemgeneratemipmap. Added GL_BASE_AND_LEAVES. Rewrote examples to match changes. Fixed some typos Mace Added delayed validation for attachment compatibility. Rewrote the allocating compatible memory objects example. Remove GL_ATTACH_COMPATIBILITY property. Added section on Memory Object Circuit Binding Limitations Changed default of GL_MATCH_COMPONENT_SIZE and GL_MATCH_SAMPLES to GL_NEAREST. Added component BITS and TYPE automatic properties. Added section on the MATCH properties. Added rules for when memory object creation must fail. Added rules for when memory object creation must succeed. Clarified that the glmemimage commands are operationally equivalent to the glteximage commands. Clarified that the glgetmemimage command are operationally equivalent to the glgetteximage command. Added a Testing For Failure example. Added an issue on automatic mipmap generation. Fixed typos. Fixed minor errors. Added some minor clarifications.

8 8 of 70 1 Introduction The Über Buffers Extension adds two basic types of functionality to OpenGL. For simplicity I will refer to these as Mix and Match and Plug and Play. 1.1 Mix and Match Mix and Match is the ability to use the same memory buffers in multiple ways. The only OpenGL 1.X example of this is render to texture where a memory buffer is used as both a color buffer and a texture. What this paper describes is a generalized method for allowing memory buffers to be used for many purposes. The interface for this is also designed for easy expansion into uses that have not yet been envisioned. 1.2 Plug and Play Plug and Play is the ability to easily reconfigure what memory buffers are wired into what parts of the OpenGL pipeline. The OpenGL 2.0 Objects paper has enhanced this in relation to OpenGL 1.X but this Über Buffer proposal goes even further along this path. 1.3 Why is this Interesting? What makes über buffers truly interesting and useful is the combination with floating point calculations in the fragment shader, and floating point destination buffers. In combination these allow for a whole new set of algorithms, both graphical and non-graphical, to be implemented. The old pbuffer style mechanism where a separate OpenGL context needs to be created for each pbuffer was fine for situations where an application might have one pbuffer that is used to render a cube map, but it starts breaking down however when one starts imagining an application needing hundreds of buffers. The lightweight nature of über buffers makes them a much better fit for such applications. 1.4 API Design Philosophy APIs can live a very long time, and perhaps more importantly we will have to live with the APIs we create for a very long time. For that reason it is important that we not only look at our current needs, but also look to the future and predict as best we can how the APIs we develop today will fit our future needs. Some of the features described in this document will probably not make it into the base über buffers extension. However, these features are being explored and retained in this document as part of the philosophy of designing a future proof API. Section 12 lists those features that are currently slated as not being part of the base. 1.5 Some Notes

9 9 of 70 Since we do not know if this will be a ARB, GL2, EXT, or ATI extension this document leaves off those designators for now. This extension has been written up in the form of a white paper for now in order to make it easier to understand and discuss. Before it becomes a real extension it will be written up in standard extension form. When written up in standard extension form this extension will most likely be named the memory_object extension.

10 10 of 70 2 Memory Objects A memory object is the über buffer of this extension. When allocated, a memory object contains a fixed size block of memory that can be used in multiple places within the OpenGL pipeline. Memory objects can be used as the memory of a texture, a framebuffer, or a vertex array. typedef GLuint GLmem; The handle of a memory object is just an unsigned integer. The point of using the GLmem type is to make it clearer where memory objects are used or returned by functions. Memory objects have their own name space that does not interact with the name space of other object types. When this document refers to the contents of a memory object, it is referring to the contents of the memory of the memory object. 3 Creating and Deleting Memory Objects 3.1 Creating Memory Objects GLmem glallocmem1d(glenum format, GLsizei width, GLsizei np, const GLint *properties) GLmem glallocmem2d(glenum format, GLsizei width, GLsizei height, GLsizei np, const GLint *properties) GLmem glallocmem3d(glenum format, GLsizei width, GLsizei height, GLsizei depth, GLsizei np, const GLint *properties) format is the internal format of the memory to allocate. The format can be any of the texture internal formats, as well as new formats defined by the Über Buffer Extension. Not all formats are compatible with all properties. GL_ALPHA4 GL_ALPHA8 GL_ALPHA12 GL_ALPHA16 GL_ALPHA_FLOAT16 GL_ALPHA_FLOAT32 GL_DEPTH_COMPONENT16 GL_DEPTH_COMPONENT24 GL_DEPTH_COMPONENT32 GL_LUMINANCE4 GL_LUMINANCE8 GL_LUMINANCE12 GL_LUMINANCE16 GL_LUMINANCE_FLOAT16 GL_LUMINANCE_FLOAT32 GL_LUMINANCE4_ALPHA4 GL_LUMINANCE6_ALPHA2 GL_LUMINANCE8_ALPHA8 GL_LUMINANCE12_ALPHA4 GL_LUMINANCE12_ALPHA12

11 11 of 70 GL_LUMINANCE16_ALPHA16 GL_LUMINANCE_ALPHA_FLOAT16 GL_LUMINANCE_ALPHA_FLOAT32 GL_INTENSITY4 GL_INTENSITY8 GL_INTENSITY12 GL_INTENSITY16 GL_INTENSITY_FLOAT16 GL_INTENSITY_FLOAT32 GL_R3_G3_B2 GL_RGB4 GL_RGB5 GL_R5_G6_B5 GL_RGB8 GL_RGB10 GL_RGB12 GL_RGB16 GL_RGB_FLOAT16 GL_RGB_FLOAT32 GL_RGBA2 GL_RGBA4 GL_RGB5_A1 GL_RGBA8 GL_RGB10_A2 GL_RGBA12 GL_RGBA16 GL_RGBA_FLOAT16 GL_RGBA_FLOAT32 GL_STENCIL_COMPONENT1 GL_STENCIL_COMPONENT2 GL_STENCIL_COMPONENT4 GL_STENCIL_COMPONENT8 GL_STENCIL_COMPONENT16 GL_COMPRESSED_ALPHA GL_COMPRESSED_LUMINANCE GL_COMPRESSED_LUMINANCE_ALPHA GL_COMPRESSED_INTENSITY GL_COMPRESSED_RGB GL_COMPRESSED_RGBA np is the number of property/value pairs in properties. properties is a list of the desired property/value pairs of the memory being allocated. Each property in the properties list is followed by the value for that property. There are five classes of properties. Capability properties (see Table 3.1 and Section 7.1) define how the allocated memory can be used. Structure properties (see Table 3.2 and Section 7.2) define the structural hierarchy of the memory object. Configuration properties (see Table 3.3 and Section 7.3) define something about how the memory object is configured. Allocation properties (see Table 3.4 and Section 7.4) are properties that only have an effect during allocation and are not properties of a memory object after it is allocated. Automatic properties (see Table 3.5 and Section 7.5) are properties that are indirectly specified, and these properties cannot be used in properties. See Section 7 for a detailed description of each property. Values in BOLD are the defaults if not specified. Properties GL_COLOR_BUFFER GL_DEPTH_BUFFER GL_STENCIL_BUFFER GL_TEXTURE_1D GL_TEXTURE_2D GL_TEXTURE_3D GL_TEXTURE_CUBE_MAP GL_TEXTURE_RECTANGLE GL_VERTEX_ARRAY Possible Values GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FALSE, GL_BASE, GL_LEAVES, (structure mask)

12 12 of 70 GL_NORMAL_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_COLOR_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_SECONDARY_COLOR_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_INDEX_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_FOG_COORD_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_TEXTURE_COORD_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_EDGE_FLAG_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_WEIGHT_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_VERTEX_ATTRIB_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_ELEMENT_ARRAY GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) GL_ACCUMULATION_BUFFER GL_FALSE, GL_BASE, GL_LEAVES, (structure mask) Table 3.1 Capability Properties Properties GL_MIPMAP GL_CUBE_MAP GL_DEPTH_SLICED Possible Values GL_FALSE, GL_TRUE GL_FALSE, GL_TRUE GL_FALSE, GL_TRUE Table 3.2 Structure Properties Properties Possible Values GL_BORDER 0, 1 GL_SAMPLES 0, 2, 3,, n GL_USAGE GL_STATIC_DRAW, GL_STATIC_READ, GL_STATIC_COPY, GL_STREAM_DRAW, GL_STREAM_READ, GL_STREAM_COPY, GL_DYNAMIC_DRAW, GL_DYNAMIC_READ, GL_DYNAMIC_COPY GL_PROXY GL_FALSE, GL_TRUE Table 3.3 Configuration Properties Properties Possible Values GL_MATCH_SIZE GL_EXACT, GL_MIN, GL_MAX, GL_NEAREST, GL_MIN_ELEMENTS GL_MATCH_COMPONENT_SET GL_EXACT, GL_MIN GL_MATCH_COMPONENT_SIZE GL_NEAREST, GL_EXACT, GL_MIN GL_MATCH_COMPONENT_TYPE GL_EXACT, GL_NEAREST GL_MATCH_SAMPLES GL_NEAREST, GL_EXACT, GL_MIN, GL_MAX GL_VALIDATE GL_TRUE, GL_FALSE GL_VALIDATE_ONLY GL_FALSE, GL_TRUE Table 3.4 Allocation Properties Properties GL_VALIDATED GL_FALSE, GL_TRUE Possible Values

13 13 of 70 GL_MEMORY_DIMENSIONS 1, 2, 3 GL_MEMORY_WIDTH width GL_MEMORY_HEIGHT height if 2D or 3D, otherwise 1 GL_MEMORY_DEPTH depth if 3D, otherwise 1 GL_MEMORY_LEVELS Number of mipmap levels if GL_MIPMAP is GL_TRUE, otherwise 1 GL_BASE_FORMAT GL_RGBA, GL_RGB, GL_LUMINANCE_ALPHA, GL_LUMINANCE, GL_ALPHA, GL_INTENSITY, GL_DEPTH_COMPONENT, GL_STENCIL_COMPONENT GL_RED_BITS Size of red component in bits. GL_GREEN_BITS Size of green component in bits. GL_BLUE_BITS Size of blue component in bits. GL_ALPHA_BITS Size of alpha component in bits. GL_LUMINANCE_BITS Size of luminance component in bits. GL_INTENSITY_BITS Size of intensity component in bits. GL_DEPTH_BITS Size of depth component in bits. GL_STENCIL_TYPE Size of stencil component in bits. GL_RED_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_GREEN_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_BLUE_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_ALPHA_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_LUMINANCE_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_INTENSITY_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_DEPTH_TYPE GL_NONE, GL_UNSIGNED, GL_SIGNED, GL_FLOAT GL_STENCIL_TYPE GL_NONE, GL_INDEX GL_IS_BASE_MEM GL_FALSE, GL_TRUE GL_WS_ALLOCATED GL_FALSE, GL_TRUE GL_FLAGGED_FOR_DELETION GL_FALSE, GL_TRUE Table 3.5 Automatic Properties If successful these functions return a memory object. If a memory object cannot be created, 0 is returned The MATCH Properties The MATCH allocation properties (see section 7.4) allows details a memory object to differ from the exact memory object that is requested at allocation time. When these properties allow an implementation to choose some of the details, the implementation must follow these general rules: 1. If an exact match is requested, the allocation should fail if an exact match is not possible. 2. If an exact match is not required, the implementation should choose the nearest match possible that does not caused a severe performance penalty (i.e. falling to software rendering). There are also some specific rules for some of these properties in section When Can Memory Object Creation Fail?

14 14 of 70 There are a number of reasons that memory object creation can fail. If some needed resource is exhausted then creation can fail and the error GL_OUT_OF_MEMORY will be set. Implementations are encouraged to virtualize resources so that this failure is very rare. If an illegal combination of properties (see section 3.1.3) is specified creation will fail and the error GL_INVALID_OPERATION will be set. There can be some set of property and format combinations that are not supported on an implementation. Requesting one of these combinations will fail. An error will not be set if creation fails for this reason When Must Memory Object Creation Fail? There are some property combinations that are illegal. Attempting to allocate a memory object with one of these combinations will fail and the error GL_INVALID_OPERATION will be set. These combinations are generally illegal because they create situations where the behavior is not defined by the current OpenGL spec or this extension. Future extensions may define the behavior of some of these combinations and make them legal. Memory object creation must fail if any of the following conditions are not met: If the GL_COLOR_BUFFER capability property is GL_TRUE, the GL_BASE_FORMAT must be GL_RGBA or GL_RGB. If the GL_DEPTH_BUFFER capability property is GL_TRUE, the GL_BASE_FORMAT must be GL_DEPTH_COMPONENT. If the GL_STENCIL_BUFFER capability property is GL_TRUE, the GL_BASE_FORMAT must be GL_STENCIL_COMPONENT. If any of the texture capability properties is GL_TRUE, the GL_BASE_FORMAT cannot be GL_STENCIL_COMPONENT. If either of the GL_TEXTURE_3D or GL_TEXTURE_CUBE_MAP capability properties is GL_TRUE, the GL_BASE_FORMAT cannot be GL_DEPTH_COMPONENT. If GL_SAMPLES >= 2 the only capability properties that can be GL_TRUE are GL_COLOR_BUFFER, GL_DEPTH_BUFFER, and GL_STENCIL_BUFFER. Need to finish this list When Must Memory Object Creation Succeed?

15 15 of 70 There will most likely be some set of creation requests that must be successful, and cannot fail unless resources have been exhausted. This set will likely be expanded in future revision of OpenGL. Implementations must support at least one resolution of each legal base format that a texture capability can have. Implementations must support at least one format when the GL_COLOR_BUFFER capability property is set to GL_TRUE. Implementations are strongly encouraged to support at least one depth buffer format, and stencil buffer format for each color buffer format supported Delayed Memory Object Validation and Attachment Compatibility Sets Some implementations may have restrictions about what memory objects can be attached together to other objects (see section 6). For example only certain depth, stencil, and color formats may be attachable together to a framebuffer object. Delayed validation allows an application to make the attachments before memory objects are validated so that implementation limitations can be taken into account when determining memory object formats. The GL_VALIDATE allocation property defaults to GL_TRUE, but if it is set to GL_FALSE, the memory object created by glallocmem1d, glallocmem2d, or glallocmem3d, will not be validated at creation time. Setting GL_VALIDATE = GL_FALSE is not a guarantee that memory object creation will succeed. If the requested properties are illegal, or are a combination that an implementation cannot accommodate under any circumstance, creation of the memory object will fail. A memory object that has been validated will have its GL_VALIDATED automatic property set to GL_TRUE, while a memory object that has been validated will have it set to GL_FALSE. Non-validated memory objects can be attached to other objects, but cannot be bound into OpenGL state vector. Attempting to attach a non-validated memory object to an object that is currently bound will result in the error GL_INVALID_OPERATION being generated. Attempting to bind an object that has a nonvalidated memory object attached to it will result in the error GL_INVALID_OPERATION being generated. Non-validated memory objects can be validated by calling glvalidatemems. GLenum glvalidatemems(glmem mem) glvalidatemems will do a cascading search starting with mem, for all memory objects attached to the same objects as mem, or attached to objects that those memory objects are attached to, etc.. This set of memory objects will be considered for validation as a set, taking into account all attachments. If all non-validated memory objects in this set can be validated, they will all be validated, and GL_TRUE will be returned. If

16 16 of 70 any of the non-validated memory objects in this set cannot be validated, none of them will be validated, and GL_FALSE will be returned. When memory objects are validated, the value of their automatic properties may change. When two or more memory objects are attached to another object and are validated to be compatible together they become part of an attachment compatibility set. A memory object will belong to multiple attachment compatibility sets if it is validated in multiple attachment combinations with other memory objects. When a validated memory object is cloned (see section 3.4), the clone will belong to the same attachment compatibility sets as the original. Attempting to attach a validated memory object to an object that has other validated memory objects already attached to it will result in the error GL_INVALID_OPERATION if that memory object does not belong to the same attachment compatibility set as those other memory objects. In practice this is currently only a limitation when you want to attach more then one memory object to a framebuffer object Proxy Memory Objects A proxy memory object is one that is allocated with the property GL_PROXY = GL_TRUE. Proxy memory objects do not have actual memory associated with them, and thus cannot be bound or used in any way that would access their contents. A proxy memory object is useful to an application as a way to identify and record what memory objects are allocatable. Proxy memory objects can be attached to other objects, but cannot be bound into OpenGL state vector. Attempting to attach a proxy memory object to an object that is currently bound will result in the error GL_INVALID_OPERATION being generated. Attempting to bind an object that has a proxy memory object attached to it will result in the error GL_INVALID_OPERATION being generated. Proxy memory objects can be delay validated along with other proxy and non-proxy memory objects Memory Object Info Log GLvoid glgetmeminfolog(glmem mem, GLsizei maxlength, GLsizei *length, GLchar *infolog) glgetmeminfolog returns information about the creation or validation of mem in the buffer pointed to by infolog. The info log string that is returned in infolog will be null terminated. maxlength specifies the length of the buffer pointed to by infolog. The GL will not write more then maxlength characters, including the null termination, into infolog. If length is not NULL, the number of characters written into infolog excluding the null termination will be returned in length. If mem is 0, glgetmeminfolog will return information about the last failed memory object creation attempt. The returned string can be an empty string. The info log is typically only useful during application development and an application should not expect different OpenGL implementations to produce identical info logs.

17 17 of 70 An implementation should generally put information in the info log that the developers of that implementation think would be useful to application developers. 3.2 Memory Object Structure A memory object contains a hierarchy of sub memory objects if and only if one or more of its structure properties (GL_MIPMAP, GL_CUBE_MAP, or GL_DEPTH_SLICED) is set to GL_TRUE. Memory objects that have GL_MIPMAP = GL_TRUE contain sub memory objects that are the mipmap levels. Memory objects that have GL_CUBE_MAP = GL_TRUE contain sub memory objects that are the faces of the cube map. Memory objects that have GL_DEPTH_SLICED = GL_TRUE contain sub memory objects that are layers of the third dimension. The memory objects that are returned directly by glallocmem1d, glallocmem2d, glallocmem3d and glclonemem are referred to as base memory objects, because they are the bases of their hierarchies. Base memory objects have GL_IS_BASE_MEM = GL_TRUE. Memory objects that contain no other sub memory objects are referred to as leaf memory objects, because they are the leaves of their hierarchies. Leaf memory objects have all their structure properties set to GL_FALSE. If a base memory object has all structure properties set to GL_FALSE, it is both a base memory object and a leaf memory object. Sub memory objects are indivisible from the base memory object they are a subset of. They cannot be created or deleted independently. The memory that is contained in a sub memory object is simply a subset of its base memory object s memory. Sub memory objects can be used in the same ways as other memory objects, except that only base memory objects may be passed to glclonemem, or gldeletemem. The sub memory objects of a memory object are obtained by calling glgetsubmem (see section 4.2).

18 18 of 70 Base Memory Object Cube Map Face Sub Memory Objects Mipmap Level Sub Memory Objects Leaf Memory Objects Figure 3.1. Structure of a 4x4 mipmapped cube map memory object. Base Memory Object Depth Slice Sub Memory Objects Mipmap Level Sub Memory Objects Leaf Memory Objects Figure 3.2. Structure of a 4x4x4 mipmapped 3D memory object with depth slices.

19 19 of 70 The properties of a base memory object and its sub memory objects are not all the same. The way that each property is assigned to each sub memory object is dependent on the class of that property Structure Properties Assignment A base memory object will have all of its structure properties set in the manner that they were requested at allocation time. Sub memory objects will inherit structure properties, except sub memory objects that are based on a particular structure property will have that property set to GL_FALSE. The GL_MIPMAP sub memories of a memory object will have GL_MIPMAP = GL_FALSE. The GL_CUBE_MAP sub memories of a memory object will have GL_CUBE_MAP = GL_FALSE. The GL_DEPTH_SLICED sub memories of a memory object will have GL_DEPTH_SLICED = GL_FALSE Capability Properties Assignment At allocation time capability properties are set to GL_TRUE for a subset of a base memory object and its sub memory objects, those memory objects that are not part of that subset have the capability property set to GL_FALSE. The subset is specified by the value associated with the capability property in the properties list. The most commonly useful subsets are specified by the values GL_FALSE, GL_BASE, GL_LEAVES and, GL_BASE_AND_LEAVES. GL_FALSE is the default and means that none of the memory objects have the capability set to GL_TRUE. GL_BASE means that only the base memory object has the capability set to GL_TRUE. GL_LEAVES means that only the leaf memory objects have the capability set to GL_TRUE. GL_BASE_AND_LEAVES means that the base memory object and the leaf memory objects have the capability set to GL_TRUE. A more complex subset can be specified using a set of special mask values that specify the subset based on each memory objects structure properties. If this mask is all 0s (same as GL_FALSE), then the capability property will be GL_FALSE for the base memory object and all its sub memory objects. If the mask is not all 0s, then the mask is a series of two bit values for correspond to each structure property. These 2 bit values have the following meanings: 0x1 The capability should be GL_TRUE where the corresponding structure property is GL_FALSE. 0x2 The capability should be GL_TRUE where the corresponding structure property is GL_TRUE. 0x0 or 0x3 The capability should be GL_TRUE regardless of if the corresponding structure property is either GL_FALSE or GL_TRUE. The defines used for setting this mask are: #define GL_MIPMAP_FALSE_BIT #define GL_MIPMAP_TRUE_BIT #define GL_MIPMAP_EITHER_BITS #define GL_CUBE_MAP_FALSE_BIT #define GL_CUBE_MAP_TRUE_BIT #define GL_CUBE_MAP_EITHER_BITS 0x x x c 0x x x

20 20 of 70 #define GL_DEPTH_SLICED_FALSE_BIT 0x #define GL_DEPTH_SLICED_TRUE_BIT 0x #define GL_DEPTH_SLICED_EITHER_BITS 0x000000c0 These mask values are bitwise ORed together to specify the subset of the sub memory objects that are to have the capability property set to GL_TRUE. Here are a couple examples: GL_MIPMAP_TRUE_BIT GL_CUBE_MAP_TRUE_BIT The capability property will be GL_TRUE in sub memory objects where GL_MIPMAP = GL_TRUE and GL_CUBE_MAP = GL_TRUE, and will be GL_FALSE in other sub memory objects. GL_DEPTH_SLICED_TRUE_BIT GL_MIPMAP_EITHER_BITS The capability property will be GL_TRUE in sub memory objects where GL_DEPTH_SLICED = GL_TRUE and regardless of the value of GL_MIPMAP, and will be GL_FALSE in other sub memory objects. The GL_BASE and GL_LEAVES defines are: #define GL_BASE #define GL_LEAVES #define GL_BASE_AND_LEAVES 0x x x Configuration Properties Assignment A memory object and all its sub memory objects will have the same configuration properties Automatic Properties Assignment A memory object and all its sub memory objects will have the same GL_MEMORY_FORMAT and GL_WS_ALLOCATED properties. A memory object and all its sub memory objects will have the same GL_MEMORY_DIMENSIONS and GL_MEMORY_DEPTH properties, except when the sub memory objects are 3D depth slices in which case their GL_MEMORY_DIMENSIONS will be 2 and their GL_MEMORY_DEPTH will be 1. A memory object and all its sub memory objects will have the same GL_MEMORY_LEVELS, GL_MEMORY_WIDTH, and GL_MEMORY_HEIGHT properties, except when the sub memory objects are mipmap levels in which case their GL_MEMORY_LEVELS will be 1 and their GL_MEMORY_WIDTH and GL_MEMORY_HEIGHT will be dependent on which level each sub memory object is. A base memory object will have GL_IS_BASE_MEM = GL_TRUE, while all its sub memory objects will have GL_IS_BASE_MEM = GL_FALSE.

21 21 of Memory Object Property Combination Restrictions For some of the properties of a memory object to be GL_TRUE other properties of that same memory object must have specific values. Table 3.6 and 3.7 list these property combination requirements. Structure Property GL_MEMORY_DIMENSIONS GL_MIPMAP 1, 2, or 3 GL_CUBE_MAP 2 GL_DEPTH_SLICED 3 Table 3.6. Structure Property Requirements. A memory object may only have a structure property with the value GL_TRUE if the value of its GL_MEMORY_DIMENSIONS property is as specified above. Capability Property GL_MEMORY_DIMENSIONS GL_MIPMAP GL_CUBE_MAP GL_TEXTURE_1D 1 either GL_FALSE GL_TEXTURE_2D 2 either GL_FALSE GL_TEXTURE_3D 3 either GL_FALSE GL_TEXTURE_CUBE_MAP 2 either GL_TRUE GL_TEXTURE_RECTANGLE 2 GL_FALSE GL_FALSE GL_COLOR_BUFFER 1 or 2 GL_FALSE GL_FALSE GL_DEPTH_BUFFER 1 or 2 GL_FALSE GL_FALSE GL_STENCIL_BUFFER 1 or 2 GL_FALSE GL_FALSE GL_ACCUMULATION_BUFFER 1 or 2 GL_FALSE GL_FALSE GL_VERTEX_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_NORMAL_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_COLOR_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_SECONDARY_COLOR_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_INDEX_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_FOG_COORD_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_TEXTURE_COORD_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_EDGE_FLAG_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_WEIGHT_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_VERTEX_ATTRIB_ARRAY 1 or 2 GL_FALSE GL_FALSE GL_ELEMENT_ARRAY 1 or 2 GL_FALSE GL_FALSE Table 3.7 Capability Property Requirements. A memory object may only have a capability property with the value GL_TRUE if the values of its GL_MEMORY_DIMENSIONS, GL_MIPMAP, and GL_CUBE_MAP properties are as specified above. 3.4 Cloning Memory Objects GLmem glclonemem(glmem mem) glclonemem allocates a memory object that is a clone of the memory object mem. All the properties of mem are exactly duplicated with the following exceptions. If mem is window system allocated the clone will not be. If mem is a proxy memory object (GL_PROXY = GL_TRUE) the clone will be a real memory

22 22 of 70 object (GL_PROXY = GL_FALSE). The cloning of a memory object does not include the cloning of its contents. Contents can be copied by using one of the memory copying functions (see section 5.2). Non-base memory object (GL_IS_BASE_MEM = GL_FALSE) cannot be cloned. Attempting to do so will result in the error GL_INVALID_OPERATION. 3.5 Window System Allocated Memory Objects Window system allocated memory objects are the memory objects allocated by the window system and attached to the default framebuffer of a context. A context s original color buffers, depth buffer, and stencil buffer are examples of window system allocated memory objects. Window system allocated memory objects have the GL_WS_ALLOCATED property set to GL_TRUE. 3.6 Deleting Memory Objects GLvoid gldeletemem(glmem mem) gldeletemem deletes or flags for deletion the memory object mem. mem is flagged for deletion if it or any of its sub memory objects are attached to any other objects, or are part of the current rendering state for any context. mem is deleted if it and all its sub memory objects are neither attached to other objects, nor part of the current rendering state for any context. When a memory object that that has been flagged for deletion is no longer attached to other objects or part of any contexts rendering state, it is deleted. The GLmem handle to a memory object that has been flagged for deletion is still valid and continues to be valid until the memory object is deleted. A memory object that has been flagged for deletion will have its GL_FLAGGED_FOR_DELETION property set to GL_TRUE. The error GL_INVALID_VALUE is generated if mem is > 0 and is not a memory object. If mem is 0 gldeletemem will do nothing. Deleting a memory object will delete all its sub memory objects. You cannot independently delete a sub memory object. Attempting to do so will result in the error GL_INVALID_OPERATION. You cannot delete a window system allocated memory object using gldeletemem. Attempting to do so will result in the error GL_INVALID_OPERATION. 3.7 Memory Objects and Multiple Contexts Memory objects are shared by a set of contexts, if texture objects are shared by that same set of contexts. OpenGL makes no attempt to synchronize access to memory objects. If a memory object is actively being used in more than one context, then it is up to the programmer to ensure that the contents of the object are not being changed via one context while another context is using the memory object. The results of changing a memory object while another context is using it are undefined.

23 23 of 70 Note, that this behavior mirrors the behavior defined for texture objects in section 2.5 of the GLX 1.3 spec.

24 24 of 70 4 Querying Memory Object State 4.1 Querying Memory Object Properties GLint glgetmemproperty(glmem mem, GLenum property) glgetmemproperty returns the value for the specified property of mem. Capability properties (see Table 3.1 and Section 7.1), structure properties (see Table 3.2 and Section 7.2), configuration properties (see Table 3.3 and Section 7.3), and automatic properties (see Table 3.5 and Section 7.5) can be queried. Allocation properties (see Table 3.4 and Section 7.4) can be queried for non-validated memory objects, but cannot be queried for validated memory objects, because they affect other properties at validation time and are not kept as state in the validated memory objects. 4.2 Querying the Sub Memories of a Memory Object GLmem glgetsubmem(glmem mem, GLenum type, GLuint sub) glgetsubmem returns a sub memory object of mem. type is the sub memory type. sub is the specific sub memory identifier based on the requested type. type GL_MIPMAP 0 to levels 1 GL_CUBE_MAP GL_DEPTH_SLICED 0 to depth 1 Table 4.1 Sub Memory Types and Identifiers If mem does not have the specified sub memory, glgetsubmem will return 0. sub GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_TEXTURE_CUBE_MAP_NEGATIVE_X, GL_TEXTURE_CUBE_MAP_POSITIVE_Y, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y, GL_TEXTURE_CUBE_MAP_POSITIVE_Z, GL_TEXTURE_CUBE_MAP_NEGATIVE_Z If a memory object has multiple sub memory types, the order in which the sub memories are queried does not change the final leaf sub memories that are reached. For example, for a mem that has both mipmap and 3D depth slice sub memories, the following two queries will result in the same sub memory objects. sub_mem = glgetsubmem(glgetsubmem(mem, GL_MIPMAP, 3), GL_DEPTH_SLICED, 11); sub_mem = glgetsubmem(glgetsubmem(mem, GL_DEPTH_SLICED, 11), GL_MIPMAP, 3); 4.3 Querying the Base Memory Object of a Sub Memory Object GLmem glgetbasemem(glmem mem)

25 25 of 70 glgetbasemem returns the base memory object that mem is a sub memory of. If mem is a base memory object mem is returned. 4.4 Checking That a Memory Object Exists GLboolean glismem(glmem mem) glismem returns GL_TRUE is mem is a valid memory object, and GL_FALSE otherwise. A memory object that has been flagged for deletion, but not yet deleted (see section 3.6), is still a valid memory object so GL_TRUE would be returned.

26 26 of 70 5 Manipulating Memory Objects 5.1 Memory Objects Image Specification GLvoid glmemimage(glmem mem, GLenum format, GLenum type, GLvoid *data) GLvoid glcopymemimage2d(glmem mem, GLint x, GLint y) GLvoid glcopymemimage1d(glmem mem, GLint x, GLint y) GLvoid glmemsubimage3d(glmem mem, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLenum type, GLvoid *data) GLvoid glmemsubimage2d(glmem mem, GLint xoffset, GLint yoffset, GLsizei width, GLsizei height, GLenum format, GLenum type, GLvoid *data) GLvoid glmemsubimage1d(glmem mem, GLint xoffset, GLsizei width, GLenum format, GLenum type, GLvoid *data) GLvoid glcopymemsubimage3d(glmem mem, GLint xoffset, GLint yoffset, GLint zoffset, GLint x, GLint y, GLsizei width, GLsizei height) GLvoid glcopymemsubimage2d(glmem mem, GLint xoffset, GLint yoffset, GLint x, GLint y, GLsizei width, GLsizei height) GLvoid glcopymemsubimage1d(glmem mem, GLint xoffset, GLint x, GLint y, GLsizei width) These functions are the memory object equivalents of texture image functions. They provide a way for data to be loaded into a memory object. Since, unlike textures, memory objects are pre-sized and pre-formatted these functions do not affect the size or format of the memory object, and thus fewer arguments are needed. mem is the memory object whose contents will be loaded. All other arguments are identical in purpose to the equivalent texture image functions. The operation of these functions is also identical to the equivalent texture image functions. Memory objects with GL_SAMPLES >= 2 cannot be passed to these commands. Doing so will cause the error GL_INVALID_OPERATION to be generated Memory Objects Image Specification Using glteximage and glcopyteximage Calling glteximage or glcopyteximage on a texture that has a memory object attached to it will specify the contents of a memory object if the dimensions and internalformat of the command exactly match the dimensions and format of the memory object. The error GL_INVALID_VALUE will be generated if the dimensions and format do not match.