On Fri, Jul 22, 2011 at 3:19 AM, Jay Taoko<jay.taoko@xxxxxxxxxxxxx> wrote:
On 7/20/2011 11:34 AM, Marco Trevisan (Treviño) wrote:
2011/7/20 Jay Taoko<jay.taoko@xxxxxxxxxxxxx>:
Hello
Last cycle it was noticed that there is a problem when using the fglrx
driver and Compiz Vsync. I did a few experiments today with an AMD GPU
and
the fglrx driver. Activating Compiz Vsync option negatively impact
Unity's
rendering performance.
Not only on performances: see [1].
[1] https://bugs.launchpad.net/bugs/762918
From what I could gather, Compiz uses the GLX_SGI_video_sync extension to
implement its VSync. Normal OpenGL applications typicaly use
GLX_EXT_swap_control. I wonder if anything prevents Compiz from using this
extension.
I have been running Compiz withits VSync feature disabled. I will try test
it with VSync enable and see if I get a problem similar to the bug report.
We can use this extension, but it operates in a different way to that
compiz actually functions, and from reading the documentation it might
require other work in core.
glXGetVideoSyncSGI and glXWaitVideoSyncSGI allow you to do frame
limiting in line with an internal paint/wakeup clock rather than
blocking on glXSwapBuffers.
So with the SGI extensions you get something like
|poll ()| wake | redraw back buffer | wait for glXWaitVideoSyncSGI
(remaining time) | buffers swapped | poll () ...
And with swap control you'll get
| poll () | wake | redraw back buffer | | block on glXSwapBuffers for
the swap interval time | poll ()
With swap control glXSwapBuffers will block for longer, since it will
wait for the vsync frame before it begins counting to the vsync
afterwards (since there is no internal counter that is reset until a
vblank).
I think that in the case of fglrx though, we can overload
GL::waitVideoSync to return true and use glXSwapIntervalEXT on init to
control swaps.
This should be fixed in the fglrx driver though. It might be worth
looking into the values it returns on glXGetVideoSyncSGI since I think
these are wrong.
Sam
