Unlike the semantics of glXSwapBuffers which doesn't usually have to preserve the contents of the backbuffer, glXCopySubBuffer can be called multiple times though so the driver isn't ever be able to free the backbuffer under memory pressure. We use glXCopySubBufferMESA in Clutter when updating a small region of a ClutterStage and would like to be able to tell the driver when the backbuffer contents can be discarded. Clutter is used by the Mutter compositor and there may be multiple OpenGL applications on hidden/non-active workspaces and it would be ideal for the corresponding backbuffers for those applications to be freed if the system is under memory pressure. Something like glXDiscardBackbufferMESA() could be one possability. Alternatively a swap buffers API that could take a list of rectangles to blit and immediately mark the backbuffer as purgeable might help. (Apologies if I'm missing something and there is already a suitable mechanism.)
There is a mechanism, but we have not implemented it in Mesa yet. I think GL_EXT_discard_framebuffer (link below), should suit your needs. The intended use is with framebuffer objects, but will purge the window backbuffer is the current FBO is 0. If this looks like the right tool, please change the bug subject to "Implement GL_EXT_discard_framebuffer". http://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt I'm adding Kristian to the CC list because he has done a lot of work in this area.
(In reply to comment #1) > There is a mechanism, but we have not implemented it in Mesa yet. I think > GL_EXT_discard_framebuffer (link below), should suit your needs. The intended > use is with framebuffer objects, but will purge the window backbuffer is the > current FBO is 0. > > If this looks like the right tool, please change the bug subject to "Implement > GL_EXT_discard_framebuffer". > > http://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt > > I'm adding Kristian to the CC list because he has done a lot of work in this > area. Yes, this extension looks like it would work for Clutter; thanks Ian.
(In reply to comment #2) > (In reply to comment #1) > > There is a mechanism, but we have not implemented it in Mesa yet. I think > > GL_EXT_discard_framebuffer (link below), should suit your needs. The intended > > use is with framebuffer objects, but will purge the window backbuffer is the > > current FBO is 0. > > > > If this looks like the right tool, please change the bug subject to "Implement > > GL_EXT_discard_framebuffer". > > > > http://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt > > > > I'm adding Kristian to the CC list because he has done a lot of work in this > > area. > > Yes, this extension looks like it would work for Clutter; thanks Ian. And the DRI2CopyRegion request was designed exactly so that you can copy a region (ie a list of rects) in one atomic request and at the same time indicate "end-of-frame". You probably just need a new request to indicate that that is indeed the behaviour you want (DRI2CopyRegion defaults to preserving the backbuffer contents) and then take that into account in the DRI2CopyRegion implementation. What about discarding other aux buffers (stencil, depth etc)?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > There is a mechanism, but we have not implemented it in Mesa yet. I think > > > GL_EXT_discard_framebuffer (link below), should suit your needs. The intended > > > use is with framebuffer objects, but will purge the window backbuffer is the > > > current FBO is 0. > > > > > > If this looks like the right tool, please change the bug subject to "Implement > > > GL_EXT_discard_framebuffer". > > > > > > http://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt > > > > > > I'm adding Kristian to the CC list because he has done a lot of work in this > > > area. > > > > Yes, this extension looks like it would work for Clutter; thanks Ian. > > And the DRI2CopyRegion request was designed exactly so that you can copy a > region (ie a list of rects) in one atomic request and at the same time indicate > "end-of-frame". You probably just need a new request to indicate that that is > indeed the behaviour you want (DRI2CopyRegion defaults to preserving the > backbuffer contents) and then take that into account in the DRI2CopyRegion > implementation. Either exposing a GLX extension that could copy a list of rectangles and end the frame (without preserving the backbuffer) or an explicit discard mechanism could work for Clutter, though the former sounds potentially a bit nicer because it only needs one request at the end of the frame. > > What about discarding other aux buffers (stencil, depth etc)? Clutter could happily tell the driver to discard the stencil and depth too at the end of a frame so maybe a new request could be defined to take a mask of which aux buffers can be discarded after copying a region.
(In reply to comment #3) > What about discarding other aux buffers (stencil, depth etc)? GL_EXT_discard_framebuffer can already do that: const GLenum attachments[] = { GL_COLOR_EXT, GL_DEPTH_EXT, GL_STENCIL_EXT }; glDiscardFramebufferEXT(GL_FRAMEBUFFER, attachments, 3); It sounds like we want GL_EXT_discard_framebuffer and some other extension that enables multiple sub-buffer copy behavior.
(In reply to comment #5) > (In reply to comment #3) > > What about discarding other aux buffers (stencil, depth etc)? > > GL_EXT_discard_framebuffer can already do that: > > const GLenum attachments[] = { GL_COLOR_EXT, GL_DEPTH_EXT, GL_STENCIL_EXT }; > glDiscardFramebufferEXT(GL_FRAMEBUFFER, attachments, 3); > > It sounds like we want GL_EXT_discard_framebuffer and some other extension that > enables multiple sub-buffer copy behavior. Something thing that occurred to me the other day is that glXCopySubBuffer isn't integrated with the concept of a SwapInterval which upsets Clutter quite a bit when we start taking advantage of it because it allows applications to break out of the framerate throttling we try to impose on applications. This suggests that actually having a new extension that lets us copy a region + end the frame + integrate with the swap interval in one go could be more ideal for us.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > What about discarding other aux buffers (stencil, depth etc)? > > > > GL_EXT_discard_framebuffer can already do that: > > > > const GLenum attachments[] = { GL_COLOR_EXT, GL_DEPTH_EXT, GL_STENCIL_EXT }; > > glDiscardFramebufferEXT(GL_FRAMEBUFFER, attachments, 3); > > > > It sounds like we want GL_EXT_discard_framebuffer and some other extension that > > enables multiple sub-buffer copy behavior. > > Something thing that occurred to me the other day is that glXCopySubBuffer > isn't integrated with the concept of a SwapInterval which upsets Clutter quite > a bit when we start taking advantage of it because it allows applications to > break out of the framerate throttling we try to impose on applications. > > This suggests that actually having a new extension that lets us copy a region + > end the frame + integrate with the swap interval in one go could be more ideal > for us. Adapting this extension to GLX sounds ideal for Clutter: http://developer.symbian.org/wiki/images/e/e8/EGL_NOK_swap_region.txt
I'm going to close this bug as fixed. There are several extensions in Mesa that enable various related bits of sub-buffer swapping. If more functionality is needed, please open a new feature request.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.