| Name |
| |
| EXT_buffer_age |
| |
| Name Strings |
| |
| GLX_EXT_buffer_age |
| |
| Notice |
| |
| Copyright 2011,2012 Intel Cooperation. All rights reserved. |
| |
| Contributors |
| |
| Robert Bragg |
| Neil Roberts |
| James Jones |
| |
| Contacts |
| |
| Robert Bragg, Intel (robert.bragg 'at' intel.com) |
| |
| Status |
| |
| Draft |
| |
| Version |
| |
| 8 - Sept 20, 2012 |
| |
| Number |
| |
| 427 |
| |
| Dependencies |
| |
| Requires GLX 1.4 |
| |
| This extension is written against the wording of the GLX 1.4 |
| Specification. |
| |
| GLX_OML_swap_method trivially interacts with this extension. |
| |
| Overview |
| |
| The aim of this extension is to expose enough information to |
| applications about how the driver manages the set of front and |
| back buffers associated with a given surface to allow applications |
| to re-use the contents of old frames and minimize how much must be |
| redrawn for the next frame. |
| |
| There are lots of different ways for a driver to manage these |
| buffers, from double buffering, different styles of triple |
| buffering and even n-buffering or simply single buffer rendering. |
| We also need to consider that power management events or memory |
| pressure events might also result in some of the buffers not |
| currently in-use being freed. |
| |
| This extension lets applications query the age of the back buffer |
| contents for a GLX surface as the number of frames elapsed since |
| the contents were most recently defined. The back buffer can |
| either be reported as invalid (has an age of 0) or it may be |
| reported to contain the contents from n frames prior to the |
| current frame. |
| |
| Once the application has queried the buffer age, the age of |
| contents remains valid until the end of the frame for all pixels |
| that continue to pass the pixel ownership test. |
| |
| For example if you consider a double buffered application drawing |
| a small spinning icon, but everything else in the scene is static. |
| If we know that 2 buffers are continuously being recycled each |
| time glXSwapBuffers is called then even though 100s of frames may |
| need to be drawn to animate the icon it can be seen that the two |
| buffers are remaining unchanged except within the bounds of the |
| icon. In this scenario ideally the application would simply |
| perform an incremental update of the old buffer instead of |
| redundantly redrawing all the static parts of the scene. The |
| problem up until now though has been that GLX doesn't report how |
| buffers may be recycled so it wasn't safe for applications to try |
| and reuse their contents. Now applications can keep track of all |
| the regions that have changed over the last n frames and by |
| knowing the age of the buffer they know how to efficiently repair |
| buffers that are re-cycled instead of redrawing the entire scene. |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| GLX_BACK_BUFFER_AGE_EXT 0x20F4 |
| |
| Additions to Section 3.3.6 of the GLX 1.4 Specification (Querying Attributes) |
| |
| Add the following text to the description for glXQueryDrawable |
| |
| Querying GLX_BACK_BUFFER_AGE_EXT returns the age of the color |
| contents of the current back-buffer as the number of frames |
| elapsed since it was most recently defined. Applications can, |
| under certain conditions described below, use this age to |
| safely rely on the contents of old back-buffers to potentially |
| reduce the amount of redrawing they do each frame. A frame is |
| the period between calls to any of the functions in table 3.X, |
| hereafter referred to as "frame boundaries." |
| |
| Function name |
| -------------------- |
| glXSwapBuffers |
| glXSwapBuffersMscOML |
| |
| Table 3.X, Frame Boundary Functions |
| |
| Buffers' ages are initialized to 0 at buffer creation time. |
| When a frame boundary is reached, the following occurs before |
| any exchanging or copying of color buffers: |
| |
| * The current back buffer's age is set to 1. |
| * Any other color buffers' ages are incremented by 1 if |
| their age was previously greater than 0. |
| |
| For the purposes of buffer age tracking, a buffer's content |
| is considered defined when its age transitions to a value |
| greater than 0. |
| |
| For example, with a double buffered surface and an |
| implementation that swaps via buffer exchanges, the age would |
| usually be 2. With a triple buffered surface the age would |
| usually be 3. An age of 1 means the previous swap was |
| implemented as a copy. An age of 0 means the buffer has only |
| just been initialized and the contents are undefined. Single |
| buffered drawables have no frame boundaries and therefore |
| always have an age of 0. |
| |
| Frame boundaries are the only events that can set a buffer's |
| age to a positive value. Once GLX_BACK_BUFFER_AGE_EXT has been |
| queried then it can be assumed that the age will remain valid |
| until the next frame boundary. GLX implementations are |
| permitted, but not required, to reset the buffer age in |
| response to pixel ownership test changes for any pixels within |
| the drawable, or if new pixels are added to or removed from |
| the drawable, i.e., the drawable is resized. A reset of this |
| nature does not affect the age of pixels that pass the pixel |
| ownership test before and after the event that caused the |
| reset. In other words, applications can assume that no event |
| will invalidate the content of pixels that continuously pass |
| the pixel test between when the buffer age was queried and the |
| following frame boundary. |
| |
| It is up to applications to track pixel ownership using data |
| collected from window configuration, expose, and any other |
| relevant X events. |
| |
| If the GLX implementation decides to free un-used back-buffers |
| when the system is under memory pressure or in response to |
| power-management events then GLX will return an age of 0 when |
| it allocates a new buffer at the start of a new frame. |
| |
| GLX_BACK_BUFFER_AGE_EXT state, while a property of the GLX |
| drawable that owns the buffers, lives in the address space of |
| the current GL server context. That is, if a GLX drawable is |
| used with multiple direct-rendering contexts in separate |
| processes, the buffer age is not guaranteed to be |
| synchronized across the processes. Similarly, if a GLX |
| drawable is used with both an indirect and a direct context, |
| the buffer age may depend on which context the drawable is |
| bound to when it is queried. However, binding and unbinding a |
| drawable to and from one or more contexts in the same address |
| space will not affect the ages of any buffers in that |
| drawable. |
| |
| Add the following text to the last paragraph of the description for |
| glXQueryDrawable describing error conditions. |
| |
| If querying GLX_BACK_BUFFER_AGE_EXT and <draw> is not bound to |
| the calling thread's current context a GLXBadDrawable error is |
| generated. |
| |
| Dependencies on OpenGL |
| |
| None |
| |
| Dependencies on GLX_OML_sync_control |
| |
| If GLX_OML_sync_control is not supported, glXSwapBuffersMscOML is |
| removed from Table 3.X. |
| |
| Issues |
| |
| 1) How can an application know that all pixels of a re-usable |
| buffer were originally owned by the current context? |
| |
| RESOLVED: It is up to the application to track pixel |
| ownership using existing X11 events, such as expose or |
| configure notify events. |
| |
| 2) What are the semantics if the buffer age attribute is queried |
| for a drawable that isn't bound to the calling thread's |
| context? |
| |
| RESOLVED: we report a GLXBadDrawable error. |
| |
| 3) Is the buffer age tracked in the GLX client or the GLX server? |
| |
| RESOLVED: Querying the buffer age needs to be a fast |
| operation, so it makes sense to track it in the GLX client. |
| However, GLX implementations without support for direct |
| rendering likely won't have any per-drawable client state. |
| Therefore, the buffer age is tracked in the same address space |
| as the current GL server context. For direct rendering, this |
| is the GLX client. For indirect rendering, it is the GLX |
| server. The buffer age is not synchronized between the two |
| when changing contexts. |
| |
| 4) What is the buffer age of a single buffered drawable? |
| |
| RESOLVED: 0. This falls out implicitly from the buffer age |
| calculations, which dictate that a buffer's age starts at 0, |
| and is only incremented by frame boundaries. Since frame |
| boundary functions do not affect single buffered drawables, |
| their age will always be 0. |
| |
| 5) What guarantees are provided after querying the buffer age? |
| |
| RESOLVED: The buffer age of pixels which continue to pass the |
| pixel ownership test must remain valid until the next frame |
| boundary otherwise applications can't be absolutely sure of |
| the consistency of their rendered content. Implementations |
| may reset the queryable age of the buffer when pixel ownership |
| changes occur. This is further clarified in section 3.3.6 |
| |
| Revision History |
| |
| Version 1, 07/02/2012 |
| - First draft |
| Version 2, 08/03/2012 |
| - Document that once the age is queried it remains valid until |
| the end of the frame. |
| Version 3, 08/03/2012 |
| - Clarify that only buffers who's contents were fully owned by |
| the context are tracked. |
| Version 4 21/03/2012 |
| - Document that an error will be generated if querying the age |
| for a drawable not bound to the current context. |
| Version 5 21/08/2012 |
| - Relax pixel ownership requirements |
| - Slightly tweak and explicitly document buffer age calculation |
| - Note that buffer age is tracked in the GLX client when using |
| direct rendering. |
| Version 6 11/09/2012 |
| - Clarify guarantees once the age has been queried |
| Version 7 17/09/2012 |
| - Further clarify pixel age vs. buffer age |
| - Rename GLX_BUFFER_AGE_EXT to GLX_BACK_BUFFER_AGE_EXT |
| - Assign value to GLX_BACK_BUFFER_AGE_EXT |
| Version 8 20/09/2012 |
| - Remove overly precise definition of buffer age |
