Vblanks, CRTCs and GLX, oh my!

[Jesse Barnes]

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

> > The vblank-rework branch of the DRM tree tries to address (1) and
> > (2) by splitting the logic for handling CRTCs and their associated
> > vblank interrupts into discrete paths, but this defeats the
> > original purpose of the driver interrupt code that tries to fall
> > back to a single counter, which is due to limitations in (5),
> > namely that the glX*VideoSyncSGI APIs can only handle a single
> > pipe.
>
> Right, it would be nice if we could preserve the above with
> vblank-rework.
>
> Or, I guess another option would be to stop caring about old Mesa
> drivers that don't know about secondary vblank and to just make sure
> things work as well as possible when vblank interrupts are enabled
> for both pipes. But note that 'old drivers' currently includes i965
> and all Radeon drivers.

Given that some of this will break no matter what, I like this option 
better.

> > 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)
  - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
    correctly

That should make the current stack work fairly well.  And when there's a 
real need, we can look at adding multipipe aware extensions.

I can finish up the Intel bits, but the vblank-rework tree still needs 
mach64, mga, r128 and via updated.  And the Mesa parts of those drivers 
need updating to handle multiple pipes.  Anyone have time to tackle 
those?

Thanks,
Jesse