Bug 21027 - [EXA] xvideo hang X
Summary: [EXA] xvideo hang X
Status: VERIFIED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: high critical
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20276
  Show dependency treegraph
 
Reported: 2009-04-03 02:01 UTC by zhao jian
Modified: 2009-04-09 00:34 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.0.log (53.18 KB, text/plain)
2009-04-03 02:01 UTC, zhao jian
no flags Details
Don't enable exec fencing with EXA (950 bytes, patch)
2009-04-06 19:13 UTC, Jesse Barnes
no flags Details | Splinter Review
Don't enable exec fencing with EXA (950 bytes, patch)
2009-04-06 19:20 UTC, Jesse Barnes
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description zhao jian 2009-04-03 02:01:52 UTC
Created attachment 24499 [details]
xorg.0.log

System Environment:
----------------------
Platform:               G45
Arch:           x86_64
Platform:               G45
OSD:            Fedora release 8 (Werewolf)
Kernel_version:         2.6.29
Libdrm:                (master)51d6346f9f3c425f49e57d185530c6bcaeb94f5e
Mesa:           (mesa_7_4_branch)7be149cfd131c0b3f7d4337bb83e6fba5f563bf9
Xserver:        (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:     (2.7)10b5014c42dc055d9559ee112cc7a017e887d813
Kernel:        (drm-intel-2.6.29)0e56a4d653b66d4729f944b23935a00c4472f987

Bug Description:
---------------------
In EXA mode, start gnome and play a video with mplayer, then the X will hang. 

Reproduce Steps:
---------------------
1. xinit&
2. gnome-session&
3. mplayer XX.VOB(some videoes)
Comment 1 Jesse Barnes 2009-04-03 12:06:13 UTC
I haven't been able to reproduce this yet, still trying.
Comment 2 Jesse Barnes 2009-04-03 12:54:04 UTC
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).
Comment 3 Jesse Barnes 2009-04-03 12:55:43 UTC
Even non-composited textured video looks fine, so I'll assume this report is about overlay video.
Comment 4 Jesse Barnes 2009-04-03 14:07:39 UTC
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...
Comment 5 Raúl 2009-04-03 15:48:14 UTC
I've just reported a similar issue: http://bugs.freedesktop.org/show_bug.cgi?id=20994 maybe it's the same.

HTH.
Comment 6 Gordon Jin 2009-04-03 19:49:00 UTC
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.
Comment 7 Jesse Barnes 2009-04-04 16:30:17 UTC
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... :)
Comment 8 Jesse Barnes 2009-04-06 12:40:43 UTC
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),
Comment 9 Jesse Barnes 2009-04-06 19:13:44 UTC
Created attachment 24625 [details] [review]
Don't enable exec fencing with EXA

Can you give this patch a try?
Comment 10 Jesse Barnes 2009-04-06 19:20:40 UTC
Created attachment 24627 [details] [review]
Don't enable exec fencing with EXA

Can you give this patch a try?
Comment 11 haihao 2009-04-06 19:24:22 UTC
The new patch works for me. Thanks
Comment 12 zhao jian 2009-04-06 19:55:10 UTC
Great! It is OK on my platform too! 
Comment 13 Carl Worth 2009-04-08 15:55:07 UTC
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).
Comment 14 zhao jian 2009-04-09 00:34:48 UTC
It is OK now with the commit ec8ef3b2984cef581ea7fa745a76fe6f97a952dd. 


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.