[RFC] wl_surface video protocol extension

[Pekka Paalanen]

On Mon, 21 Oct 2013 10:50:05 -0400
Frederic Plourde <frederic.plourde at collabora.co.uk> wrote:

> On 13-10-18 05:59 PM, James Courtier-Dutton wrote:
> > We would also need the API to be compatible with "G-Sync".
> >
> > http://www.pcper.com/news/Graphics-Cards/NVIDIA-Announces-G-Sync-Variable-Refresh-Rate-Monitor-Technology
> >
> >
>  From my understanding of GSYNC, the monitor refresh rate will be 
> completely slaved to the GPU rendering (frame) rate. No need to 
> wait/sync on vblanks, as the monitor will scanout the buffer when it 
> ready (presented). I will start thinking about implications this could 
> have on the protocol we're devising atm, but I guess all in all, GSYN 
> will just going to make everything even simpler.. tho I'm not sure it'd 
> change anything protocol-wise.

Protocol-wise it means the whole concept of "constant monitor
refresh rate" is gone. You don't have a single frequency at a time,
you have probably a minimum and maximum frame cycle length in, say,
microseconds.

Would be nice to get more technical detais of that thing.

The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe how GSYNC affects timings.

I also expect video player timing algorithms to need to actually
take GSYNC into account, or they might become unstable as there is
no constant refresh rate. At least they would need to know about
GSYNC to take advantage of it.

IOW, I'm not sure it's worth to design support for GSYNC at the
moment. I am tempted to say that let's leave it for another
extension (should not be too hard or invasive to add later, as the
only thing changing is the concept of output refresh rate, right?),
and wait for the hardware to be widely adopted. Oh, and also driver
support?


Thanks,
pq