Bug 89807 - [Broadwell] xv "Textured Video" adds green and purple noise blocks
Summary: [Broadwell] xv "Textured Video" adds green and purple noise blocks
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-29 03:22 UTC by Josh Triplett
Modified: 2015-04-16 20:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Noisy screenshot from mplayer -vo xv (162.15 KB, image/png)
2015-03-29 03:22 UTC, Josh Triplett
no flags Details
Non-noisy screenshot from mplayer -vo gl (147.11 KB, image/png)
2015-03-29 03:23 UTC, Josh Triplett
no flags Details
Non-noisy mplayer internal screenshot via alt-s (163.38 KB, image/png)
2015-03-29 03:24 UTC, Josh Triplett
no flags Details
Xorg.0.log (21.71 KB, text/plain)
2015-03-29 03:24 UTC, Josh Triplett
no flags Details
glxinfo (18.83 KB, text/plain)
2015-03-29 03:25 UTC, Josh Triplett
no flags Details
xvinfo (2.31 KB, text/plain)
2015-03-29 03:25 UTC, Josh Triplett
no flags Details
[PATCH] gen8: Fix the YUV->RGB shader (2.18 KB, patch)
2015-03-30 13:54 UTC, Ville Syrjala
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Triplett 2015-03-29 03:22:49 UTC
Created attachment 114694 [details]
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
Comment 1 Josh Triplett 2015-03-29 03:23:24 UTC
Created attachment 114695 [details]
Non-noisy screenshot from mplayer -vo gl
Comment 2 Josh Triplett 2015-03-29 03:24:30 UTC
Created attachment 114696 [details]
Non-noisy mplayer internal screenshot via alt-s
Comment 3 Josh Triplett 2015-03-29 03:24:55 UTC
Created attachment 114697 [details]
Xorg.0.log
Comment 4 Josh Triplett 2015-03-29 03:25:13 UTC
Created attachment 114698 [details]
glxinfo
Comment 5 Josh Triplett 2015-03-29 03:25:24 UTC
Created attachment 114699 [details]
xvinfo
Comment 6 Chris Wilson 2015-03-29 07:52:03 UTC
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?
Comment 7 Josh Triplett 2015-03-29 09:43:03 UTC
(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.)
Comment 8 Josh Triplett 2015-03-29 09:53:13 UTC
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.
Comment 9 Ville Syrjala 2015-03-30 06:45:57 UTC
(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.
Comment 10 Josh Triplett 2015-03-30 07:26:40 UTC
(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.
Comment 11 Ville Syrjala 2015-03-30 13:54:57 UTC
Created attachment 114728 [details] [review]
[PATCH] gen8: Fix the YUV->RGB shader

This patch seems to fix the problems on my BSW at least. Please test.
Comment 12 Chris Wilson 2015-04-16 20:07:01 UTC
commit c43617b739e358064396912c7a7a8028ca91d201
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
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ä <ville.syrjala@linux.intel.com>
    Tested-by: Chris Wilson <chris@chris-wilson.co.uk>


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.