Bug 20901

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

I can confirm this behavior with i915.
This is important until Bug 20664 is fixed. If textured video works without tearing and has no performance issues there is no need for Overlay.

> --- Comment #2 from unggnu@googlemail.com  2009-05-03 08:03:42 PST ---
> I can confirm this behavior with i915.
> This is important until Bug 20664 is fixed. If textured video works without
> tearing and has no performance issues there is no need for Overlay.

wrong.  i8xx has no textured video.

Right, guess which card support will be dropped next ;)

Any news from the devs on this issue?

Textured video works better than before but it still tears in some parts with an i915.

So what is the status of this issue?

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

I am really interested in the video overlay as I own a 865GM

00:02.0 VGA compatible controller [0300]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02)

That works out of the box with KMS but no textured video so... no Xv...

I've posted my latest work on porting the overlay to kms to intel-gfx@fd.org. I'm really interested in test-reports because I have just a 855GM to develop on. I'll upload my latest patches against kernel and ddx on this bug report, too.

Thx for all reports, Daniel

Created attachment 28587 [details] [review]
patch for ddx

Apply to latest xf86-video-intel git master. To compile you need the
new ioctl definitions from the kernel.

Created attachment 28588 [details] [review]
patch for ddx

this time the actual patch, not just the log ...

Created attachment 28589 [details] [review]
patch for kernel

patch is against latest -linus (I'm using 2.6.31-rc5-gitsomething).

To install the new userspace headers do:

$ make install

Then copy usr/include/drm/i915.h someplace where it can be included by the ddx
(quick&dirty: overwrite the system header in /usr/include/drm)

well... I just tested the patches and after that the video overlay is detected, I can play videos with mplayer using it, but can't put them in fullscreen, I just get a blue screen and mplayer spams this :

X11 error: BadAlloc (insufficient resources for operation)

so there might be a problem somewhere. There is no error nor warnings in the kernel, the Xorg.log or anywhere else than the output of mplayer.

xvinfo has a promising output:

X-Video Extension version 2.2
screen #0
  Adaptor #0: "Intel(R) Video Overlay"
    number of ports: 1
    port base: 72
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
    number of attributes: 5
      "XV_COLORKEY" (range 0 to 16777215)
              client settable attribute
              client gettable attribute (current value is 66046)
      "XV_BRIGHTNESS" (range -128 to 127)
              client settable attribute
              client gettable attribute (current value is -19)
      "XV_CONTRAST" (range 0 to 255)
              client settable attribute
              client gettable attribute (current value is 75)
      "XV_SATURATION" (range 0 to 1023)
              client settable attribute
              client gettable attribute (current value is 146)
      "XV_PIPE" (range -1 to 1)
              client settable attribute
              client gettable attribute (current value is -1)
    maximum XvImage size: 2048 x 2048
    Number of image formats: 5
      id: 0x32595559 (YUY2)
        guid: 59555932-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x32315659 (YV12)
        guid: 59563132-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x30323449 (I420)
        guid: 49343230-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x59565955 (UYVY)
        guid: 55595659-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x434d5658 (XVMC)
        guid: 58564d43-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)

So I think there might be just a little thing missing to make it work, unfortunately I don't know anything about the intel driver to begin the debug. My card :

00:02.0 VGA compatible controller [0300]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company D530 sff(dc578av) [103c:12bc]
        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 16
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at fc400000 (32-bit, non-prefetchable) [size=512K]
        Region 2: I/O ports at 24e0 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [d0] Power Management version 1
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: i915

Created attachment 28615 [details] [review]
patch for kernel

this should fix the fullscreen issue.

On Thu, Aug 13, 2009 at 02:35:30PM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #13 from diego.abelenda@gmail.com  2009-08-13 14:35:29 PST ---
> well... I just tested the patches and after that the video overlay is detected,
> I can play videos with mplayer using it, but can't put them in fullscreen, I
> just get a blue screen and mplayer spams this :
> 
> X11 error: BadAlloc (insufficient resources for operation)
> 
> so there might be a problem somewhere. There is no error nor warnings in the
> kernel, the Xorg.log or anywhere else than the output of mplayer.

Thanks for testing. I've already fixed the fullscreen issue (it's a
over-eager test in the kernel due to a misconception on my side). I must
have sent out a stale version of the patches. I'll redo them.

One important question: Have you noticed any visual corruptions like
flickering (I have them here on my 855GM) on your 865G? That's the last
problem known to me and having a better picture of which chip revs are
affected may help.

Thanks, Daniel

Thanks for your fast work. Now fullscreen works ^^

I had seen pretty bad corruption (1/4 of the screen goes green or displays a part of the video it shouldn't) when I changed the resolution to a lower one, I get a slight one at native resolution (only some lines that appear and disappear, I didn't see it when the full screen wasn't there as it is very small, but now that I can go to fullscreen I can see it).

> --- Comment #16 from diego.abelenda@gmail.com  2009-08-14 02:37:00 PST ---
> Thanks for your fast work. Now fullscreen works ^^

Good, thanks for testing.

> I had seen pretty bad corruption (1/4 of the screen goes green or displays a
> part of the video it shouldn't) when I changed the resolution to a lower one, I
> get a slight one at native resolution (only some lines that appear and
> disappear, I didn't see it when the full screen wasn't there as it is very
> small, but now that I can go to fullscreen I can see it).

At native resolution, when you stop the video, do the corruptions (slowly)
disappear? Some mouse-moving moving around of other windows may help (does
at least here). Just to make sure we're seeing the same type of
corruption.

About the reduced resolution issue: You may be hitting the completely
untested one-line-mode code. Can you post the output of 

$ xrandr

when this happens? Or does the corruption disappear, when you stop the
video (like above)?

-Daniel

The corruption only affects the video nothing else.

Ah, the heavy corruption at lower resolution was probably the same issue as the missing fullscreen, it has disappeared.

Now the only remaining corruption are the lines that appear, and it seems dependent on the resolution of the video, the lesser the resolution it is the greater the number of lines. (I got a few lines with a 720p video and a lot with a 640x480 one), they appear and disappear just like if it were a refresh problem.

my xrandr output :

Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2048 x 2048
VGA1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 410mm x 256mm
   1680x1050      59.9*+
   1280x1024      75.0  
   1360x768       60.0  
   1024x768       75.1     70.1     60.0  
   800x600        72.2     75.0     60.3  
   640x480        72.8     75.0     60.0  
   720x400        70.1  

Daniel, thanks for the patch.

Jesse, could you review and consider commit?

On Mon, Aug 31, 2009 at 08:03:22PM -0700, bugzilla-daemon@freedesktop.org wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=20901
> --- Comment #19 from Gordon Jin <gordon.jin@intel.com>  2009-08-31 20:03:21 PST ---
> Daniel, thanks for the patch.
> 
> Jesse, could you review and consider commit?
Just fyi, there's an ongoing discussion on dri-devel about the right
kernel-userspace interface of this whole thing.

-Daniel

Any progress?

On Sat, Sep 05, 2009 at 04:03:26AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #21 from Michal Nowak <mnowak@redhat.com>  2009-09-05 04:03:25 PST ---
> Any progress?

Not really. There's still the bandwidth/watermaking bug (besides that, it
works). But I can't fix that because I don't have the docs (and I've
already tried all odd things that popped up while scanning through the ums
driver). So until someone at intel picks this up/reviews it, it's
unfortunately stalled.

-Daniel

Daniel, on your 855 what's the FW_BLC reg when you see the flicker?  The overlay FIFO should be controlled by the display plane C bits in that reg; maybe we have a bad watermark or burst size selected.

On Tue, Sep 08, 2009 at 09:44:33AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #23 from Jesse Barnes <jbarnes@virtuousgeek.org>  2009-09-08 09:44:31 PST ---
> Daniel, on your 855 what's the FW_BLC reg when you see the flicker?  The
> overlay FIFO should be controlled by the display plane C bits in that reg;
> maybe we have a bad watermark or burst size selected.

I've already mucked around with FW_BLC and DSPARB values (there are some
small differences to the userspace driver), but turned up nothing. Anyway,
here are the values:

[  181.323475] DSPARB: 15455
[  181.323481] watermarks: FW_BLC: 1070128, FW_BLC2: 102

This is on latest git with drm-next (including latest intel stuff) merged
in. Unfortunately the flickering is still there. Below patch created this
output (the i915_regs stuff in drm-next hung my machine so I couldn't use
it).

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 444cf8c..7f594a1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2107,6 +2107,8 @@ static int intel_get_fifo_size(struct drm_device *dev, int plane)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	uint32_t dsparb = I915_READ(DSPARB);
 	int size;
+	
+	printk("DSPARB: %x\n", dsparb);
 
 	if (IS_I9XX(dev)) {
 		if (plane == 0)
@@ -2229,6 +2231,8 @@ static void i9xx_update_wm(struct drm_device *dev, int planea_clock,
 
 	I915_WRITE(FW_BLC, fwater_lo);
 	I915_WRITE(FW_BLC2, fwater_hi);
+
+	printk("watermarks: FW_BLC: %x, FW_BLC2: %x\n", I915_READ(FW_BLC), I915_READ(FW_BLC2));
 }
 
 static void i830_update_wm(struct drm_device *dev, int planea_clock,

Well, BLC2 does seem to have a low burst length:

42:40: display plane c burst length
  000 - 4
  001 - 8
  010 - 12
  011 - 16
  100 - 20
  101 - 24
  110 - 28
  111 - 32

36:32: display plane c watermark (fetches start when this many or more entries are available in the FIFO), in 32 byte units
  00000 = 32 bytes

The default is 0x307 for this reg...  If increasing the burst length doesn't help, maybe it's not a FIFO issue?
  

On Tue, Sep 08, 2009 at 06:21:14PM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #25 from Jesse Barnes <jbarnes@virtuousgeek.org>  2009-09-08 18:21:11 PST ---
> Well, BLC2 does seem to have a low burst length:
> 
> 42:40: display plane c burst length
>   000 - 4
>   001 - 8
>   010 - 12
>   011 - 16
>   100 - 20
>   101 - 24
>   110 - 28
>   111 - 32
> 
> 36:32: display plane c watermark (fetches start when this many or more entries
> are available in the FIFO), in 32 byte units
>   00000 = 32 bytes
> 
> The default is 0x307 for this reg...  If increasing the burst length doesn't
> help, maybe it's not a FIFO issue?

I've tried 0x302 and 0x702 as values for FW_BLC2, but nothing really
changed. Previously I've copied the ums driver behaviour of not setting
anything (i.3. default value = 0x307), but that didn't help, either.

Still, the visual corruptions are nicely aligned, so it looks like the
some cacheline loads are too late. To other very puzzling thing is that
corruptions disappaer after a few secs, as long as no overlay flip is
being issued in the mean time. And the disappear in a very peculiar way,
namely cacheline by cacheline, i.e. I haven't ever seen new corruptions
pop up. Furthermore, when the image is clear, it stays that way (as long
as it does not get redrawn), i.e. even with cpu/gpu load there are no
further corruptions.

Thanks, Daniel

On Wed,  9 Sep 2009 06:02:34 -0700 (PDT)
bugzilla-daemon@freedesktop.org wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=20901
> 
> 
> 
> 
> 
> --- Comment #26 from Daniel Vetter <daniel@ffwll.ch>  2009-09-09
> 06:02:33 PST --- On Tue, Sep 08, 2009 at 06:21:14PM -0700,
> bugzilla-daemon@freedesktop.org wrote:
> > --- Comment #25 from Jesse Barnes <jbarnes@virtuousgeek.org>
> > 2009-09-08 18:21:11 PST --- Well, BLC2 does seem to have a low
> > burst length:
> > 
> > 42:40: display plane c burst length
> >   000 - 4
> >   001 - 8
> >   010 - 12
> >   011 - 16
> >   100 - 20
> >   101 - 24
> >   110 - 28
> >   111 - 32
> > 
> > 36:32: display plane c watermark (fetches start when this many or
> > more entries are available in the FIFO), in 32 byte units
> >   00000 = 32 bytes
> > 
> > The default is 0x307 for this reg...  If increasing the burst
> > length doesn't help, maybe it's not a FIFO issue?
> 
> I've tried 0x302 and 0x702 as values for FW_BLC2, but nothing really
> changed. Previously I've copied the ums driver behaviour of not
> setting anything (i.3. default value = 0x307), but that didn't help,
> either.
> 
> Still, the visual corruptions are nicely aligned, so it looks like the
> some cacheline loads are too late. To other very puzzling thing is
> that corruptions disappaer after a few secs, as long as no overlay
> flip is being issued in the mean time. And the disappear in a very
> peculiar way, namely cacheline by cacheline, i.e. I haven't ever seen
> new corruptions pop up. Furthermore, when the image is clear, it
> stays that way (as long as it does not get redrawn), i.e. even with
> cpu/gpu load there are no further corruptions.

Ah ok, that sounds like it may cache flush related then.  I remember
seeing something similar in the early KMS work.  I was mapping the
framebuffer through the GTT, but I hadn't done a GTT domain transition
on it yet, so over time I had lots of cacheline sized writes to the
screen until things had finally flushed out of the CPU.  Maybe you're
missing a similar domain transition in your code?

On Wed, Sep 09, 2009 at 09:41:55AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Ah ok, that sounds like it may cache flush related then.  I remember
> seeing something similar in the early KMS work.  I was mapping the
> framebuffer through the GTT, but I hadn't done a GTT domain transition
> on it yet, so over time I had lots of cacheline sized writes to the
> screen until things had finally flushed out of the CPU.  Maybe you're
> missing a similar domain transition in your code?

Thanks alot for the hint, Jesse. I indeed forgot a set_gtt_domain call.
Everything seems to work now. I'll update the patch (I'd like to decouple
the gpu and cpu, atm the running in lockstep for testing purposes) and
resen for testing. Do you think the kernel side of this series could still
be merged into .32?

Thanks, Daniel

(In reply to comment #28)
> Thanks alot for the hint, Jesse. I indeed forgot a set_gtt_domain call.
> Everything seems to work now. I'll update the patch (I'd like to decouple
> the gpu and cpu, atm the running in lockstep for testing purposes) and
> resen for testing. Do you think the kernel side of this series could still
> be merged into .32?

Great!  Yeah, I'm hoping this can land in .32.  I'll review the next set you post. 

Created attachment 29397 [details] [review]
patch for kernel

This is the latest version with the cache-flushing fixed. Recompiling the userspace part is not necessary. Please test, thanks.

Jesse, I'll repost the split-up patch series tomorrow.

-Daniel

I just patched the 2.6.31 release with the new kernel patch, it works great, the video corruption is nearly entirely gone, now I have only a "hole" in the video from time to time : 1/6 of the lines are black instead of displaying the video during 1-2 frames, but it's far better than before thank you.

On Fri, Sep 11, 2009 at 03:07:40AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #31 from diego.abelenda@gmail.com  2009-09-11 03:07:38 PST ---
> I just patched the 2.6.31 release with the new kernel patch, it works great,
> the video corruption is nearly entirely gone, now I have only a "hole" in the
> video from time to time : 1/6 of the lines are black instead of displaying the
> video during 1-2 frames, but it's far better than before thank you.

Are you using a compositing window manager? If so, can you please test
wheter it works when turning compositin off (perhaps just run a failsafe
session)? I'm experiencing similar issues when using compositioning as you
described.

-Daniel

I don't use composition. 

On Fri, Sep 11, 2009 at 04:20:40AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #33 from diego.abelenda@gmail.com  2009-09-11 04:20:38 PST ---
> I don't use composition. 
Ok. Next idea: What video player are you using? Can you test a different
one? xvtest is nice for _very_ basic xv testing (<space> switches colors,
v draws a gradient).

git clone git://anongit.freedesktop.org/~keithp/xvtest

I've got an idea what might be causing this. But some more testing first
would be nice.

-Daniel

Oh interesting, as soon as I move its window I cannot switch vt anymore : chvt would just stay there and do nothing, I had to kill it to regain access to the shell, same for xrandr, it became impossible to terminate X in a normal way, even SIGTERM failed, I had to send SIGKILL to it, but all remained the same way so I had to reboot.

I played a little with the default size of the window overlay in xvtest (the #define DEFAULT_WIDTH and DEFAULT_HEIGHT), putting some values beside the default 256x256 (which seems to work no problem).

I discovered that the program causes the screen to be corrupted at many (nearly all ?) other sizes, and I even made it segfault by putting 1600x900 and this segfault made KMS quite angry again, but this time It refused to display anything, black screen nothing else. The same happens if I press "v", the first time it displays a nice color gradient the second time black screen.

No error message in the kernel or X logs.


btw I use mplayer version 1.0_rc2_p20090731-r1 and nothing like that happens.

> --- Comment #35 from diego.abelenda@gmail.com  2009-09-12 07:02:48 PST ---
Thanks for testing. I'm sorry for this tedious back-and-forth
trial-and-error testing. I've rebased my work onto drm-intel-next and I'm
now exprience similar problems as you described below. I'm working on a
fix, but it needs some more testing.

I've also got an idea on how to fix can't-kill-X-anymore issue (at least
for the common case), but that needs some more time.

> Oh interesting, as soon as I move its window I cannot switch vt anymore : chvt
> would just stay there and do nothing, I had to kill it to regain access to the
> shell, same for xrandr, it became impossible to terminate X in a normal way,
> even SIGTERM failed, I had to send SIGKILL to it, but all remained the same way
> so I had to reboot.
> 
> I played a little with the default size of the window overlay in xvtest (the
> #define DEFAULT_WIDTH and DEFAULT_HEIGHT), putting some values beside the
> default 256x256 (which seems to work no problem).
> 
> I discovered that the program causes the screen to be corrupted at many (nearly
> all ?) other sizes, and I even made it segfault by putting 1600x900 and this
> segfault made KMS quite angry again, but this time It refused to display
> anything, black screen nothing else. The same happens if I press "v", the first
> time it displays a nice color gradient the second time black screen.
> 
> No error message in the kernel or X logs.
> 
> 
> btw I use mplayer version 1.0_rc2_p20090731-r1 and nothing like that happens.

But the occasional black stripe is still there?

-Daniel

Created attachment 29518 [details] [review]
patch for ddx

As promised the new kernel patch with the wc-cache flushing fix. This survived one hour of scripted stress-testing on my box. Neither the ums xorg driver nor any of my previous patches managed to do this, so it looks quite solid.

To test apply this on top of the drm-intel-next branch of

git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

This tree contains another cache flushing fix for i8xx hw by Eric.

Thx, Daniel

Eric will be pulling this in shortly...

(In reply to comment #38)
> Eric will be pulling this in shortly...

Cool! Thanks everyone involved.

Should XVideo be supported on:

- KMS enabled
- 0:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
- mesa 7.7_rc3
- intel driver 2.9.1
- libdrm 2.4.17
- Linux xxxxxx 2.6.32-gentoo #3 SMP Mon Dec 21 23:20:01 CET 2009 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux


since it my case it does not work:
# xvinfo
X-Video Extension version 2.2
screen #0
 no adaptors present


if KMS is disabled XVideo works

Should I open a new bug report?

> --- Comment #40 from Octavian Petre <octavsly@tiscali.nl>  2009-12-23 01:12:20 PST ---
> Should XVideo be supported on:
> 
> - Linux xxxxxx 2.6.32-gentoo #3 SMP Mon Dec 21 23:20:01 CET 2009 i686 Intel(R)
> Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux

the i915 overlay code will be included in linux 2.6.33.

On Wed, Dec 23, 2009 at 06:16:25AM -0800, bugzilla-daemon@freedesktop.org wrote:
> the i915 overlay code will be included in linux 2.6.33.

Furthermore you need a more recent xf86-video-intel, support will be
included by default in the upcoming 2.9.10 release.