On Thu, 2006-03-09 at 08:55 -0700, Brian Paul wrote: > David Reveman wrote: > > On Thu, 2006-03-09 at 07:34 -0700, Brian Paul wrote: > > > >>David Reveman wrote: > >> > >>>Biggest problem with using Xgl and compiz on DRI drivers is that I can't > >>>efficiently update part of the screen. On proprietary drivers it's > >>>efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels. > >>> > >>>The attached patch for mesa 6.4.2 is just something I created to prove > >>>that Xgl and compiz runs very well on the Intel driver once this is > >>>fixed. > >>> > >>>I'd like to get this solved asap. I suggest that we add support for > >>>GLX_MESA_copy_sub_buffer. If I remove the CopyPixel hack from my Intel > >>>driver patch, that's pretty much what we have. > >>> > >>>Xgl will use GLX_MESA_copy_sub_buffer instead of CopyPixels when > >>>available and we'll add protocol support so that compositing managers > >>>can use it. > >>> > >>>Thoughts? > >>> > >>>I'll probably go ahead and get this done in the next few days if no one > >>>objects. > >> > >>Is there anything wrong with just using glCopyPixels all the time? If > >>it's just a matter of speed, we can certainly try to optimize that path. > > > > > > I just thought that something like GLX_MESA_copy_sub_buffer would be > > easier to get efficient and as buffer swapping doesn't require a context > > to be current, I though that could makes things faster for the case > > where we have screen updates being done synced to vblank in a separate > > thread (avoiding two context switches every time we update the screen). > > That's a good point, actually. Though, don't we need to effectively > do a context switch in the driver for glXCopySubBufferMESA() in order > to issue the copy/blit? > > For a long time (probably still true in some/all cases) the DRI > drivers' SwapBuffer() routine only worked on the window which was > bound to the current rendering context. > > Looking at intelSwapBuffers(), it looks like we still have some sort > of current context restriction on SwapBuffers(). That should be > looked into.
Yes, I think the drawable needs to be associated with a context but I don't think the context is actually made current unless there are pending rendering commands. So this should work fine with the code I currently have for threaded buffer swapping synced to vblank. > > > If you get to the point where you could measure the speed of > GLX_MESA_copy_sub_buffer vs. glCopyPixels that'd be interesting. Yes, I should do that. > > But if your gut feeling is that GLX_MESA_copy_sub_buffer would be > better, we can go with that. It will be really easy to add so I'll create a patch and we'll see how it works out. -David ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
