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

[Lenny Wang]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmdutils-opencl-perform-tests-on-available-opencl-de.patch
Type: application/octet-stream
Size: 11744 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131122/31365360/attachment.obj>