[GM45] Bad chroma upsampling on videos

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.

Created an attachment (id=27919)
Screenshot on driver version 2.4

Created an attachment (id=27920)
Screenshot on driver version 2.6 (notice jaggedness in t-shirt)

Created an attachment (id=27921)
xorg.conf, essentially empty

Created an attachment (id=27922)
Output of dmesg

Created an attachment (id=27923)
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 an attachment (id=27983)
Screenshot on driver version 2.8

Created an attachment (id=27984)
Xorg.0.log of driver version 2.8

Created an attachment (id=27985)
Output of dmesg after driver 2.8

Created an attachment (id=27986)
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 an attachment (id=28044)
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 <email address hidden>
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 <email address hidden>
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 an attachment (id=28315)
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. 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 <email address hidden>
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 <email address hidden>
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.