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

Lenny Wang lenny at multicorewareinc.com
Fri Nov 22 19:53:38 CET 2013


On Fri, Nov 22, 2013 at 4:42 AM, Lenny Wang <lenny at multicorewareinc.com> wrote:
> On Thu, Nov 21, 2013 at 2:50 PM, Lenny Wang <lenny at multicorewareinc.com> wrote:
>> 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.
>
> Attached patch implements "-show_opencl" in cmdutil to perform tests
> on all available opencl devices within a system.

Patch updated, use "-show_opencl" utility to test all opencl devices
and the fastest one got selected in the end.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmdutils-opencl-show-available-opencl-devices-.patch
Type: application/octet-stream
Size: 11978 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131122/e024a0e4/attachment.obj>


More information about the ffmpeg-devel mailing list