Hello! I have Lenovo Thinkpad X220 laptop with Sandy Bridge and HD3000. If i915_enable_rc6 set to 0 vsync is just fine(some very minor desync on the very top, one-pixel top row I believe) but if it set to 1 desync is quite huge. i915_enable_rc6=1 http://www.youtube.com/watch?v=jK3L-n5_OX0 i915_enable_rc6=0 http://www.youtube.com/watch?v=mVTPTSHjCqQ This bug is very annoying because you can't watch videos and stay calm. This is with compositing enabled. If you disable it, vsync is not works at all.
Is it with mplayer? What video output (-vo) are you using? Does something changes if you switch between 'xv', 'gl' and 'vaapi'? Video tearing on SNB is the infamous https://bugs.freedesktop.org/show_bug.cgi?id=37686, but I haven't seen any relation between it and rc6 status before.
That videos I uploaded on youtube were played in mplayer, but that happens in every player and just on desktop. I have KDE4 and panel on the right, when you press kde menu button and it slides horizontally, you can see tearing on the top. I checked modelines both for rc6=0 and rc6=1 and it's the same. You can see no tearing with -vo gl and compositing disabled only. It's really strange because kwin also uses gl for compositing. Should I try another DE with compositing to check if it's a kwin bug?
Forget to mention that with -vo gl there is no tearing only on high resolution videos, e.g. with divx 640x480, compositing off, -vo gl and double buffering I can see the tearing and with 1920x1080 h264 with the same settings there is no tearing. Maybe because of different aspects.
Well, I updated mplayer and KDE and now no tearing in video (xv, vaapi) but it still presents on desktop even with kwin compositing turned on using opengl and with vsync enabled.
I also have an x220 and I definitely saw tearing with and without enable_rc6. Sometimes it just takes more time to happen. "teartest.mp4" from comment 46 of bug #37686 is what I use (but I can see tearing everywhere).
Hello again. I'm running kernel 3.3, today's git xf86-video-intel, mesa, intel-dri. I don't know it for sure but it seems like HD3000 breaks vsync if opengl or vaapi surface is not 16:9 (I have Thinkpad X220 with 16:9 1366x768 screen). http://rghost.ru/37220226 - Tearing test 1280x720 http://rghost.ru/37220233 - Tearing test 720x406 http://rghost.ru/37220247 - Tearing test 640x360 1280x720 and 640x360 tearing tests works fine and vsync is done properly, but 720x406 tearing test is tearing on top as you can see in the first message' youtube videos. It's really annoying because KWin does vsync in this way too and you can see tearing on desktop on the top of the screen with rc6=1 and one-top-pixel desync with rc6=0. For example it's impossible to watch sports 720x406 because you get tearing with composite manager either off or on with vsync. The workaround is to do software upscale in player, but that's really not a proper resolution of a problem. If you need any other test data, feel free to ask. I hope it will be resolved till 3.4 kernel version where as far as I know rc6=1 will be by default.
This happens on all i915_enable_rc6 states except =0 with this patch http://cgit.freedesktop.org/~eugeni/kernel/commit/?h=rc6
Ok, since vsync in fundamentally broken on SNB, I can accept that reducing the render clocks can make the issue more apparent but is still just an artifact of the underlying bug. *** This bug has been marked as a duplicate of bug 37686 ***
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.