yuv to rgb translation is faulty for Intel Generation 8 Graphics

Bug #1449892 reported by Uwe Koziolek on 2015-04-29
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
xserver-xorg-video-intel (Debian)
Fix Released
Unknown
xserver-xorg-video-intel (Ubuntu)
Medium
Unassigned
Vivid
Medium
Unassigned

Bug Description

[Impact]
running mplayer or vlc the video output is incorrect. There are are 2 line steps on edges.
The problems is known and there is already an upstream fix available.
http://www.spinics.net/lists/intel-gfx/msg65030.html

I have rebuild the driver with git from 2015-04-28, and the video output is correct now.

The bugfix is for Generation 8 Intel graphics like Intel NUC with Core I5-5250 and HD6000 grahics in my case.
The used version is Ubuntu vivid amd64.

[Test Case]
Launch Skype, VLC or mplayer and use xv as video output.
A sample of the corruption can be found here:
https://a.disquscdn.com/uploads/mediaembed/images/1942/867/original.jpg

[Regression Potential]
None. Admittedly I may not be the right one to fully assess the risk.
Any help on this matter would be much appreciated.

[Other Info]
Already fixed upstream.

Created attachment 114694
Noisy screenshot from mplayer -vo xv

On a Broadwell system (X1 Carbon 3rd generation), playing video through the default xv adaptor "Intel(R) Textured Video" adds piles of green and purple noise to the image. I can reliably reproduce this by playing back any video using "mplayer -vo xv". This noise doesn't appear when using some other video output (such as -vo gl) or when using xv adaptor #1: "Intel(R) Video Sprite" (though that has other issues).

I'll attach three screenshots of the same video frame: one from mplayer -vo xv (showing the noise), one from mplayer -vo gl (not showing the noise), and one dumped via mplayer's internal screenshot mechanism by hitting alt-s (which turns a frame into a screenshot without sending it to the video output, so it doesn't include the noise).

The noise doesn't dance around; it's consistent for any given frame, and slight changes to the frame seem to produce slight changes to the noise rather than completely different noise.

Driver version: 2.99.917
Xorg server version: 7.7
Mesa version: 10.4.2
Kernel version: 4.0-rc5
Debian sid

Will attach Xorg.0.log, glxinfo output, and xvinfo output.

Graphics card (from lspci -vvv):

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 2227
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 54
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=16M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 3000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee00018 Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: i915

Created attachment 114695
Non-noisy screenshot from mplayer -vo gl

Created attachment 114696
Non-noisy mplayer internal screenshot via alt-s

Created attachment 114697
Xorg.0.log

Created attachment 114698
glxinfo

Created attachment 114699
xvinfo

Any particular sample video i.e. is it dependent upon planar or packed formats? Could you quickly jump around a couple of kernel and ddx versions just in case it is a regression? (I haven't touched the video paths for a while, but there might be some collateral damage.)

Are the sprite problems just the usual issues of using an overlay? Or are they worth filing bug reports for?

(In reply to Chris Wilson from comment #6)
> Any particular sample video i.e. is it dependent upon planar or packed
> formats?

Happens with every video I've tried, regardless of format. Any random youtube video downloaded with youtube-dl, for instance.

AFAICT, mplayer is always using xv with planar YV12; it always shows a line like this (modulo resolution):

VO: [xv] 1920x1080 => 1920x1080 Planar YV12 [zoom]

> Could you quickly jump around a couple of kernel and ddx versions
> just in case it is a regression? (I haven't touched the video paths for a
> while, but there might be some collateral damage.)

Kernel yes; I'll test a couple of kernels and report back.

DDX not as easily, since I need a DDX new enough to understand Broadwell, and the version packaged in latest Debian unstable doesn't. I'm currently running 2:2.99.917-1~exp1 from Debian experimental.

> Are the sprite problems just the usual issues of using an overlay? Or are
> they worth filing bug reports for?

Lack of scaling; with -vo xv:adaptor=1, the video only displays at its original size, regardless of the display window size (including fullscreen). Toggling fullscreen leaves the video centered at its original size with the rest of the screen filled with colorkey. (The mplayer -zoom option doesn't seem to make a difference there.)

3.19 (specifically 3.19.1, Debian package 3.19.1-1~exp1) shows the same behavior as 4.0-rc5. With 3.16 (specifically 3.16.7-ckt7, Debian package 3.16.7-ckt7-1), instead of scattered blocky noise that doesn't dance around, I get pixel-level green noise over the whole image that changes every frame.

(In reply to Josh Triplett from comment #7)
> (In reply to Chris Wilson from comment #6)
> > Are the sprite problems just the usual issues of using an overlay? Or are
> > they worth filing bug reports for?
>
> Lack of scaling; with -vo xv:adaptor=1, the video only displays at its
> original size, regardless of the display window size (including fullscreen).
> Toggling fullscreen leaves the video centered at its original size with the
> rest of the screen filled with colorkey. (The mplayer -zoom option doesn't
> seem to make a difference there.)

BDW sprite planes simply do not support scaling, so that's expected.

To get mplayer to use another format you can pass eg. '-vf format=yuy2' to it.

As for the corruption, I'm getting it on my BSW too. With both YV12 and YUY2. So a generic gen8 issue I suppose. For me it seems to depend on the horizontal position of the window. When I see the corruption and I pause mplayer, then move the window sideways a bit, the corruption remains in the image, but then if I hit '.' to have it render another frame the corruption shifts or disappears.

And even when I get the position correct to eliminate the green/purple corruption, the results still look very blocky. Pretty much looks like it's doing linear interpolation exactly the wrong around or something. Not quite sure, but look like the vertical interpolation is the problem, horizontal might be OK.

(In reply to Ville Syrjala from comment #9)
> To get mplayer to use another format you can pass eg. '-vf format=yuy2' to
> it.

yuy2 doesn't seem to work at all here; it gives a colorspace incompatibility error and exits.

> As for the corruption, I'm getting it on my BSW too. With both YV12 and
> YUY2. So a generic gen8 issue I suppose. For me it seems to depend on the
> horizontal position of the window. When I see the corruption and I pause
> mplayer, then move the window sideways a bit, the corruption remains in the
> image, but then if I hit '.' to have it render another frame the corruption
> shifts or disappears.

I don't have that behavior at all; the corruption seems to be entirely position-independent here. Though it's possible that some combination of mplayer2 and compositing is causing the video decoding on my system to always occur at the same offset in an off-screen buffer unless fullscreened.

Created attachment 114728
[PATCH] gen8: Fix the YUV->RGB shader

This patch seems to fix the problems on my BSW at least. Please test.

commit c43617b739e358064396912c7a7a8028ca91d201
Author: Ville Syrjälä <email address hidden>
Date: Thu Apr 16 20:40:39 2015 +0300

    gen8: Fix the YUV->RGB shader

    Use the correct register (Yn_01) with first half of the
    Y samples instead of using the register (Yn_23) with the
    second half twice when computing the green channel.

    Also use the Yn_01 register name instead of Yn for the red
    channel as well, just for a bit of extra consistency.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89807
    Signed-off-by: Ville Syrjälä <email address hidden>
    Tested-by: Chris Wilson <email address hidden>

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Unknown → Fix Released
tags: added: patch
Changed in xserver-xorg-video-intel (Debian):
status: Unknown → Confirmed
Changed in xserver-xorg-video-intel (Ubuntu Vivid):
status: New → In Progress
description: updated
description: updated
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
Changed in xserver-xorg-video-intel (Ubuntu Vivid):
importance: Undecided → Medium

Hello Uwe, or anyone else affected,

Accepted xserver-xorg-video-intel into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.99.917-1~exp1ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in xserver-xorg-video-intel (Ubuntu Vivid):
status: In Progress → Fix Committed
tags: added: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.99.917-1~exp1ubuntu2.2

---------------
xserver-xorg-video-intel (2:2.99.917-1~exp1ubuntu2.2) vivid-proposed; urgency=medium

  * fix-yuv-to-rgb-shared-on-intel-gen8.patch: Fix faulty yuv2rgb translation
    on Intel Generation 8 Graphics. (LP: #1449892)

 -- Alessio Treglia <email address hidden> Fri, 29 May 2015 11:46:27 +0100

Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Fix Released
Alessio Treglia (quadrispro) wrote :

The bug used to affect my Dell XPS 13 9343. It is no longer the case with the package uploaded to vivid-proposed, the video output does look very good now and corruptions are visible. Information on package's installed version follow:

alessio@bizet:~$ dpkg-query -s xserver-xorg-video-intel
Package: xserver-xorg-video-intel
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 3174
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Version: 2:2.99.917-1~exp1ubuntu2.2
Provides: xorg-driver-video
Depends: libc6 (>= 2.17), libdrm-intel1 (>= 2.4.38), libdrm2 (>= 2.4.25), libpciaccess0 (>= 0.8.0+git20071002), libpixman-1-0 (>= 0.30.0), libudev1 (>= 183), libx11-6, libx11-xcb1, libxcb-dri2-0, libxcb-dri3-0, libxcb-sync1, libxcb-util0 (>= 0.3.8), libxcb1, libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxinerama1, libxrandr2 (>= 2:1.2.99.2), libxrender1, libxshmfence1, libxtst6, libxv1, libxvmc1, xorg-video-abi-19, xserver-xorg-core (>= 2:1.16.99.901)
Description: X.Org X server -- Intel i8xx, i9xx display driver
 This package provides the driver for the Intel i8xx and i9xx family
 of chipsets, including i810, i815, i830, i845, i855, i865, i915, i945
 and i965 series chips.
 .
 This package also provides XvMC (XVideo Motion Compensation) drivers
 for i810/i815 and i9xx and newer chipsets.
 .
 This package is built from the X.org xf86-video-intel driver module.
Homepage: http://www.x.org/
Original-Maintainer: Debian X Strike Force <email address hidden>

Alessio Treglia (quadrispro) wrote :

There was a small but important typo in my previous message, please replace "corruptions are visible" with "corruptions are ***no longer*** visible".

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.99.917-1~exp1ubuntu2.2

---------------
xserver-xorg-video-intel (2:2.99.917-1~exp1ubuntu2.2) vivid-proposed; urgency=medium

  * fix-yuv-to-rgb-shared-on-intel-gen8.patch: Fix faulty yuv2rgb translation
    on Intel Generation 8 Graphics. (LP: #1449892)

 -- Alessio Treglia <email address hidden> Fri, 29 May 2015 11:46:27 +0100

Changed in xserver-xorg-video-intel (Ubuntu Vivid):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for xserver-xorg-video-intel has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hello Uwe, or anyone else affected,

Accepted xserver-xorg-video-intel-lts-vivid into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel-lts-vivid/2:2.99.917-1~exp1ubuntu2.2~trusty1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: removed: verification-done
tags: added: verification-needed
Changed in xserver-xorg-video-intel (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.