Summary: | [Regression] Hardware video acceleration of VP9 format is broken since kernel 4.13 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Maxim Baz <bugs.freedesktop> | ||||||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
Severity: | major | ||||||||||
Priority: | medium | CC: | bugs.freedesktop, intel-gfx-bugs, op8867555, vathsala.nagaraju | ||||||||
Version: | unspecified | Keywords: | bisected, regression | ||||||||
Hardware: | x86-64 (AMD64) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | ReadyForDev | ||||||||||
i915 platform: | BYT, KBL | i915 features: | GEM/execlists | ||||||||
Attachments: |
|
Description
Maxim Baz
2017-10-03 09:11:17 UTC
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.