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.
Bisect result: db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit commit db138b9ba12a0de5d6140832c0679c2418e3e7e0 Author: Michel Dänzer 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
On 30/03/17 09:16 PM, Jan Burgmeier wrote:
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.
Bisect result: db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit commit db138b9ba12a0de5d6140832c0679c2418e3e7e0 Author: Michel Dänzer michel.daenzer@amd.com Date: Thu Jan 21 18:08:49 2016 +0900
radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATEioctl
Not doing so makes it impossible for radeon_bo_open callers to setany 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.
Without this change, the flags passed to radeon_bo_open are ignored. The question is which flag passed from where is causing the trouble.
Hi Jan,
very interesting. Sounds like we somehow mess up the buffer placement so that it won't work any more with UVD.
But this only happens with WMV files? Not with H264 or anything else?
Anyway please open up a bug report on https://bugs.freedesktop.org/.
Thanks, Christian.
Am 30.03.2017 um 14:16 schrieb Jan Burgmeier:
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.
Bisect result: db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit commit db138b9ba12a0de5d6140832c0679c2418e3e7e0 Author: Michel Dänzer michel.daenzer@amd.com Date: Thu Jan 21 18:08:49 2016 +0900
radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATEioctl
Not doing so makes it impossible for radeon_bo_open callers to setany 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
the error only occurs with wmv, h264 works.
I created a bug report: https://bugs.freedesktop.org/show_bug.cgi?id=100510
Regards, Jan
On Fri, 2017-03-31 at 09:13 +0200, Christian König wrote:
Hi Jan,
very interesting. Sounds like we somehow mess up the buffer placement so that it won't work any more with UVD.
But this only happens with WMV files? Not with H264 or anything else?
Anyway please open up a bug report on https://bugs.freedesktop.org/.
Thanks, Christian.
Am 30.03.2017 um 14:16 schrieb Jan Burgmeier:
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.
Bisect result: db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit commit db138b9ba12a0de5d6140832c0679c2418e3e7e0 Author: Michel Dänzer 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Christian König -
Jan Burgmeier -
Michel Dänzer