[FFmpeg-devel] [PATCH]opencl: automatically select the fastest opencl device

[Lenny Wang]

On Thu, Nov 21, 2013 at 2:01 PM, Stefano Sabatini <stefasab at gmail.com> wrote:
> On date Thursday 2013-11-21 06:58:32 -0600, Lenny Wang encoded:
>> On Thu, Nov 21, 2013 at 6:40 AM, Stefano Sabatini <stefasab at gmail.com>wrote:
>>
>> > On date Thursday 2013-11-21 06:05:19 -0600, Lenny Wang encoded:
>> > > Hi,
>> > >
>> > > Use -opencl_options device_idx=-1 or platform_idx=-1 to enable
>> > > automatic opencl device selection.
>> > >
>> > > There are usually more than a couple (CPU, iGPU, dGPU) opencl capable
>> > > devices present in a mainstream platform.  We wanted something less
>> > > heuristic and effective in ffmpeg with automatic opencl device
>> > > selection.  This is achieved by running a small representative
>> > > workload (unsharp) across all available devices, and the one with the
>> > > shortest processing time will be picked.  The entire benchmark only
>> > > takes a few seconds to execute.
>> >
>> > I don't think it is acceptable to call libavfilter (or any other
>> > library) from libavutil.
>>
>>
>> > If you need to select the fastest device, you could add a dedicated
>> > tool (e.g. ffmpeg/tools/opencl-find-fastest-device), but this should
>> > not be part of the library.
>
> [...]
>> No, it doesn't call any libavfilter APIs.   We only 'borrow' the kernel
>> from unsharp opencl fitler and use it in the benchmark.
>>
>> It's not designed as a tool but rather part of the opencl-util framework
>> using the existing 'opencl_options'.
>
> Yet it is assuming that there is an "unsharp" kernel, and applying
> very specific code to compute benchmarks. Keep in mind that by design
> libavutil should not depend on external libraries, and assuming the
> existence of a kernel with a specific name is violating this
> principle.
>
> Thus I'd suggest to create a tool for that instead, moving the logic
> to an external application. For commandline users it will have a
> minimal overhead, and will make it possible to run the benchmark just
> once rather than every time the libavutil opencl subsystem is
> initialized.
>
> library users should probably devise their own heuristics for
> detecting the fastest device, based on what it is assumed to be
> available, and thus adopting ad-hoc logic which really doesn't belong
> to a generic library such as libavutil.
> --
> FFmpeg = Frightening and Fierce Marvellous Puristic Elaborated Generator
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hi Stefano,

Thanks for your comments.

I agree.  I think we can export this as a commandline tool, for
example use "ffmpeg -test_opencl" to invoke the benchmark and it will
print out the test result and platform/device indices used for
"-opencl_options".  The opencl program for such a benchmark will be
standalone without relying on libavfilter.