Waiting for vertical refresh on Intel 965 and 945 chips in recent git
xavier.bestel at free.fr
Fri Jun 8 08:24:46 PDT 2007
On Fri, 2007-06-08 at 16:20 +0100, Torgeir Veimo wrote:
> On 8 Jun 2007, at 12:18, Hamish Moffatt wrote:
> > On Fri, Jun 08, 2007 at 08:23:05AM +0200, Michel Dänzer wrote:
> >> On Thu, 2007-06-07 at 18:00 +0100, Simon Farnsworth wrote:
> >>> In the 7.2 release, I could use the DRM directly to wait for
> >>> vertical
> >>> blanking, using the DRM_IOCTL_WAIT_VBLANK ioctl. The intel driver
> >>> has
> >>> been changed to only enable the interrupt if 3D is in use, so I
> >>> reworked
> >>> my code to use the GLX_SGI_video_sync extension to wait for VBlank.
> >>> I am now finding that the OpenGL based wait for VBlank also fails
> >>> if the
> >>> window I create to get an OpenGL context is fully obscured;
> >>> glXWaitVideoSyncSGI returns 5 (GLX_BAD_CONTEXT). My code
> >>> automatically
> >>> falls back to trying the DRM method, but DRM_IOCTL_WAIT_VBLANK
> >>> returns
> >>> 16 (EBUSY).
> >> Yes, this is because the X server DRI layer now counts DRI windows
> >> according to visibility, to allow e.g. page flipping to work with
> >> multiple windows as long as only one of them is visible. So the intel
> >> driver can't tell the difference between a window being invisible
> >> and it
> >> not existing at all and disables the vblank interrupts.
> > How is "3D in use" defined?
> > MythTV uses DRM vertical blanking sync with Xv output; I wouldn't
> > say it
> > uses 3D by any stretch of the imagination.
> If the screensaver is disabled, as is often the case when a media
> player runs full screen, can't that be a toggle to always turn on
> vblank irqs?
Why can't vblank be enabled only when the DRM_IOCTL_WAIT_VBLANK ioctl is
called ? Is that because OpenGL hangs on to it ?
More information about the xorg