Bug 13938 - i915 vblank interrupts not always working
i915 vblank interrupts not always working
Status: RESOLVED DUPLICATE of bug 10675
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915
git
Other All
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-04 19:16 UTC by David Schleef
Modified: 2009-08-24 12:29 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
patch (2.17 KB, patch)
2008-01-05 15:44 UTC, David Schleef
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Schleef 2008-01-04 19:16:39 UTC
chipset: 945GM
versions: * from git master

When running anything GL related on the CRT output, I get:

do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.

This appears after a 3 second timeout.  Backtrace during the timeout:

ginger:~/xorg/jhbuild/git/mesa/progs/xdemos$ gdb ./glxgears
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r
Starting program: /home/ds/xorg/jhbuild/git/mesa/progs/xdemos/glxgears 
[Thread debugging using libthread_db enabled]
[New Thread -1214105920 (LWP 7690)]

Program received signal SIGINT, Interrupt.
[Switching to Thread -1214105920 (LWP 7690)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d3e8b9 in ioctl () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7a4b9ae in drmWaitVBlank (fd=6, vbl=0xbfb21d24) at xf86drm.c:1857
#3  0xb780d1a2 in do_wait (vbl=0xfffffffc, vbl_seq=0xbfb21d24, fd=-1072667590)
    at ../common/vblank.c:282
#4  0xb780d27c in driDrawableInitVBlank (priv=0x8056e98)
    at ../common/vblank.c:336
#5  0xb7830d6f in intelMakeCurrent (driContextPriv=0x80536b0, 
    driDrawPriv=0x8056e98, driReadPriv=0x8056e98) at intel_context.c:679
#6  0xb780df84 in driBindContext (ctx=0x80570c4, pdraw=0x8085cc0, 
    pread=0x8085cc0) at ../common/dri_util.c:213
#7  0xb7e1642e in MakeContextCurrent (dpy=0x804c008, draw=58720258, 
    read=58720258, gc=0x8057010) at glxext.c:1647
#8  0xb7e166fc in glXMakeCurrent (dpy=0x804c008, draw=58720258, gc=0x8057010)
    at glxext.c:1822
#9  0x0804a3fe in main (argc=1, argv=0xbfb220d4) at glxgears.c:601


Right after an X restart, the LVDS output does not show this problem.  However, after running xrandr several times, they both show the problem.
Comment 1 David Schleef 2008-01-04 23:29:00 UTC
I sort of figured out why this is happening.  It appears a rendering context is picking up the initial sequence number from one pipe, and then the context draws to a window on the other pipe.  Then, when you wait based on the wrong base sequence number, you either time out or don't wait long enough.
Comment 2 David Schleef 2008-01-05 15:44:23 UTC
Created attachment 13544 [details] [review]
patch

vblank counters correspond to the drm primary/secondary, not the i915 pipe.  Fix the i915 irq code accordingly.

With this patch, libGL startup no longer fails on both the primary and secondary displays.  Also, vblank synchronization works on secondary display (CRT).  It occasionaly fails to synchronize on the primary display (LVDS), for unknown reasons.  In any case, the vblank counters are being updated correctly.
Comment 3 Michel Dänzer 2008-01-07 00:49:10 UTC
Semantically, it doesn't seem to matter whether the pipe<->plane mapping is checked in the interrupt handler or wait function, so I suspect what really makes the difference is changing the semantics when only one 'pipe' is enabled in dev_priv->vblank_pipe. This may or may not be a good idea; considering the interactions with different versions of Mesa boggles my mind right now. :}
Comment 4 Jesse Barnes 2008-01-07 09:23:37 UTC
Yeah, that's a tough one.  Changing the pipe<->plane mapping seems to be fundamentally at odds with the current scheme's "use the primary counter if only one pipe is enabled" logic.  Is there any software out there that depends on that behavior?

Maybe it doesn't matter much, seems like something will break no matter what we do (including if we do nothing).
Comment 5 Michel Dänzer 2008-01-07 09:34:19 UTC
(In reply to comment #4)
> Changing the pipe<->plane mapping seems to be fundamentally at odds with the
> current scheme's "use the primary counter if only one pipe is enabled" logic. 
> Is there any software out there that depends on that behavior?

Mainly old Mesa drivers that didn't know about secondary vblank (I think - unless the reversed pipe<->plane mapping magically fixes that :).
Comment 6 Gordon Jin 2008-03-24 22:25:06 UTC

*** This bug has been marked as a duplicate of bug 10675 ***
Comment 7 ajax at nwnk dot net 2009-08-24 12:29:08 UTC
Mass version move, cvs -> git