1Name 2 3 EXT_buffer_age 4 5Name Strings 6 7 GLX_EXT_buffer_age 8 9Notice 10 11 Copyright 2011,2012 Intel Cooperation. All rights reserved. 12 13Contributors 14 15 Robert Bragg 16 Neil Roberts 17 James Jones 18 19Contacts 20 21 Robert Bragg, Intel (robert.bragg 'at' intel.com) 22 23Status 24 25 Draft 26 27Version 28 29 8 - Sept 20, 2012 30 31Number 32 33 427 34 35Dependencies 36 37 Requires GLX 1.4 38 39 This extension is written against the wording of the GLX 1.4 40 Specification. 41 42 GLX_OML_swap_method trivially interacts with this extension. 43 44Overview 45 46 The aim of this extension is to expose enough information to 47 applications about how the driver manages the set of front and 48 back buffers associated with a given surface to allow applications 49 to re-use the contents of old frames and minimize how much must be 50 redrawn for the next frame. 51 52 There are lots of different ways for a driver to manage these 53 buffers, from double buffering, different styles of triple 54 buffering and even n-buffering or simply single buffer rendering. 55 We also need to consider that power management events or memory 56 pressure events might also result in some of the buffers not 57 currently in-use being freed. 58 59 This extension lets applications query the age of the back buffer 60 contents for a GLX surface as the number of frames elapsed since 61 the contents were most recently defined. The back buffer can 62 either be reported as invalid (has an age of 0) or it may be 63 reported to contain the contents from n frames prior to the 64 current frame. 65 66 Once the application has queried the buffer age, the age of 67 contents remains valid until the end of the frame for all pixels 68 that continue to pass the pixel ownership test. 69 70 For example if you consider a double buffered application drawing 71 a small spinning icon, but everything else in the scene is static. 72 If we know that 2 buffers are continuously being recycled each 73 time glXSwapBuffers is called then even though 100s of frames may 74 need to be drawn to animate the icon it can be seen that the two 75 buffers are remaining unchanged except within the bounds of the 76 icon. In this scenario ideally the application would simply 77 perform an incremental update of the old buffer instead of 78 redundantly redrawing all the static parts of the scene. The 79 problem up until now though has been that GLX doesn't report how 80 buffers may be recycled so it wasn't safe for applications to try 81 and reuse their contents. Now applications can keep track of all 82 the regions that have changed over the last n frames and by 83 knowing the age of the buffer they know how to efficiently repair 84 buffers that are re-cycled instead of redrawing the entire scene. 85 86New Procedures and Functions 87 88 None 89 90New Tokens 91 92 GLX_BACK_BUFFER_AGE_EXT 0x20F4 93 94Additions to Section 3.3.6 of the GLX 1.4 Specification (Querying Attributes) 95 96 Add the following text to the description for glXQueryDrawable 97 98 Querying GLX_BACK_BUFFER_AGE_EXT returns the age of the color 99 contents of the current back-buffer as the number of frames 100 elapsed since it was most recently defined. Applications can, 101 under certain conditions described below, use this age to 102 safely rely on the contents of old back-buffers to potentially 103 reduce the amount of redrawing they do each frame. A frame is 104 the period between calls to any of the functions in table 3.X, 105 hereafter referred to as "frame boundaries." 106 107 Function name 108 -------------------- 109 glXSwapBuffers 110 glXSwapBuffersMscOML 111 112 Table 3.X, Frame Boundary Functions 113 114 Buffers' ages are initialized to 0 at buffer creation time. 115 When a frame boundary is reached, the following occurs before 116 any exchanging or copying of color buffers: 117 118 * The current back buffer's age is set to 1. 119 * Any other color buffers' ages are incremented by 1 if 120 their age was previously greater than 0. 121 122 For the purposes of buffer age tracking, a buffer's content 123 is considered defined when its age transitions to a value 124 greater than 0. 125 126 For example, with a double buffered surface and an 127 implementation that swaps via buffer exchanges, the age would 128 usually be 2. With a triple buffered surface the age would 129 usually be 3. An age of 1 means the previous swap was 130 implemented as a copy. An age of 0 means the buffer has only 131 just been initialized and the contents are undefined. Single 132 buffered drawables have no frame boundaries and therefore 133 always have an age of 0. 134 135 Frame boundaries are the only events that can set a buffer's 136 age to a positive value. Once GLX_BACK_BUFFER_AGE_EXT has been 137 queried then it can be assumed that the age will remain valid 138 until the next frame boundary. GLX implementations are 139 permitted, but not required, to reset the buffer age in 140 response to pixel ownership test changes for any pixels within 141 the drawable, or if new pixels are added to or removed from 142 the drawable, i.e., the drawable is resized. A reset of this 143 nature does not affect the age of pixels that pass the pixel 144 ownership test before and after the event that caused the 145 reset. In other words, applications can assume that no event 146 will invalidate the content of pixels that continuously pass 147 the pixel test between when the buffer age was queried and the 148 following frame boundary. 149 150 It is up to applications to track pixel ownership using data 151 collected from window configuration, expose, and any other 152 relevant X events. 153 154 If the GLX implementation decides to free un-used back-buffers 155 when the system is under memory pressure or in response to 156 power-management events then GLX will return an age of 0 when 157 it allocates a new buffer at the start of a new frame. 158 159 GLX_BACK_BUFFER_AGE_EXT state, while a property of the GLX 160 drawable that owns the buffers, lives in the address space of 161 the current GL server context. That is, if a GLX drawable is 162 used with multiple direct-rendering contexts in separate 163 processes, the buffer age is not guaranteed to be 164 synchronized across the processes. Similarly, if a GLX 165 drawable is used with both an indirect and a direct context, 166 the buffer age may depend on which context the drawable is 167 bound to when it is queried. However, binding and unbinding a 168 drawable to and from one or more contexts in the same address 169 space will not affect the ages of any buffers in that 170 drawable. 171 172 Add the following text to the last paragraph of the description for 173 glXQueryDrawable describing error conditions. 174 175 If querying GLX_BACK_BUFFER_AGE_EXT and <draw> is not bound to 176 the calling thread's current context a GLXBadDrawable error is 177 generated. 178 179Dependencies on OpenGL 180 181 None 182 183Dependencies on GLX_OML_sync_control 184 185 If GLX_OML_sync_control is not supported, glXSwapBuffersMscOML is 186 removed from Table 3.X. 187 188Issues 189 190 1) How can an application know that all pixels of a re-usable 191 buffer were originally owned by the current context? 192 193 RESOLVED: It is up to the application to track pixel 194 ownership using existing X11 events, such as expose or 195 configure notify events. 196 197 2) What are the semantics if the buffer age attribute is queried 198 for a drawable that isn't bound to the calling thread's 199 context? 200 201 RESOLVED: we report a GLXBadDrawable error. 202 203 3) Is the buffer age tracked in the GLX client or the GLX server? 204 205 RESOLVED: Querying the buffer age needs to be a fast 206 operation, so it makes sense to track it in the GLX client. 207 However, GLX implementations without support for direct 208 rendering likely won't have any per-drawable client state. 209 Therefore, the buffer age is tracked in the same address space 210 as the current GL server context. For direct rendering, this 211 is the GLX client. For indirect rendering, it is the GLX 212 server. The buffer age is not synchronized between the two 213 when changing contexts. 214 215 4) What is the buffer age of a single buffered drawable? 216 217 RESOLVED: 0. This falls out implicitly from the buffer age 218 calculations, which dictate that a buffer's age starts at 0, 219 and is only incremented by frame boundaries. Since frame 220 boundary functions do not affect single buffered drawables, 221 their age will always be 0. 222 223 5) What guarantees are provided after querying the buffer age? 224 225 RESOLVED: The buffer age of pixels which continue to pass the 226 pixel ownership test must remain valid until the next frame 227 boundary otherwise applications can't be absolutely sure of 228 the consistency of their rendered content. Implementations 229 may reset the queryable age of the buffer when pixel ownership 230 changes occur. This is further clarified in section 3.3.6 231 232Revision History 233 234 Version 1, 07/02/2012 235 - First draft 236 Version 2, 08/03/2012 237 - Document that once the age is queried it remains valid until 238 the end of the frame. 239 Version 3, 08/03/2012 240 - Clarify that only buffers who's contents were fully owned by 241 the context are tracked. 242 Version 4 21/03/2012 243 - Document that an error will be generated if querying the age 244 for a drawable not bound to the current context. 245 Version 5 21/08/2012 246 - Relax pixel ownership requirements 247 - Slightly tweak and explicitly document buffer age calculation 248 - Note that buffer age is tracked in the GLX client when using 249 direct rendering. 250 Version 6 11/09/2012 251 - Clarify guarantees once the age has been queried 252 Version 7 17/09/2012 253 - Further clarify pixel age vs. buffer age 254 - Rename GLX_BUFFER_AGE_EXT to GLX_BACK_BUFFER_AGE_EXT 255 - Assign value to GLX_BACK_BUFFER_AGE_EXT 256 Version 8 20/09/2012 257 - Remove overly precise definition of buffer age 258