-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Barnes wrote: > Both the generic DRM vblank-rework and Intel specific pipe/plane > swapping have uncovered some vblank related problems which we discussed > at XDS last week. Unfortunately, no matter what we do (including > the "do nothing" option), some applications will break some of the time > in the new world order. > > Basically we have a few vblank related bits of code: > 1) DRM_IOCTL_WAIT_VBLANK - core DRM vblank wait ioctl > 2) driver interrupt code - increments appropriate vblank counter > 3) DRM_I915_VBLANK_SWAP - Intel specific scheduled swap ioctl > 4) SAREA private data - used for tracking which gfx plane to swap > 5) glX*VideoSyncSGI - GL interfaces for sync'ing to vblank events > > 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).
We basically implemented DRM_IOCTL_WAIT_VBLANK as an easy way to migrate existing driver swap code to support glXSwapIntervalSGI. > The Intel specific DRM_I915_VBLANK_SWAP is a really nice interface, and > is the only reliable way to get tear free vblank swap on a loaded > system. However, what it really cares about is display planes (in the > Intel sense), so it uses the _DRM_VBLANK_SECONDARY flag to indicate > whether it wants to flip plane A or B. Whether or not to pass the > _DRM_VBLANK_SECONDARY flag is determined by DRI code based on the SAREA > private data that describes how much of a given client's window is > visible on either pipe. This should work fine as of last week's mods > and only the DDX and DRM code have to be aware of potential pipe->plane > swapping due to hardware limitations. > > 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. glXVideoSyncSGI and glXSwapIntervalSGI really are crappy interfaces. OpenML supplanted them with glXWaitForMscOML and glXSwapBuffersMscOML. The newer interfaces are a superset of the old, and we should look to implementing them as such. > So, what to do? 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), letting the DRM take care of the rest. > > Another option (which could be done in addition to the above) would be > to add some new CRTC-aware interfaces along with ways at getting at > current CRTC/display plane for a client (does GL already have this?). No. Core GL doesn't even know about windows or screens. GLX knows about displays and drawables, and that's 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. Something like DRM_I915_VBLANK_SWAP should be used to implement either glXSwapIntervalSGI or glXSwapBuffersMscOML. To be honest, I'm not sure what real-world use an application could have for the glXWait interfaces. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8VpBX1gOwKyEAw8RAmmfAJ0eq1B1CEkp/ofo86kvGBgIK5MptwCffpHA vaBiGHXYPuh9wi0MS+Zttk0= =U+Cb -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
