1Name 2 3 ATI_meminfo 4 5Name Strings 6 7 GL_ATI_meminfo 8 9Contributors 10 11 Roy Blackmer, ATI Technologies 12 Bruno Stefanizzi, ATI Technologies 13 Andreas Wolf, ATI Technologies 14 Evan Hart, ATI Technologies 15 16Contact 17 18 Bruno Stefanizzi, AMD (bruno.stefanizzi 'at' amd.com) 19 20Status 21 22 ??? 23 24Version 25 26 Date: March 2, 2009 27 Revision: 0.2 28 29Number 30 31 359 32 33Dependencies 34 35 OpenGL 1.1 is required 36 37 ARB_vertex_buffer_object affects the defintion of this extension 38 39 EXT_framebuffer_object affects the definition of this extension 40 41 This extension is written against the 2.0 version of the OpenGL 42 Specification, modified with EXT_framebuffer_object. 43 44Overview 45 46 Traditionally, OpenGL has treated resource management as a task of hardware 47 virtualization hidden from applications. While providing great portability, 48 this shielding of information can prevent applications from making 49 intelligent decisions on the management of resources they create. For 50 instance, an application may be better served by choosing a different 51 rendering method if there is not sufficient resources to efficiently 52 utilize its preferred method. 53 54Issues 55 56 1) Revealing the management of memory directly is somewhat controversial, 57 is this really desirable? 58 59 The intent of this extension is to provide insight into the consumption 60 of memory. It does not require that exact values be returned. The 61 information is intended to be a hint to the application about the 62 status at a particular moment in time. As such, the value returned does 63 not need to reveal the exact information, but instead it could return 64 a conservative value of 80% of actual availability. In any case, it is 65 highly reccommended that the information be returned in kilobytes. 66 67 2) Memory can come from different pools that may interact. How should this 68 be dealt with? 69 70 The queries will enumerate different classes of memory based on modern 71 OpenGL paradigms. The classes defined so far are texture, vertex 72 buffer, an render buffer. These correspond to API visible capabilities 73 such as readable, writable, and mapable. The memory between these pools 74 may often be shared, so allocations in one pool may reduce all pools. 75 76 3) Are the abreviations and names correct? 77 78 Probably not. 79 80 4) How should the values be returned? 81 82 Returning all information about a memory type in a single query is 83 most optimal. Values are returned as 4 integers: total pool available, 84 largest pool available, total auxilliary pool available, and largest 85 auxilliary pool available. Auxilliary pool are for remote memory. 86 87New Functions and Procedures 88 89 None 90 91New Tokens 92 93 Accepted by the <value> parameter of GetIntegerv: 94 95 VBO_FREE_MEMORY_ATI 0x87FB 96 TEXTURE_FREE_MEMORY_ATI 0x87FC 97 RENDERBUFFER_FREE_MEMORY_ATI 0x87FD 98 99Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation) 100 101 None 102 103Additions to Chapter 3 of the 2.0 Specification (Rasterization) 104 105 None 106 107Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations 108and the Frame Buffer) 109 110 None 111 112Additions to Chapter 5 of the 2.0 Specification (Special Functions) 113 114 None 115 116Additions to Chapter 6 of the 2.0 Specification (State and State Requests) 117 118 Section 6.1.x, Memory Information Queries 119 120 Inserted between sections 6.1.14 and 6.1.15 121 122 Information on the current memory resources available can be queried 123 by specifying VBO_FREE_MEMORY_ATI, TEXTURE_FREE_MEMORY_ATI, or 124 RENDERBUFFER_FREE_MEMORY_ATI as the value parameter to GetIntergerv. 125 These return the memory status for pools of memory used for vertex 126 buffer objects, textures, and render buffers respectively. The 127 memory status is not meant to be an exact measurement of the system's 128 current status (though it may be in some implementations), but it is 129 instead meant to represent the present load such that an application 130 can make decisions on how aggressive it can be on the allocation of 131 resources without overloading the system. The query returns a 4-tuple 132 integer where the values are in Kbyte and have the following meanings: 133 134 param[0] - total memory free in the pool 135 param[1] - largest available free block in the pool 136 param[2] - total auxiliary memory free 137 param[3] - largest auxiliary free block 138 139 These values are only useful as a hint as the implementation cannot 140 guarantee the lack of allocations between commands, and the 141 information may have changed before the attempt to use it. Auxiliary 142 memory is memory that an implementation may use as a backup to its 143 primary pool for a certain type of allocation. The pools are not 144 guaranteed to be either independent or shared, as this is an 145 implementation choice. 146 147Additions to the OpenGL Shading Language specification 148 149 None 150 151Additions to the GLX Specification 152 153 None 154 155Dependencies on ARB_vertex_buffer_object or OpenGL version 1.5 156 157 If ARB_vertex_buffer_object or OpenGL version 1.5 is supportedd, then 158 the query for VBO_FREE_MEMORY_ATI is available. 159 160Dependencies on EXT_framebuffer_object 161 162 If EXT_framebuffer_object is implemented, then the query for 163 RENDERBUFFER_FREE_MEMORY_ATI is available. 164 165Errors 166 167 None 168 169GLX protocol 170 171 None 172 173Revision History 174 175 2009/03/02 (Jon Leech) - format version 0.2 received from ATI 176 to remove GL_ prefix, assign extension number. 177