System Environment: ---------------------------------------- Platform: IVB Kernel_version: 3.10.0-rc2+ Libdrm: (master)libdrm-2.4.46-2-gfea5408098c3c3057958e85ea9d7146f0b08749e Mesa: (master)190312949e8ce2c1dc884d4db5d6a44511666641 Xserver: (master)xorg-server-1.14.99.1-137-g74469895e39fa38337f59edd64c4031ab9bb51d8 Xf86_video_intel:(master)2.21.12-39-g2737aaab77cc6233826077b90d001fe45efc376c Cairo: (master)03c81d414d4edb710c91f96ddb7dbf73e5432583 Libva: (staging)fbd3de9b22491689c6c3e5f1c305d7af76444e45 Libva_intel_driver: (staging)1caf179b1425b13cacaa421c688c6df8369668c6 OpenCL: (master)75b59f27c0bf403e97925e32b407b4fcb9bcb73f Kernel_unstable: (drm-intel-nightly)68c6cd3f1312965698b2af5bb08e15807ce9ae2d Bug info: ---------------------------------------- 1 xinit& 2 mplayer -vo vaapi video.mp4 when using SNA, there is blank screen. when using UXA, it works well. ######## 1 xinit& 2 gnome-session 3 mplayer -vo vaapi video.mp4 It works well when using both mode.
*** Bug 67211 has been marked as a duplicate of this bug. ***
Please attach Xorg.0.log after the failure -- even better if can provide a full debug log as well.
Created attachment 82888 [details] Xorg.0.log a 4k movie to a 4k screen
No, this isn't decoding issue. The root cause is DR2 can't swap buffers for a drawable whose origin is out of the screen when using SNA
Created attachment 82895 [details] [review] A patch to fix can_blit() Could you try with this patch ?
(In reply to comment #0) > System Environment: > ---------------------------------------- > Platform: IVB > Kernel_version: 3.10.0-rc2+ > Libdrm: > (master)libdrm-2.4.46-2-gfea5408098c3c3057958e85ea9d7146f0b08749e > Mesa: (master)190312949e8ce2c1dc884d4db5d6a44511666641 > Xserver: > (master)xorg-server-1.14.99.1-137-g74469895e39fa38337f59edd64c4031ab9bb51d8 > Xf86_video_intel:(master)2.21.12-39-g2737aaab77cc6233826077b90d001fe45efc376c > Cairo: (master)03c81d414d4edb710c91f96ddb7dbf73e5432583 > Libva: (staging)fbd3de9b22491689c6c3e5f1c305d7af76444e45 > Libva_intel_driver: > (staging)1caf179b1425b13cacaa421c688c6df8369668c6 > OpenCL: (master)75b59f27c0bf403e97925e32b407b4fcb9bcb73f > Kernel_unstable: (drm-intel-nightly)68c6cd3f1312965698b2af5bb08e15807ce9ae2d > > Bug info: > ---------------------------------------- > 1 xinit& > 2 mplayer -vo vaapi video.mp4 This command does not involve hardware decoding through VA-API. So, as Haihao mentioned further on, you are hitting and Xv issue. The correct command to enable VA-API decoding is mplayer -vo vaapi -va vaapi ... but, it won't succeed on Ivybridge. Ivybridge can support 4K video but only if a single dimension is 4K. i.e. 4K x 3K or 3K x 3K would work, but not 4K x 4K.
s/Xv/DRI/ issue. Xv is addressed in another bug. :)
(In reply to comment #5) > Created attachment 82895 [details] [review] [review] > A patch to fix can_blit() > > Could you try with this patch ? Hmm, not quite. The bug is a typo later on. What I'm trying to validate here is that we do not try to read/write beyond the bounds the associated bo (which can happen due to the asynchronous notification of drawable/buffer changes.)
Too early, not enough coffee. I had the correct masks.
I've pushed a patch to clarify just what can_blit() is trying to test: commit 6d80bd6a7311926f258cd92f0b22e8d03022b62b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 24 09:03:45 2013 +0100 sna/dri: Cleanup validation of blit extents Prompted by a suggestion by Haihao, clarify the intent behind checking the incoming maximum blit extents against the recorded sizes of the attached bo. Due to the asynchronous nature of DRI2 invalidation, it is possible for the DRI2 buffer to be stale and for its bo to be smaller than required for the client's blit. References: https://bugs.freedesktop.org/show_bug.cgi?id=67210 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: haihao <haihao.xiang@intel.com> Paste the debug log somewhere.
cmd "mplayer -vo vaapi" work on IVB/HSW. (In reply to comment #6) > (In reply to comment #0) > > System Environment: > > ---------------------------------------- > > Platform: IVB > > Kernel_version: 3.10.0-rc2+ > > Libdrm: > > (master)libdrm-2.4.46-2-gfea5408098c3c3057958e85ea9d7146f0b08749e > > Mesa: (master)190312949e8ce2c1dc884d4db5d6a44511666641 > > Xserver: > > (master)xorg-server-1.14.99.1-137-g74469895e39fa38337f59edd64c4031ab9bb51d8 > > Xf86_video_intel:(master)2.21.12-39-g2737aaab77cc6233826077b90d001fe45efc376c > > Cairo: (master)03c81d414d4edb710c91f96ddb7dbf73e5432583 > > Libva: (staging)fbd3de9b22491689c6c3e5f1c305d7af76444e45 > > Libva_intel_driver: > > (staging)1caf179b1425b13cacaa421c688c6df8369668c6 > > OpenCL: (master)75b59f27c0bf403e97925e32b407b4fcb9bcb73f > > Kernel_unstable: (drm-intel-nightly)68c6cd3f1312965698b2af5bb08e15807ce9ae2d > > > > Bug info: > > ---------------------------------------- > > 1 xinit& > > 2 mplayer -vo vaapi video.mp4 > > This command does not involve hardware decoding through VA-API. So, as > Haihao mentioned further on, you are hitting and Xv issue. > > The correct command to enable VA-API decoding is mplayer -vo vaapi -va vaapi > > ... but, it won't succeed on Ivybridge. Ivybridge can support 4K video but > only if a single dimension is 4K. i.e. 4K x 3K or 3K x 3K would work, but > not 4K x 4K.
(In reply to comment #11) > cmd "mplayer -vo vaapi" work on IVB/HSW. As I mentioned, this does not involve "decode with vaapi" as the title of this bug implies. This command only exercices "render with vaapi". If you want decode, try -vo vaapi -va vaapi.
Built and tested mplayer/vaapi and both "-vo vaapi" and "-vo vaapi -va vaapi" playback the 4kx2k video fine - on an IVB GT1 with only a 1366x768 panel. Your 4k screen btw is not running at 4k. Can you please confirm the bug, and please attach the full debug log.
commit 6d80bd6a7311926f258cd92f0b22e8d03022b62b broke GL apps on my system. glxgears just shows a black box. The driver at commit 74dd10d252df2d826b6db5da7e53bd7c5d76dec0 works fine.
If you attach an Xorg.0.log with --enable-debug=full I can tell if it is a trivial mistake, or if you indeed have the client race that the validation is designed to reject.
Sigh, the earlier check for bottom-right was (at least partially) right: commit ef2a45731ef55b9fbafe5da67e0251b9b871bda9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 24 19:44:15 2013 +0100 sna/dri: Restore the comparison of bottom-right extents to the pixmap origin This reverts a portion of commit 6d80bd6a73 so that we do not compare an offset redirected window against its outer frame (e.g. glxgears in a 300x300 under unity sits within a much larger ~330x330 frame). References: https://bugs.freedesktop.org/show_bug.cgi?id=67210 Reported-by: Joseph Yasi <joe.yasi@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #12) > (In reply to comment #11) > > cmd "mplayer -vo vaapi" work on IVB/HSW. > > As I mentioned, this does not involve "decode with vaapi" as the title of > this bug implies. This command only exercices "render with vaapi". > > If you want decode, try -vo vaapi -va vaapi. Yes this is rendering issue. However for the latest version of mplayer-vaapi, only '-vo vaapi' is needed for "decoding with vaapi". is this a bug of mplayer vaapi ?
xf86-video-intel commit ef2a45731ef55b9fbafe5da67e0251b9b871bda9 4kx4k video to 4kx4k screen cmd1: 1. xinit& 2. mplayer -vo vaapi -va vaapi video.mp4 after above cmd, there is no picture -------------------------------------------- cmd2: 1. xinit& 2. gnome-session 3. mplayer -vo vaapi -va vaapi video.mp4 when play the video at the first time, there is no picture. But, play again ,it works well the link of Xorg.0.log http://tinderbox.sh.intel.com/media/ file name Xorg.0.log
Oh, pageflips disabled. Do you use that xorg.conf universally, even for power testing?
only test encoding/decoding performance, papeflips disable. git reset --hard 42862298bc4d8588433abc8ac3b1ff65ec20e30d Whatever using Option "SwapbuffersWait" "off"/"on", the issue can't be reproduced. (In reply to comment #19) > Oh, pageflips disabled. Do you use that xorg.conf universally, even for > power testing?
commit 6f5fd772c7ca656b86394a0f036d4e0cf5b33d8e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 25 08:29:55 2013 +0100 sna/dri: Discard the strict checking for stale bo before performing a blit Instead of checking that the DRI2Buffers match up with the current DRI2Drawable, clip the area that is being copied to the minimum extents of the Drawable, source and destination buffers. This ensures that we never read nor write beyond the extents of the allocated or visible regions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67305 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 83184 [details] Xorg.0.log using SNA, there is no picture system environments: -------------------------------------- Kernel_version: 3.10.0-rc2+ Libdrm: (master)libdrm-2.4.46-2-gfea5408098c3c3057958e85ea9d7146f0b08749e Mesa: (master)803f755edeabd1b0af3d8f4ebf2005333e152ad4 Xserver: (master)xorg-server-1.14.99.1-167-gff38bbe81ace85bf675bbaa0a9ca5f3b32ede449 Xf86_video_intel:(master)b0826907dd7844c03080421d79e5f927b1245833 Cairo: (master)274863be08f6c8df6d411df9db725d34f7fbabea Libva: (staging)d4988142a3f2256e38c5c5cdcdfc1b4f5f3c1ea9 Libva_intel_driver: (staging)7783b945824c9c01b415ca7b72c2d9463c8ae40b
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.