On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: > >> On 10/11/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: > >> > >>> 3) Share buffers with a reference counting scheme. When a client > >>> notices the buffer needs a resize, do the resize and adjust refcounts - > >>> other clients continue with the older buffer. What happens when a > >>> client on the older buffer calls swapbuffers -- I'm sure we can figure > >>> out what the correct behaviour should be. > >> 3) Sounds like the best solution and it's basically what I'm > >> proposing. > > > > I agree, it looks like this can provide the benefits of shared > > drawable-private renderbuffers (support for cooperative rendering > > schemes, no waste of renderbuffer resources) without compromising the > > general benefits of private renderbuffers. > > Yes, I'm just interested to understand what happens when one of the > clients on the old, orphaned buffer calls swapbuffers... All the > buffers should be swapped, right? Large and small? How does that work? > > If the answer is that we just do the swap on the largest buffer, then > you have to wonder what the point of keeping the smaller ones around > is?
To make 3D drivers nice and simple by not having to deal with fun stuff like cliprects? :) Seriously though, as I understand Kristian's planned scheme, all buffer swaps will be done by the DRM, and I presume it'll only take the currently registered back renderbuffer into account, so the contents of any previous back renderbuffers will be lost. I think that's fine, and should address your concerns? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
