Vblanks, CRTCs and GLX, oh my!

[Michel Dänzer]

On Wed, 2007-09-19 at 09:59 -0700, Jesse Barnes wrote:
> On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote:
> > On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
> > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new
> > > world of dyanmically controlled outputs and CRTCs (at least for
> > > i915 and radeon):  a client trying to sync against the second CRTC
> > > that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC
> > > is enabled, due to the way current interrupt handlers increment the
> > > respective vblank counters (i.e. they increment the correct counter
> > > if both CRTCs are generating events, but only the primary counter
> > > if only one CRTC vblank interrupt is enabled).
> >
> > Yes, I made it that way to allow old Mesa drivers that don't know
> > anything about secondary vblank to work. The trouble is that at least
> > xf86-video-intel currently never enables vblank interrupts for pipe B
> > only, which defeats that purpose. It's really too bad I screwed up
> > trying to make all this backwards compatible, so I'm afraid it looks
> > like we have to bite the bullet and make incompatible changes again
> > to hopefully make things right finally.
> 
> Well I'm not sure you screwed it up, before we had randr1.2 enabled 
> drivers that scheme made a lot of sense. :)

Except I was assuming Intel LVDS panels were driven by pipe A...


> > > One way of making the glX*VideoSyncSGI interfaces behave more or
> > > less as expected would be to make them more like
> > > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to
> > > determine which pipe needs to be sync'd against by passing in the
> > > display plane the client is most tied to (this would imply making
> > > the Intel specific SAREA plane info more generic),
> >
> > Not necessarily - the driver could provide its own versions of the
> > GetMSC and WaitForMSC hooks, or we could make the generic ones use a
> > new driver hook to determine whether to use secondary vblank.
> 
> Yeah, common code would be best.
> 
> 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.

>   - 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.

> 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).


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