← Back to team overview

unity-dev team mailing list archive

Re: [Ayatana-dev] Compiz VSync

 

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

> Jay
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana-dev
> Post to     : ayatana-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sam Spilsbury



Follow ups

References