| Bug ID | 100510 |
|---|---|
| Summary | [radeon] Heavy artifacts during hw accelerated playback of wm= v files |
| Product | DRI |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | libdrm |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | jan.burgmeier@unicon-software.com |
Hi, with versions newer than libdrm-2.4.66 I have heavy artifacts during hw accelerated playback of wmv files vaapi/vdpau tested with gstreamer- 0.10 and ffmpeg based mpv. The error occures only with wmv, h264 works. Bisect result: db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit commit db138b9ba12a0de5d6140832c0679c2418e3e7e0 Author: Michel D=C3=A4nzer <michel.daenzer@amd.com> Date: Thu Jan 21 18:08:49 2016 +0900 radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATE ioctl Not doing so makes it impossible for radeon_bo_open callers to set any RADEON_GEM_* flags for the newly created BO. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> If I revert this commit on the current master branch the artefacts are gone. System environment: -- chipset: AMD GX-217GA SOC with Radeon(tm) HD Graphics -- system architecture: 32-bit -- xserver: 1.19.1 -- mesa: 13.0.3, 13.0.6, 17.0.2 -- libdrm: 2.4.74 -- kernel: 4.4.11 -- Linux distribution: eLux -- Machine or mobo model: HP t620 dual core thin client Regards, Jan Burgmeier
Please attach your full dmesg output as well.
Created attachment 130614 =
[details]
full dmesg output
Created attachment 130615 <= a href=3D"attachment.cgi?id=3D130615&action=3Dedit" title=3D"Hack for t= esting">[details] [review] Hack for testing Please apply the attached code change with "git apply hack.patch"= on a linux kernel tree and see if that helps. It overrides the setting from libdrm to always use VRAM for UVD submissions. Not a final solution, but it should help to narrow down the problem.
I applied the hack to HEAD of the staging-next branch and it w= orked.
| What | Removed | Added |
|---|---|---|
| Attachment #130615 is obsolete | 1 |
Created attachment 130= 618 [details] [review] Hack number 2 for testing Ok, just as I expected we suddenly don't put buffers into VRAM any more and= the UVD block has an undocumented requirement for WMV playback that those buffe= rs needs to be in VRAM. No idea why user space is broken, but the kernel should catch such cases and force them into VRAM when the hardware needs that. Please revert the last hack and try this one. It should only the first and second buffer into VRAM. If that doesn't work try to change the if so that the first,second and third buffer are forced into VRAM etc.... I need to know which one is needed in VRAM here.