Hi Thomas,
[moving vger to bcc]
mhm, sounds like something isn't running in parallel any more.
We usually don't test the multimedia engines for this but we do test
gfx+compute, so I'm really wondering what goes wrong here.
Could you run some tests for me? Additional to that I'm going to raise
that issue with our multimedia guys later today.
Thanks for the info,
Christian.
Am 18.06.22 um 18:13 schrieb Thomas Voegtle:
Hello,
I noticed a performance drop encoding a mpeg file to a h264 video using
the vaapi option deinterlace_vaapi on a Haswell i5-4570 with Linux
5.19-rc1.
A 10 minute long video takes normally 41s to convert, now with 5.19-rc1
it takes about 2m 36s.
My ffmpeg line is:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i test.vdr -vf 'deinterlace_vaapi' -c:v
h264_vaapi
Removing the option deinterlace_vaapi shows no difference in
performance between 5.18 and 5.19-rcX.
I bisected this down to:
commit 047a1b877ed48098bed71fcfb1d4891e1b54441d
Author: Christian König <christian.koenig@xxxxxxx>
Date: Tue Nov 23 09:33:07 2021 +0100
dma-buf & drm/amdgpu: remove dma_resv workaround
and wasn't able to revert this one on top of 5.19-rcX.
I tried the predecessor commit:
commit 73511edf8b196e6f1ccda0fdf294ff57aa2dc9db (HEAD)
Author: Christian König <christian.koenig@xxxxxxx>
Date: Tue Nov 9 11:08:18 2021 +0100
dma-buf: specify usage while adding fences to dma_resv obj v7
which is fine.
Using ffmpeg 5.0.1 with libva 2.10.0 and intel vaapi driver 2.4.1
Best regards,
Thomas
