Bug 22895

Created attachment 27919 [details]
Screenshot on driver version 2.4

Created attachment 27920 [details]
Screenshot on driver version 2.6 (notice jaggedness in t-shirt)

Created attachment 27921 [details]
xorg.conf, essentially empty

Created attachment 27922 [details]
Output of dmesg

Created attachment 27923 [details]
Xorg.0.log of driver version 2.4

If it's the tearing issue, it has been fixed in 2.8.0.

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?

Try the latest driver, thanks.

I compiled the 2.8.0 version of the driver. Still no change - the jaggedness persists. I am attaching relevant files and screenshot. Thanks.

Created attachment 27983 [details]
Screenshot on driver version 2.8

Created attachment 27984 [details]
Xorg.0.log of driver version 2.8

Created attachment 27985 [details]
Output of dmesg after driver 2.8

Created attachment 27986 [details]
xorg.conf, after modifications for driver 2.8

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.

Which video output is used, xv or others? 
If using xv, which xv adaptor is used, overlay or textured?

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. 

Created attachment 28044 [details]
Screenshot on driver version 2.8 xv overlay adaptor

> 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.

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.

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?

I am not familiar with that process. Can you please link me to some guide, or explain the procedure in short? Thanks.

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.

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.

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

Thanks for your help.

Could you double check if XV is jagged with 830bf916724afd21b7947f797c22a8c8aab7a0a4, however it isn't jagged without this commit?

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.

(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

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.

Created attachment 28315 [details]
Screenshot after reverting commit (distorted colours and display)

(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. 

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.

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!

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

*** Bug 21522 has been marked as a duplicate of this bug. ***

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.