Vblanks, CRTCs and GLX, oh my!

[Michel Dänzer]

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.

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


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

> letting the DRM take care of the rest.

Yes, this has been my idea, but I haven't got around to actually playing
with it.


> And no matter the outcome, we should encourage people to use interfaces 
> like DRM_I915_VBLANK_SWAP rather than glXWaitVideoSyncSGI, otherwise 
> they'll be highly susceptible to unpredictable scheduling hiccups.

Right, i.e. right now use GLX_SGI_swap_control instead of
GLX_SGI_video_sync whenever possible.


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