Created attachment 134634 [details] screenshot_vp9_rendering_issue See attachment on how a video encoded with VP9 format is being rendered with hardware acceleration enabled since I upgraded the kernel to 4.13.3. There is no issue with playing H264 videos. Downgrading kernel to 4.12.12 resolves the issue. A few people in [1] confirm the same behavior. Reproducible on ArchLinux with mpv or chromium compiled with VA-API. People who confirm this bug have the following CPUs: Intel i7-7820HQ, i7-7500U, Pentium n3450. This bug was also submitted to the kernel [2], but it was suggested in [1] that this might be a better place to report it. [1] https://aur.archlinux.org/packages/chromium-vaapi [2] https://bugzilla.kernel.org/show_bug.cgi?id=197113
Hello Maxim, Could you please share logs, dmesg and/or kern.log with debug info, drm.debug=0xe log_bug_len=2M (or bigger) on grub. Thank you.
Created attachment 134658 [details] dmesg when playing vp9 video (4.12.8) Hi Elizabeth, I'm running into this same issue too. Here is the dmesg log with `drm.debug=0xe log_bug_len=2M` when playing a vp9 video with `mpv --hwdec=vaapi --vo=vaapi`. It didn't produce new logs when playing the video. Archlinux Thinkpad X1 Carbon 5th i7-7500U / HD620 mesa-17.1.8-2 libva-intel-driver 1.8.3-1
Created attachment 134659 [details] dmesg when playing vp9 video (4.13.3)
I did a git-bisect on drm-tip and found this commit is the first bad one: [2889caa9232109afc8881f29a2205abeb5709d0c] drm/i915: Eliminate lots of iterations over the execobjects array before this commit, vp9 videos rendered as expect.
Sadly likely to be a forgotten relocation specifier from userspace that happened to work (or at least until it came under GTT pressure). Another option, the one that happened last time would be a forgotten write hazard indicator. vp9 requires Kabylake?
(In reply to Chris Wilson from comment #5) > Sadly likely to be a forgotten relocation specifier from userspace that > happened to work (or at least until it came under GTT pressure). Another > option, the one that happened last time would be a forgotten write hazard > indicator. Thanks for the hint :) I just found that intel-vaapi-driver already fixed the issue on the master branch[1]. I think we can close this issue for now. [1]: https://github.com/01org/intel-vaapi-driver/issues/262
(In reply to Ming-Yang Lu from comment #6) > (In reply to Chris Wilson from comment #5) > > Sadly likely to be a forgotten relocation specifier from userspace that > > happened to work (or at least until it came under GTT pressure). Another > > option, the one that happened last time would be a forgotten write hazard > > indicator. > > Thanks for the hint :) > I just found that intel-vaapi-driver already fixed the issue on the master > branch[1]. > I think we can close this issue for now. > > [1]: https://github.com/01org/intel-vaapi-driver/issues/262 Thanks for the update. Closing.
*** Bug 103657 has been marked as a duplicate of this bug. ***
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.