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.
If you get to the point where you could measure the speed of
GLX_MESA_copy_sub_buffer vs. glCopyPixels that'd be interesting.
But if your gut feeling is that GLX_MESA_copy_sub_buffer would be
better, we can go with that.
-Brian
-------------------------------------------------------
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
