Created attachment 39070 [details] [review]
Disable XVideo on SandyBridge by default

We will be using this patch until XVideo is working fine on SandyBridge.
It re-adds the XVideo option (why had it been removed in the first place?) and defaults to Enable on all platforms but SandyBridge.

Please consider this for the next release :-)

In the short-term there is nothing we can do but to disable XVideo on Sandybridge -- the shaders have not yet been written. :(

commit 8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Oct 1 21:40:36 2010 +0100

    video: Disable TextureAdaptor for Sandybridge
    
    The acceleration code does not yet exist, so we try to use gen4 shaders
    which hangs the chip and makes everybody upset. Disable it until such a
    time as support is written for Sandybridge XVideo.
    
    Reported-by: Matthias Hopf <mhopf@suse.de>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30500
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

(In reply to comment #2)
> In the short-term there is nothing we can do but to disable XVideo on
> Sandybridge -- the shaders have not yet been written. :(
> 
> commit 8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Oct 1 21:40:36 2010 +0100
> 
>     video: Disable TextureAdaptor for Sandybridge
> 
>     The acceleration code does not yet exist, so we try to use gen4 shaders
>     which hangs the chip and makes everybody upset. Disable it until such a
>     time as support is written for Sandybridge XVideo.
> 
>     Reported-by: Matthias Hopf <mhopf@suse.de>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30500
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I don't think this commit is actually working? gstreamer still tries to use Xv and is hanging. The patch attached to this bug works.


X-Video Extension version 2.2
screen #0
  Adaptor #0: "Intel(R) Textured Video"
    number of ports: 16
    port base: 81
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
    number of attributes: 3
      "XV_BRIGHTNESS" (range -128 to 127)
              client settable attribute
              client gettable attribute (current value is 0)
      "XV_CONTRAST" (range 0 to 255)
              client settable attribute
              client gettable attribute (current value is 0)
      "XV_SYNC_TO_VBLANK" (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)

Created attachment 39160 [details]
Xorg.0.log

Xorg.0.log from an xf86-video-intel git checkout from 455f2939a661764 on a sandybridge-m GT2 device.

After the sandybridge shadow changes it is working.

[    75.441] (WW) intel(0): Disabling Xv because no adaptors could be initialized.

(In reply to comment #5)
> After the sandybridge shadow changes it is working.
> 
> [    75.441] (WW) intel(0): Disabling Xv because no adaptors could be
> initialized.

--- a/src/intel_video.c
+++ b/src/intel_video.c
@@ -363,7 +363,7 @@ void I830InitVideo(ScreenPtr screen)
         * supported hardware.
         */
        if (scrn->bitsPerPixel >= 16 &&
-           (IS_I9XX(intel) || IS_I965G(intel)) &&
+           (IS_I9XX(intel) || (IS_I965G(intel) && !IS_GEN6(intel))) &&
            !intel->use_shadow) {
                texturedAdaptor = I830SetupImageVideoTextured(screen);
                if (texturedAdaptor != NULL) {

The reason is that && has a higher precedence than || in C. I guess we want
to fix commit 8784c4f5a1524fb979b00c7ce7981cbc1dcf0ec0 instead. ;-)

Using [SNB] as the tag for bugs specific to Sandybridge hardware.

I didn't read the code carefully. The issue is not the operator precedence, but
the problem is that IS_965G(...) is already part of IS_9XX(...). I'm going to attach a fix.

Created attachment 39201 [details] [review]
xf86-video-intel-fix-8784c4f.diff

fix for commit #8784c4f

"Fixed" for good, I hope!

commit 4083197a44d1a1a05d33654b3c7d6e96d7472fe7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Oct 7 12:45:02 2010 +0100

    Include a chipset generation number to clarify device specific paths.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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