Summary: | Cloned screens with different res/refresh cause problems with mesa demos since new dri2 vsync. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Andy Furniss <adf.lists> | ||||||
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | mario.kleiner, nbowler | ||||||
Version: | git | ||||||||
Hardware: | All | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 27592 | ||||||||
Attachments: |
|
Description
Andy Furniss
2010-06-04 04:28:02 UTC
DRI2 synchronization is handled by the X driver. Created attachment 36178 [details] [review] Testpatch for dualhead hang when moving windows. This quick & dirty patch disables the pPriv->last_swap_target mechanism for implementing arbitrary swap_intervals for glXSwapBuffers with the DRI2 swap & sync bits. Any swap interval > 0 is effectively treated as a swap interval of 1 (=vsync'ed swap). A zero swap_interval means immediate swap. This should avoid hangs of windows (no longer updating) when they are moved from a crtc with a higher refresh rate (e.g., 60 Hz) to a crtc with a lower refresh rate (e.g., 50 Hz). Assumed reason for the hang is that crtc's with different refresh rate will differ / drift apart in their vblank counts after some time has passed. For each drawable, the x-server keeps track of the last vblank count for which a bufferswap was scheduled for a drawable in pPriv->last_swap_target. In successive glXSwapBuffers() calls, this value is used as baseline for scheduling the swap to satisfy the chosen pPriv->swap_interval. If a window moves between crtc's, pPriv->last_swap_target is not updated prior to swap to take the difference in vblank counts between old and new crtc into account. Therefore a swap is scheduled far in the future, which causes the window to hang for many seconds or minutes. This quick & dirty patch forces swap at next vblank if swap_interval is > 0, ignoring the stale last_swap_target value. (In reply to comment #2) > Created an attachment (id=36178) [details] > Testpatch for dualhead hang when moving windows. I will test this - but current (unpatched) xserver master is not working for me, so it may not be today if I run out of time finding why. (In reply to comment #3) > (In reply to comment #2) > > Created an attachment (id=36178) [details] [details] > > Testpatch for dualhead hang when moving windows. > > I will test this - but current (unpatched) xserver master is not working for > me, so it may not be today if I run out of time finding why. The Patch fixes the issue, I had to apply by hand on the latest xserver master that works for me. Created attachment 36250 [details] [review] Fix hang in glXSwapBuffers if drawable has moved between crtc's. Thanks for testing. If you want you can try this new patch as well - you'll need to revert the old one first. It is a more clever solution, i already tested in on a dual-head machine and will send it for inclusion into master / 1.8. But a bit of extra testing never hurts. This patch detects if a drawable has moved from a "faster" crtc with higher refresh rate to a "slower" crtc with lower refresh rate. If so, it resets last_swap_target to the current vblank count of the current slow crtc to avoid the hang. The patch does nothing when moving from a slow to a fast crtc as that fixes itself automagically. (In reply to comment #5) > Created an attachment (id=36250) [details] > Fix hang in glXSwapBuffers if drawable has moved between crtc's. This patch also works OK. Patch sent to the list as well: http://lists.x.org/archives/xorg-devel/2010-June/010094.html Thanks for testing. Fix is now in master, i'm closing the bug. |
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.