| Summary: | i915 vblank interrupts not always working | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | David Schleef <ds> |
| Component: | Drivers/DRI/i915 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | patch | ||
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. 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. 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. :} 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). (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 :). *** This bug has been marked as a duplicate of bug 10675 *** Mass version move, cvs -> git |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.