[PATCH 3/3] DRI2: defer swap if relevant CRTC is in DMPS off state

[Michel Dänzer]

On Die, 2012-12-18 at 09:53 -0500, Ilija Hadzic wrote: 
> >>
> >> and such information would not be per-drawable anyway (it would be per-CRTC).
> >
> > Eh? The MSC and related values are properties of the drawable, not the
> > CRTC (there is no concept of a CRTC in GLX/DRI2 at all). Only tracking
> > this per CRTC will break with several clients synchronizing to the same
> > CRTC.
> 
> I understand that, but let me try to clarify what I had in mind,
> although it may be moot in the light of what I said above. Sure MSC is
> maintained per-drawable, but my understanding is (please correct me if
> I am missing something) that when a drawable is displayed on a CRTC,
> the values it will get for MSC will be the vblank counters that
> originate from the CRTC. So if two drawables are on the same CRTC,
> their MSCs will be in lock-step. So when the CRTC is disabled (i.e.,
> its vblank counters are not progressing) and the user space takes over
> the role of producing "emulated" counters, it can do this by
> maintaining this emulated count on per-CRTC basis.

That's true for the MSC itself, but your patches also only track the
last swap MSC and timestamp per CRTC, which breaks with several
drawables synchronizing to the same CRTC.


> Anyway, given that the fix will probably spread to other GPUs and that
> it may involve changes to the xserver code, I think I can do this your
> way.

It's not about my (or anyone's) way, but I think there's two basic
approaches:

     1. Mimic the behaviour with a running CRTC as closely as possible 
     2. Don't bother, just always wait for a fixed amount of time, say
        some fraction of a second

I fail to see the point of a flawed compromise.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer