I haven't been able to reproduce this yet, still trying.

Ok I've reproduced it but only with overlay video, not textured.  Textured seems to work fine (though I'm composited now I'll try w/o).

Even non-composited textured video looks fine, so I'll assume this report is about overlay video.

Oh it seems a little more complicated than that actually... Overlay works in both composited and non-composited mode, and if overlay has been run once already, textured video will work under composite.  But if you go back to non-composited things break...

I think the get_pixmap_offset call in i965_video.c is correct though; it's used by render as well, so if it were broken under EXA I'd expect to see a lot more trouble.  I think there's something else buggy in the video code...

Btw, why is dst_base the buffer virtual address in the textured case and the front buffer virtual address in the overlay case?  It would be good if we could use GTT mapping in both cases...

I've just reported a similar issue: http://bugs.freedesktop.org/show_bug.cgi?id=20994 maybe it's the same.

HTH.

Jesse, I thought this is the known issue you are discussing with Haihao.

Jian's test environment is textured video with non-composite. I think G45 doesn't have overlay.

Yeah, but Haihao didn't give me any details.  He said something about using a different offset and making things work, but then having tiling issues.  With a little more info I'm sure I could fix this one quickly, as it is I'm having to learn the Xv code more than I'd like... :)

Haihao, how about this simple patch?  Works for me...

diff --git a/src/i830_driver.c b/src/i830_driver.c
index 32ca6c9..2134056 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -852,6 +852,7 @@ i830_update_front_offset(ScrnInfoPtr pScrn)
              drm_intel_gem_bo_start_gtt_access(bo, 1);
              data = pI830->FbBase + bo->offset;
          }
+         i830_set_pixmap_bo(pScreen->GetScreenPixmap(pScreen), bo);
       }
    }
    if (!pScreen->ModifyPixmapHeader(pScreen->GetScreenPixmap(pScreen),

Created attachment 24625 [details] [review]
Don't enable exec fencing with EXA

Can you give this patch a try?

Created attachment 24627 [details] [review]
Don't enable exec fencing with EXA

Can you give this patch a try?

The new patch works for me. Thanks

Great! It is OK on my platform too! 

Thanks for all the testing and confirmation. I've gone ahead and pushed the patch now since it happens to also fix bug #21029, (pushed to both master
and the 2.7 branch).

-Carl

commit 620e97bbd6a811ad69b8ac94df1fe2c9edf65549
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Apr 8 15:49:00 2009 -0700

    Don't enable kernel execbuf fencing w/EXA
    
    If we enable kernel execbuf fence register management, it's best if the
    kernel manages all fence registers.  This works fine if the accel
    method is managing pixmaps or doesn't use offscreen pixmaps.  However
    with EXA, pixmap accesses are done relative to the framebuffer BAR
    mapping (pI830->FbBase) and the Screen pixmap address.  So if we try to
    set the screen pixmap to point at a GTT mapped (and therefore properly
    fenced) address, later calls to intel_get_pixmap_offset() will call
    into EXA, which will use the pseudo-random pixmap addr and the EXA
    offscreen base addr (which is really just FbBase) to calculate the
    offset.  This will fail.  So disable kernel fence reg management in the
    EXA case (this is easier than adding proper EXA pixmap management to
    xf86-video-intel, and makes more sense since we'll be removing EXA soon
    anyway).
    
    Fixes FDO #21027.
    
    Also happens to fix FDO #21029 (as tested by Carl Worth <cworth@cworth.org).

It is OK now with the commit ec8ef3b2984cef581ea7fa745a76fe6f97a952dd.