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

Stefano Sabatini stefasab at gmail.com
Thu Nov 21 21:01:46 CET 2013

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

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

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

More information about the ffmpeg-devel mailing list