From: Jesse B. <jb...@vi...> - 2007-09-19 16:59:26
|
On Wednesday, September 19, 2007 3:52 am Michel D=C3=A4nzer 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=20 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=20 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=20 real need, we can look at adding multipipe aware extensions. I can finish up the Intel bits, but the vblank-rework tree still needs=20 mach64, mga, r128 and via updated. And the Mesa parts of those drivers=20 need updating to handle multiple pipes. Anyone have time to tackle=20 those? Thanks, Jesse |