Vblanks, CRTCs and GLX, oh my!

[Jesse Barnes]

On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote:
> > So:
> >   - use the vblank-rework tree to make per-CRTC vblank counters (as
> > you
> >     say, this breaks some setups but will fix others)
>
> Out of curiosity, what setups are you thinking of that this will fix on
> its own? Can't think of any offhand.

It should fix the case where a client is waiting on pipe B when vblank 
interrupts on pipe A go from off to on.  Currently, that'll cause the client 
to switch to the wrong vblank counter after pipe A's interrupts become 
active.  In the vblank rework tree, it'll either not work in the first place 
(because it's using the wrong counter) or it'll work and keep working due to 
passing in DRM_VBLANK_SECONDARY.  I think this is the correct behavior.

> >   - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
> >     correctly
>
> One idea (with some handwaving :) would be the common code keeping
> around a pointer to the driver's vblank_flags variable or keeping track
> of the flags per drawable in some other sensible way.

Yeah, if it can be kept generic I think that would be good.

> > That should make the current stack work fairly well.  And when there's a
> > real need, we can look at adding multipipe aware extensions.
>
> My gut feeling is we'd be better off without apps or even toolkits
> dealing with this directly. So long as everything's keyed off the
> drawable, the GLX implementation should mostly be able to do the right
> thing on its own. One exception being cloned (or at least overlapping)
> setups where the CRTC modes aren't in sync. My idea for that has been a
> driconf option to choose which CRTC to sync to in case the drawable is
> visible on both CRTCs).

Yeah, makes sense.  If we get this right there shouldn't be much need for 
exposing clients to the pipe layouts directly.

Jesse