[FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

Song, Ruiling ruiling.song at intel.com
Mon Apr 29 05:06:07 EEST 2019



> -----Original Message-----
> From: Song, Ruiling
> Sent: Tuesday, April 23, 2019 4:52 PM
> To: 'FFmpeg development discussions and patches' <ffmpeg-
> devel at ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl filter
> 
> 
> 
> > -----Original Message-----
> > From: Song, Ruiling
> > Sent: Sunday, April 21, 2019 8:18 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > nlmeans_opencl filter
> >
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> > Behalf Of
> > > Mark Thompson
> > > Sent: Saturday, April 20, 2019 11:08 PM
> > > To: ffmpeg-devel at ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > nlmeans_opencl
> > > filter
> > >
> > > On 17/04/2019 03:43, Song, Ruiling wrote:
> > > >> -----Original Message-----
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> > Behalf
> > > Of
> > > >> Mark Thompson
> > > >> Sent: Wednesday, April 17, 2019 5:28 AM
> > > >> To: ffmpeg-devel at ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > > nlmeans_opencl
> > > >> filter
> > > >>
> > > >> On 12/04/2019 16:09, Ruiling Song wrote:
> > > >>> Signed-off-by: Ruiling Song <ruiling.song at intel.com>
> > > >>
> > > >> I can't work out where the problem is, but there is something really
> > weirdly
> > > >> nondeterministic going on here.
> > > >>
> > > >> E.g.
> > > >>
> > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-
> 120-
> > > mbps-
> > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > > >>
> >
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > > >> frames:v 10 -f framemd5 -
> > > >> ...
> > > >> 0,          0,          0,        1, 12441600, 8b8805818076b23ae6f80ec2b5a349d4
> > > >> 0,          1,          1,        1, 12441600, 7a7fdaa083dc337cfb6af31b643f30a3
> > > >> 0,          2,          2,        1, 12441600, b10ef2a1e5125cc67e262e086f8040b5
> > > >> 0,          3,          3,        1, 12441600, c06b53ad90e0357e537df41b63d5b1dc
> > > >> 0,          4,          4,        1, 12441600, 5aa2da07703859a3dee080847dd17d46
> > > >> 0,          5,          5,        1, 12441600, 733364c6be6af825057e905a6092937d
> > > >> 0,          6,          6,        1, 12441600, 47edae2dec956a582b04babb745d26b0
> > > >> 0,          7,          7,        1, 12441600, 4e45fe8268df4298d06a17ab8e46c3e9
> > > >> 0,          8,          8,        1, 12441600, 960d722a3f8787c9191299a114c04174
> > > >> 0,          9,          9,        1, 12441600, e759c07ee4834a9cf94bfcb4128e7612
> > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-
> 120-
> > > mbps-
> > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > > >>
> >
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > > >> frames:v 10 -f framemd5 -
> > > >> 0,          0,          0,        1, 12441600, 8b8805818076b23ae6f80ec2b5a349d4
> > > >> [Parsed_nlmeans_opencl_2 @ 0x5557ae580d00] integral image
> > overflow
> > > >> 2157538
> > > >> 0,          1,          1,        1, 12441600, bce72e10a9f1118940c5a8392ad78ec3
> > > >> 0,          2,          2,        1, 12441600, b10ef2a1e5125cc67e262e086f8040b5
> > > >> 0,          3,          3,        1, 12441600, c06b53ad90e0357e537df41b63d5b1dc
> > > >> 0,          4,          4,        1, 12441600, 5aa2da07703859a3dee080847dd17d46
> > > >> 0,          5,          5,        1, 12441600, 733364c6be6af825057e905a6092937d
> > > >> 0,          6,          6,        1, 12441600, 47edae2dec956a582b04babb745d26b0
> > > >> 0,          7,          7,        1, 12441600, 4e45fe8268df4298d06a17ab8e46c3e9
> > > >> 0,          8,          8,        1, 12441600, 960d722a3f8787c9191299a114c04174
> > > >> 0,          9,          9,        1, 12441600, e759c07ee4834a9cf94bfcb4128e7612
> > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-
> 120-
> > > mbps-
> > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > > >>
> >
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > > >> frames:v 10 -f framemd5 -
> > > >> 0,          0,          0,        1, 12441600, 8b8805818076b23ae6f80ec2b5a349d4
> > > >> 0,          1,          1,        1, 12441600, 7a7fdaa083dc337cfb6af31b643f30a3
> > > >> [Parsed_nlmeans_opencl_2 @ 0x557c51fbfe80] integral image
> overflow
> > > >> 2098545
> > > >> 0,          2,          2,        1, 12441600, 68b390535adc5cfa0f8a7942c42a47ca
> > > >> 0,          3,          3,        1, 12441600, c06b53ad90e0357e537df41b63d5b1dc
> > > >> 0,          4,          4,        1, 12441600, 5aa2da07703859a3dee080847dd17d46
> > > >> 0,          5,          5,        1, 12441600, 733364c6be6af825057e905a6092937d
> > > >> 0,          6,          6,        1, 12441600, 47edae2dec956a582b04babb745d26b0
> > > >> 0,          7,          7,        1, 12441600, 4e45fe8268df4298d06a17ab8e46c3e9
> > > >> 0,          8,          8,        1, 12441600, 960d722a3f8787c9191299a114c04174
> > > >> 0,          9,          9,        1, 12441600, e759c07ee4834a9cf94bfcb4128e7612
> > > >>
> > > >> Frame 1 gave an overflow on the second run, and gets a different
> > answer,
> > > then
> > > >> frame 2 in the same way on the third run?  I can't characterise when
> this
> > > >> happens, it seems to be pretty random with low probability.
> > > >
> > > > I tried to reproduce on my SKL and KBL, with Beignet and Neo. And
> didn't
> > > reproduce the issue.
> > > > As I am encountering some network issue, I didn't get the video sample
> > you
> > > provide (I am using https://4ksamples.com/ses-astra-uhd-test-2-2160p-
> > uhdtv/ ),
> > > I can try later to download the same video as you.
> > > > May be an OpenCL driver issue? I am not sure yet. So could you provide
> > what
> > > hardware and opencl driver version you are using? So I can do some
> > debugging if
> > > possible.
> > >
> > > CFL-8700 with git Beignet.
> > First I want to say that Beignet never declare official support of CFL, which
> > means that CFL was not fully tested.
> > I guess your problem is specific to CFL, may be specific to Beignet + CFL,
> > maybe not.
> > I highly recommend you to try NEO(https://github.com/intel/compute-
> > runtime ) which officially support CFL.
> > If you cannot reproduce with NEO, then it would be obvious this is a bug of
> > Beignet on CFL.
> > I also try jellyfish sample on KBL and SKL, both Beignet and NEO, still not
> > reproduce the issue.
> > The Beignet was not developed or tested anymore. What's more the CFL
> > support of Beignet was not tested extensively.
> > I will try to find one CFL machine to have a test.
> I think you are running  against Beignet “Allow creating out-of-order queues
> with clCreateCommandQueue”, right?
> I got one CFL i5-7600k, and only make small modification to CMake file to use
> llvm-4.0.
> And use exact command and the jellyfish video clip. Still could not reproduce.
> So could you have a test against intel-compute-runtime when you have time?
> Or do you have any local changes against Beignet or related software?
> Which Linux kernel, libdrm, llvm version are you using?
> 
> I am guessing may be the event or asynchronous not correctly handled in
> Beignet,
> Could you make some local modification and test on your machine?
> Make the clEnqueueWriteBuffer(ctx->command_queue, ctx->overflow,
> CL_TRUE,...);
> Previously I use CL_FALSE. Hope synchronous write could help on this.

In order to verify the patch, I also have more testing on the CPU OpenCL driver from Intel.
I make it run 100 times, and still not see any reported overflow. So I think we can say the filter is in good quality to be merged. Any different idea?

Thanks!
Ruiling


More information about the ffmpeg-devel mailing list