Bug 22895

Summary: [GM965] [REGRESSION] Videos appear very blocky and jagged in driver 2.6
Product: xorg Reporter: Rohan Dhruva <rohandhruva>
Component: Driver/intelAssignee: haihao <haihao.xiang>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bofphile, haihao.xiang
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Screenshot on driver version 2.4
none
Screenshot on driver version 2.6 (notice jaggedness in t-shirt)
none
xorg.conf, essentially empty
none
Output of dmesg
none
Xorg.0.log of driver version 2.4
none
Screenshot on driver version 2.8
none
Xorg.0.log of driver version 2.8
none
Output of dmesg after driver 2.8
none
xorg.conf, after modifications for driver 2.8
none
Screenshot on driver version 2.8 xv overlay adaptor
none
Screenshot after reverting commit (distorted colours and display) none

Description Rohan Dhruva 2009-07-22 11:49:33 UTC
I have a Dell Vostro 1510 laptop with Intel GMA X3100. I am using Ubuntu 9.04 distribution. I noticed that videos appeared very jagged and blocky in all video players - VLC, Totem, mplayer etc. 

However, after I followed the instructions here - https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4 - and reverted the driver to 2.4, videos appear smooth as expected.

-- chipset: 965GM
-- system architecture: x86_64
-- xf86-video-intel/xserver/mesa/libdrm version: 
xserver-xorg-video-intel affected version: 2.6.3
xserver-xorg-video-intel proper version version: 2.4.1
xserver-xorg: 7.4
part of glxinfo output:
OpenGL renderer string: Mesa DRI Intel(R) 965GM 20090326 2009Q1 RC2
OpenGL version string: 2.0 Mesa 7.4
libdrm version: 2.4.5

-- kernel version: 2.6.28-13-generic
-- Linux distribution: Ubuntu 9.04
-- Machine or mobo model: Dell Vostro 1510 laptop

$ lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)

I am attaching pictures which highlight the difference. Please tell me if any more information is to be provided. Thanks.
Comment 1 Rohan Dhruva 2009-07-22 11:50:48 UTC
Created attachment 27919 [details]
Screenshot on driver version 2.4
Comment 2 Rohan Dhruva 2009-07-22 11:51:44 UTC
Created attachment 27920 [details]
Screenshot on driver version 2.6 (notice jaggedness in t-shirt)
Comment 3 Rohan Dhruva 2009-07-22 11:53:52 UTC
Created attachment 27921 [details]
xorg.conf, essentially empty
Comment 4 Rohan Dhruva 2009-07-22 11:54:21 UTC
Created attachment 27922 [details]
Output of dmesg
Comment 5 Rohan Dhruva 2009-07-22 11:56:08 UTC
Created attachment 27923 [details]
Xorg.0.log of driver version 2.4
Comment 6 Gordon Jin 2009-07-22 20:16:35 UTC
If it's the tearing issue, it has been fixed in 2.8.0.
Comment 7 Rohan Dhruva 2009-07-23 06:30:09 UTC
How do I verify that I am being affected by the same bug? Do I need to download a compile a newer version of the driver to verify, or is there some other method?
Comment 8 haihao 2009-07-23 18:08:12 UTC
Try the latest driver, thanks.
Comment 9 Rohan Dhruva 2009-07-24 13:18:52 UTC
I compiled the 2.8.0 version of the driver. Still no change - the jaggedness persists. I am attaching relevant files and screenshot. Thanks.
Comment 10 Rohan Dhruva 2009-07-24 13:19:53 UTC
Created attachment 27983 [details]
Screenshot on driver version 2.8
Comment 11 Rohan Dhruva 2009-07-24 13:20:16 UTC
Created attachment 27984 [details]
Xorg.0.log of driver version 2.8
Comment 12 Rohan Dhruva 2009-07-24 13:20:47 UTC
Created attachment 27985 [details]
Output of dmesg after driver 2.8
Comment 13 Rohan Dhruva 2009-07-24 13:21:14 UTC
Created attachment 27986 [details]
xorg.conf, after modifications for driver 2.8
Comment 14 Rohan Dhruva 2009-07-24 13:23:10 UTC
Please note that it's a bit messy as I had to upgrade libdrm to version .12,
which was installed in /usr and /. Consequently, I had to add /lib/xorg/modules
to the ModulePath of X11 to load the 2.8.0 version of the driver. Please tell
me if any more debugging is to be done.
Comment 15 haihao 2009-07-26 20:50:06 UTC
Which video output is used, xv or others? 
If using xv, which xv adaptor is used, overlay or textured?


Comment 16 Rohan Dhruva 2009-07-27 12:32:45 UTC
I am using xv output. If I use the adaptor 0 i.e. Textured, the video is jagged as usual. If, however, I use the adaptor 1 i.e. Overlay, there are no jagged edges and it looks perfect. 

I used mplayer -vo xv:adaptor=0 and 1 to switch between adaptors. I am attaching a screenshot of overlay adaptor for comparison. 
Comment 17 Rohan Dhruva 2009-07-27 12:34:59 UTC
Created attachment 28044 [details]
Screenshot on driver version 2.8 xv overlay adaptor
Comment 18 haihao 2009-07-27 19:15:43 UTC
> Created an attachment (id=28044) [details]
> Screenshot on driver version 2.8 xv overlay adaptor
The dimension of this image is different from others. It is jagged if enlarging the size of this image. 
BTW, do you also use xv output and textured adaptor when using driver 2.4? I wonder if it is a regression of textured video.
Comment 19 Rohan Dhruva 2009-07-28 07:05:34 UTC
The screenshot is of different dimension because I took the screenshot from within mplayer. The display with overlay adaptor is definitely not jagged even in fullscreen (in mplayer) in driver 2.8.

In driver version 2.4.1, both overlay and textured xv adaptors are properly displaying, not jagged.

Comment 20 haihao 2009-07-29 18:14:27 UTC
I tested some videos on 965GM and I didn't see any difference between 2.4.1 and 2.8.0.   If possible, could you do a git bisect?
Comment 21 Rohan Dhruva 2009-07-30 07:23:53 UTC
I am not familiar with that process. Can you please link me to some guide, or explain the procedure in short? Thanks.
Comment 22 haihao 2009-07-30 23:08:01 UTC
read manual for detail.

for example
git bisect start                            ------- start bisection
git bisect good xf86-video-intel-2.4.1      ------- mark 2.4.1 as a good revision
git bisect bad  2.8.0                       ------- mark 2.8.0 as a bad revision

It will bisect the tree and say something. Now compile the driver and test it.

git bisect good  --------- if it is good 

or 

git bisect bad   --------- if it is bad 

to ask for next bisection.


Comment 23 Rohan Dhruva 2009-07-31 13:03:54 UTC
I went through the complete process. I started out exactly as you told. After a certain point, all subsequent compiles were "bad". I had to compile around 8-10 times in all. However, the final result does not really look promising to me. This is the output of "git bisect bad" after 0 revisions were left to be tested --

$ git bisect bad
e4cd9de2933ada3e2a4b43552729ae3a370128bf is first bad commit
commit e4cd9de2933ada3e2a4b43552729ae3a370128bf
Author: Carl Worth <cworth@cworth.org>
Date:   Wed Apr 15 16:14:03 2009 -0700

    Add a NEWS files with release-notes for 2.7.0
    
    It will be nice to have release-notes under revision control, as well
    being able to document issues in an obviously time-sensitive file,
    (as opposed to README where we were documenting some of this previously).

:000000 100644 0000000000000000000000000000000000000000 c059c98adae38cc87d256139c633396aead71982 A	NEWS

Please tell me if I am making a mistake somewhere, or if the above is indeed useful.
Comment 24 Rohan Dhruva 2009-07-31 13:24:10 UTC
I must have done something wrong the first time. After running through the whole bisect process a second time, I got something else as the "bad commit":

$ git bisect bad
830bf916724afd21b7947f797c22a8c8aab7a0a4 is first bad commit
commit 830bf916724afd21b7947f797c22a8c8aab7a0a4
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Dec 29 13:42:44 2008 -0800

    Don't touch the pipestat regs for detecting FIFO underrun. The kernel owns them.
    
    Since we don't perform any synchronization with the kernel on these regs, we
    could race with the kernel to write stale values and end up not having vblank
    interrupts enabled when somebody was waiting on one.

:040000 040000 b5560984df61226ed3f9abdba87400b1b32d74a5 87e1216abe0563a17aa6f4e6700a73820f5cd20c M	src
Comment 25 haihao 2009-08-02 19:17:58 UTC
Thanks for your help.

Could you double check if XV is jagged with 830bf916724afd21b7947f797c22a8c8aab7a0a4, however it isn't jagged without this commit?
Comment 26 Rohan Dhruva 2009-08-02 19:51:00 UTC
I already did that, right, during the bisect procedure? Or are you asking me to compile the "latest" version but without this commit?

In that case, can you please guide me how to do that? I am a git-n00b. Also how do I update my git tree to reflect the latest changes.. something like a svn up? Thanks.
Comment 27 haihao 2009-08-02 23:18:48 UTC
(In reply to comment #26)
> I already did that, right, during the bisect procedure? Or are you asking me to
> compile the "latest" version but without this commit?
The later. I was surprised that this commit causes the regression, so I want to make sure this commit is the real 'bad' commit.

> In that case, can you please guide me how to do that? 
You can use git revert to revert this commit after 0 revision is left, then compile and test.

> do I update my git tree to reflect the latest changes.. something like a svn
> up? Thanks.
git pull


Comment 28 Rohan Dhruva 2009-08-03 11:15:16 UTC
After reverting that commit, I notice something strange. My video is totally corrupted and out of colour (please refer to the attached screenshot).

However, this happens only the first time X starts. If I later restart X, then the video displays properly without any weird colours, or jagged edges. 

I am still unable to pinpoint whether this commit is the cause of the error. That is because, once I was able to revert the commit cleanly. However, the other time, it informed me there was some conflict while trying to revert. I am a bit confused.
Comment 29 Rohan Dhruva 2009-08-03 11:18:33 UTC
Created attachment 28315 [details]
Screenshot after reverting commit (distorted colours and display)
Comment 30 haihao 2009-08-04 22:42:16 UTC
(In reply to comment #28)
> I am still unable to pinpoint whether this commit is the cause of the error.
> That is because, once I was able to revert the commit cleanly. However, the
> other time, it informed me there was some conflict while trying to revert. I am
> a bit confused.
> 
You can use git branch with this commit to create a new branch then use git checkout to switch to the new branch, then test the new branch.  After that, revert this commit from the new branch then test again. 
Comment 31 Rohan Dhruva 2009-08-05 06:18:04 UTC
I am now beginning to think that my testing method is bad. This is what I currently do after each git bisect good/bad -- 

export PKG_CONFIG_PATH=/lib/pkgconfig/:$PKG_CONFIG_PATH
./autogen.sh --prefix=/usr --exec-prefix=/
make
sudo make install

-- and then restart the X server. Is that enough to "reset" the graphics hardware? I am asking because I get different results each time I restart X, with same driver. Do I need to reboot my PC after each install of the driver?

For example, I asked someone in irc #git to help me out with your instructions in comment #30, and this is what I was told to do -- http://git.pastebin.com/m173e2e41

At line no 8 where it says "test - must be bad", I first got the weird green bars which I previously pasted in attachment 28315 [details]. After restarting X server, the green bars disappeared, but the jagged edges were there. After restarting yet one more time, the video is perfect, no jagged edges.

I am bit lost here so as how to proceed. The version 2.4.1 is perfectly fine always reproducible, the version 2.8.0 has the bug always reproducible, I just can't pinpoint the commit in between.
Comment 32 Rohan Dhruva 2009-08-05 07:39:03 UTC
I tried the complete bisect procedure once again. This time I restarted X twice after every commit. Somewhere down the line my X got completely hosed, gdm refused to start. I had to boot from a livecd and recover. This is what I got from git-bisect though:

$ git bisect bad
1f61e97904dfe5f8c08bb9f284cfdfe878f7e541 is first bad commit
commit 1f61e97904dfe5f8c08bb9f284cfdfe878f7e541
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Wed Dec 31 22:56:57 2008 +0800

    UXA: Fallback to dri_bo_map() if pin failed
    
    This fixes VT switch issue with UXA after Eric's
    aae4008096399a0e84abc7c016b35092caf9db25 on 2D side.

:040000 040000 87e1216abe0563a17aa6f4e6700a73820f5cd20c 7b5a43c1ce983877644b157e767af279a3b3bc53 Music/src

I am really at a loss as to what I am doing wrong here. Please give me a method of "properly" testing between bisects. Thanks!
Comment 33 Eric Anholt 2009-08-05 15:12:30 UTC
commit 79b6851148574419389ac8055b0c31b8bdac3ab3
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Aug 5 12:45:16 2009 -0700

    Fix sampler indexes on i965 planar video.
    
    We only set up one sampler, because all of our sampling is the same.  By
    using a non-zero index for the other two samplers, we'd dereference (likely)
    zeroed data, resulting in using NEAREST filtering.  This was a regression in
    40671132cb3732728703c6444f4577467fa9223f which incidentally switched from
    having 6 samplers to 1.
    
    Bug #22895, #19856
Comment 34 haihao 2009-08-05 18:21:25 UTC
*** Bug 21522 has been marked as a duplicate of this bug. ***
Comment 35 Rohan Dhruva 2009-08-06 07:57:53 UTC
After pulling in the latest head and reinstalling, I can confirm that the issue is solved for me. The videos display perfectly now. Thank you so much for all your help.

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.