Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers and ICD loader
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of Hendrik Leppkes
> Sent: Monday, June 08, 2015 1:00 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers
> and ICD loader
>
> On Mon, Jun 8, 2015 at 5:53 AM, Gupta, Maneesh
> wrote:
> >> -Original Message-
> >> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> >> boun...@ffmpeg.org] On Behalf Of James Almer
> >> Sent: Thursday, May 28, 2015 10:06 AM
> >> To: FFmpeg development discussions and patches
> >> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL
> >> headers and ICD loader
> >>
> >> On 28/05/15 12:28 AM, Gupta, Maneesh wrote:
> >> > Attached is a patch that enables configure to autodetect the
> >> > presence of
> >> OpenCL headers and ICD loader. If the necessary headers are found,
> >> the OpenCL infrastructure compilation is enabled as well. Note that
> >> this does not modify the runtime behavior in any way. Execution of
> >> the OpenCL code path still requires the user to explicitly enable it.
> >> >
> >> > Please review the patch and share your comments on the same.
> >> >
> >> > - Maneesh
> >>
> >> I personally don't agree OpenCL should be autodetected.
> >>
> >> Currently, only the so called "system" libs are autodetected (zlib,
> >> iconv, pthreads, the like). Open*L, decoding/encoding libraries, and
> >> other miscellaneous libraries are enabled only if explicitly requested.
> >> If we enable one by default, then there's no argument against
> >> enabling every other as well ("Why this one but not that other
> >> one?"), and suddenly default builds become bloated and automated
> >> scripts get potentially broken until adapted.
> >>
> >> Lets keep default builds as lightweight as possible, and allow people
> >> to explicitly enable the functionality they require.
> >
> > [Gupta, Maneesh] Apologize for the delayed response. However grep'ing
> the string "autodetect" in the configure script throws up several "non-
> system" libs including D3D11VA, DXVA2, VAAPI, VDA, VDPAU, sdl. Why are
> they turned on by default? Several of these non-system libs enable use of
> hardware acceleration. OpenCL is similar in nature with a key difference that
> it is more platform/OS agnostic and can run on both CPU as well as GPU.
>
> Most of those don't link against any library, ie. like DXVA2, it doesn't add
> any
> extra link dependencies which are not system libraries, so the resulting build
> is still perfectly portable.
> For the few exceptions that do add link deps, we suffer for that enough, we
> don't need any more "exceptions".
>
> - Hendrik
[Gupta, Maneesh] The OpenCL code only links against the ICD loader. Also x264
enables OpenCL code by default and the build is perfectly portable as far as I
have seen. I don't see how that is not possible in the case of ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers and ICD loader
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of James Almer
> Sent: Thursday, May 28, 2015 10:06 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers
> and ICD loader
>
> On 28/05/15 12:28 AM, Gupta, Maneesh wrote:
> > Attached is a patch that enables configure to autodetect the presence of
> OpenCL headers and ICD loader. If the necessary headers are found, the
> OpenCL infrastructure compilation is enabled as well. Note that this does not
> modify the runtime behavior in any way. Execution of the OpenCL code path
> still requires the user to explicitly enable it.
> >
> > Please review the patch and share your comments on the same.
> >
> > - Maneesh
>
> I personally don't agree OpenCL should be autodetected.
>
> Currently, only the so called "system" libs are autodetected (zlib, iconv,
> pthreads, the like). Open*L, decoding/encoding libraries, and other
> miscellaneous libraries are enabled only if explicitly requested.
> If we enable one by default, then there's no argument against enabling
> every other as well ("Why this one but not that other one?"), and suddenly
> default builds become bloated and automated scripts get potentially broken
> until adapted.
>
> Lets keep default builds as lightweight as possible, and allow people to
> explicitly enable the functionality they require.
[Gupta, Maneesh] Apologize for the delayed response. However grep'ing the
string "autodetect" in the configure script throws up several "non-system" libs
including D3D11VA, DXVA2, VAAPI, VDA, VDPAU, sdl. Why are they turned on by
default? Several of these non-system libs enable use of hardware acceleration.
OpenCL is similar in nature with a key difference that it is more platform/OS
agnostic and can run on both CPU as well as GPU.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: autodetect OpenCL headers and ICD loader
Attached is a patch that enables configure to autodetect the presence of OpenCL headers and ICD loader. If the necessary headers are found, the OpenCL infrastructure compilation is enabled as well. Note that this does not modify the runtime behavior in any way. Execution of the OpenCL code path still requires the user to explicitly enable it. Please review the patch and share your comments on the same. - Maneesh 0001-configure-autodetect-OpenCL-headers-and-ICD-loader.patch Description: 0001-configure-autodetect-OpenCL-headers-and-ICD-loader.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] OpenCL: Avoid potential buffer overflow in cmdutils_opencl.c by using strncpy instead of strcpy
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Michael Niedermayer > Sent: Monday, April 27, 2015 4:49 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/2] OpenCL: Avoid potential buffer > overflow in cmdutils_opencl.c by using strncpy instead of strcpy > > On Mon, Apr 27, 2015 at 07:51:36AM +, Gupta, Maneesh wrote: > > Hi, > > > > There was a potential buffer overflow during a strcpy operation in > cmdutils_opencl.c. This patch attempts to fix the same. > > > > Regards, > > Maneesh > > > cmdutils_opencl.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > b6d9e0b4f9efc1d0ae9d3f05b7802c81007999d7 > > 0002-OpenCL-Replace-strcpy-with-strncpy-to-avoid-buffer-o.patch > > From 026f4de0628c3e7e0211ee0f6c96e816ff757cd1 Mon Sep 17 00:00:00 > 2001 > > From: Maneesh Gupta > > Date: Sat, 25 Apr 2015 11:17:05 +0530 > > Subject: [PATCH 2/2] OpenCL: Replace strcpy with strncpy to avoid > > buffer overflows > > > > Signed-off-by: Maneesh Gupta > > --- > > cmdutils_opencl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/cmdutils_opencl.c b/cmdutils_opencl.c index > > 3dfd156..73cab98 100644 > > --- a/cmdutils_opencl.c > > +++ b/cmdutils_opencl.c > > @@ -238,7 +238,7 @@ int opt_opencl_bench(void *optctx, const char > *opt, const char *arg) > > devices[count].platform_idx = i; > > devices[count].device_idx = j; > > devices[count].runtime = score; > > -strcpy(devices[count].device_name, device_node- > >device_name); > > +strncpy(devices[count].device_name, > > + device_node->device_name, 64); > this should be > sizeof(devices[count].device_name) > and av_strlcpy() > [Gupta, Maneesh] Attached is the updated patch. 0002-OpenCL-Avoid-potential-buffer-overflow-in-cmdutils_o.patch Description: 0002-OpenCL-Avoid-potential-buffer-overflow-in-cmdutils_o.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] OpenCL: Fix ABI incompatibility issues
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Michael Niedermayer > Sent: Monday, April 27, 2015 4:57 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 1/2] OpenCL: Fix ABI incompatibility > issues > > On Mon, Apr 27, 2015 at 07:51:33AM +, Gupta, Maneesh wrote: > > Hi, > > > > This patch attempts to fix the ABI incompatibility issues in the OpenCL > code. Please review it and let me know if there is anything that I missed > addressing in this patch. > > > > Regards, > > Maneesh > > > opencl.c | 42 ++ > > opencl.h | 10 ++ > > 2 files changed, 40 insertions(+), 12 deletions(-) > > 091096c9ceb25f09140cbf6e4551c879a84696b4 > > 0001-OpenCL-Fix-ABI-incompatibility-issues.patch > > From 29a69771bd95e230525b67f24694a68ac8ebbade Mon Sep 17 00:00:00 > 2001 > > From: Maneesh Gupta > > Date: Sat, 25 Apr 2015 11:16:35 +0530 > > > Subject: [PATCH 1/2] OpenCL: Fix ABI incompatibility issues > > this commit message is unacceptable > > its too terse > please explain, what is changed, why it is changed, and how this is achived in > the commit message > [Gupta, Maneesh] Attached is the updated patch. 0001-OpenCL-Fix-ABI-incompatibility-issues.patch Description: 0001-OpenCL-Fix-ABI-incompatibility-issues.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] OpenCL: Fix ABI incompatibility issues
Hi, This patch attempts to fix the ABI incompatibility issues in the OpenCL code. Please review it and let me know if there is anything that I missed addressing in this patch. Regards, Maneesh 0001-OpenCL-Fix-ABI-incompatibility-issues.patch Description: 0001-OpenCL-Fix-ABI-incompatibility-issues.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] OpenCL: Avoid potential buffer overflow in cmdutils_opencl.c by using strncpy instead of strcpy
Hi, There was a potential buffer overflow during a strcpy operation in cmdutils_opencl.c. This patch attempts to fix the same. Regards, Maneesh 0002-OpenCL-Replace-strcpy-with-strncpy-to-avoid-buffer-o.patch Description: 0002-OpenCL-Replace-strcpy-with-strncpy-to-avoid-buffer-o.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Michael Niedermayer > Sent: Monday, March 02, 2015 4:58 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl > > On Mon, Mar 02, 2015 at 10:59:10AM +, Carl Eugen Hoyos wrote: > > Gupta, Maneesh amd.com> writes: > > > > > > > Similar to the way SDL is being autodetected, the attached patch > > > > > proposes to autodetect OpenCL. > > > > > > > > This cannot be done since the API is defined as being not stable. > > > > > > Sorry. I am not sure what you mean by this. Do you mean OpenCL API > > > is not stable? > > > > No, FFmpeg's OpenCL API is not stable. > > btw, to not just list problems but rather suggest potential solutions: > to make the FFmpeg OpenCL API stable, i think help in maintaining the > OpenCL code in FFmpeg is needed. The current maintainer seems not to > have enough time or interrest about ABI/API compatibility. > What is needed is to review and potentially change the OpenCL related > API/ABI used between libavutil and the other libs so that everyday > extensions/changes would not break that interface between the libs then all > the "non stable / experimental" notes can be removed and it could be saftely > be used by users and distributions [Gupta, Maneesh] Thanks. It definitely helps to know what is the direction required to make the feature stable. Let me see how I can contribute in doing that. > > > [...] > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB > > Awnsering whenever a program halts or runs forever is On a turing machine, > in general impossible (turings halting problem). > On any real computer, always possible as a real computer has a finite number > of states N, and will either halt in less than N cycles or never halt. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Carl Eugen Hoyos > Sent: Monday, March 02, 2015 4:29 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl > > Gupta, Maneesh amd.com> writes: > > > > > Similar to the way SDL is being autodetected, the attached patch > > > > proposes to autodetect OpenCL. > > > > > > This cannot be done since the API is defined as being not stable. > > > > Sorry. I am not sure what you mean by this. Do you mean OpenCL API is > > not stable? > > No, FFmpeg's OpenCL API is not stable. [Gupta, Maneesh] Okay. Thanks for the clarification. So what you are saying is that OpenCL support in ffmpeg is not fully mature enough. It is to be considered as an experimental feature. In that case, what is needed to define it as stable? > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of wm4 > Sent: Monday, March 02, 2015 2:26 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl > > On Mon, 2 Mar 2015 07:29:11 + > "Gupta, Maneesh" wrote: > > > Hi, > > > > Similar to the way SDL is being autodetected, the attached patch proposes > to autodetect OpenCL. > > SDL shouldn't be autodetected at all, since it's not a system lib, and often > causes all sorts of problems even if you don't use anything SDL-specific. > [Gupta, Maneesh] Running grep "autodetect" on configure of ffmpeg gives: --disable-dxva2 disable DXVA2 code [autodetect] --disable-vaapi disable VAAPI code [autodetect] --disable-vdadisable VDA code [autodetect] --disable-vdpau disable VDPAU code [autodetect] --disable-bzlib disable bzlib [autodetect] --disable-iconv disable iconv [autodetect] --disable-lzma disable lzma [autodetect] --disable-opencl disable OpenCL code [autodetect] --disable-sdldisable sdl [autodetect] --disable-xlib disable xlib [autodetect] --disable-zlib disable zlib [autodetect] I see a lot of modules that are autodetected. And not all of them are system libs. I quoted SDL in my original mail only because the OpenCL detection code is done similar to the way SDL is being detected. Otherwise in my opinion OpenCL code is really on the same league as DXVA2 & VAAPI since they attempt to harness additional capabilities of the underlying hardware. > > Rationale for the change: > > * OpenCL linking typically happens against the OpenCL ICD's import library. > Hence there is no hard-linking against the OpenCL ICD's DLL/shared library. > So ffmpeg should continue to run fine for non-OpenCL cases even when > OpenCL runtime is not available on the user's system. > > * Enabling OpenCL is relatively low-impact since it does not automatically > disable or override any existing functionality. The user still needs to > explicitly > specify opencl=1 in the filter options when using ffmpeg to use the OpenCL > path. > > > > Please review the patch and share your comments on the same. > > > > Thanks and Regards, > > Maneesh > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Carl Eugen Hoyos > Sent: Monday, March 02, 2015 2:19 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] configure: autodetect opencl > > Gupta, Maneesh amd.com> writes: > > > Similar to the way SDL is being autodetected, the attached patch > > proposes to autodetect OpenCL. > > This cannot be done since the API is defined as being not stable. [Gupta, Maneesh] Sorry. I am not sure what you mean by this. Do you mean OpenCL API is not stable? It is a specification with clearly defined supported APIs for each specific version. > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: autodetect opencl
Hi, Similar to the way SDL is being autodetected, the attached patch proposes to autodetect OpenCL. Rationale for the change: * OpenCL linking typically happens against the OpenCL ICD's import library. Hence there is no hard-linking against the OpenCL ICD's DLL/shared library. So ffmpeg should continue to run fine for non-OpenCL cases even when OpenCL runtime is not available on the user's system. * Enabling OpenCL is relatively low-impact since it does not automatically disable or override any existing functionality. The user still needs to explicitly specify opencl=1 in the filter options when using ffmpeg to use the OpenCL path. Please review the patch and share your comments on the same. Thanks and Regards, Maneesh 0001-configure-autodetect-opencl.patch Description: 0001-configure-autodetect-opencl.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Dominik 'Rathann' Mierzejewski > Sent: Monday, February 09, 2015 5:22 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil > > FWIW I didn't have to pass ANY --extra-cflags and --extra-ldflags to build > FFmpeg with OpenCL on Fedora 21. I only had to install opencl-headers and > ocl-icd-devel packages. > [Gupta, Maneesh] Unfortunately I am in the Windows part of the world where the OS does not ship with any OpenCL headers. As regards linking against ICD, it does come with a drawback. If the application contains both an OpenCL path as well as a CPU fallback path, and you try running an application that is linked against ICD on a system that does not have any OpenCL runtime, you cannot use the CPU fallback path. That is why solutions such as clew or wrappers-with-clew-like-intention exist. There are sufficient examples of both clew as well as similar wrappers used by several open source projects. Clew for example is used in 1) LibreOffice (http://cgit.freedesktop.org/libreoffice/core/tree/clew/source) and 2) Blender (https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/clew). Similarly there are instances of wrappers-with-clew-like-intention developed and maintained by several open source projects as well. 1) See x264 (http://git.videolan.org/?p=x264.git;a=blob;f=common/opencl.c;hb=HEAD) and 2) OpenCV (https://github.com/Itseez/opencv/blob/master/modules/core/src/ocl.cpp). The purpose of these wrappers is simple. Allow static linking to OpenCL ICD in a manner that works across multiple platforms and that is hardware vendor agnostic. > Also, I still haven't seen you respond to my question about the library > itself. > It's not packaged for any major distro and I'm still not sure who is its > upstream. I found a GoogleCode project and a SourceForge project, both by > different authors (one seems to be independent, the other is the author of > clcc, from which clew seems to be derived from). > [Gupta, Maneesh] As I mentioned in another thread previously, the current upstream maintainers of clew are Sergey and Martijn. They maintain clew, cuew (CUDA equivalent to clew) for Blender. The maintained fork of the clew project is @ https://github.com/OpenCLWrangler/clew. I can talk to Martijn and check if he is fine with being added to this mail thread for any discussion/concerns regarding clew. > I'm not sure using a library with uncertain status is such a good idea. > [Gupta, Maneesh] My intention is only to simplify the user experience of compiling OpenCL enabled ffmpeg. Since this experience seems to be fine on Linux (where all you need to do is install opencl-headers and ocl-icd), an alternative approach is to improve the wiki documentation for the build environment on Windows to specify how to ensure ffmpeg finds the OpenCL related bits in a seamless fashion as seems to be the case on Linux. I can take a stab at this if this finds better acceptance with the ffmpeg community. Regards, Maneesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Use clew instead of cl.h for OpenCL
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of Dominik 'Rathann' Mierzejewski > Sent: Friday, February 06, 2015 4:51 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 2/3] Use clew instead of cl.h for OpenCL > > Hello, Maneesh. > > On Friday, 06 February 2015 at 11:09, Gupta, Maneesh wrote: > > Attached is the follow on patch that switches to using clew instead of > > cl.h > > What's the rationale to switch? cl.h is part of Khronos distribution while > clew.h seems to be part of clcc with a couple of forks floating around the > Internet. Is clew packaged in major distributions? It's definitely not in > Fedora > or Debian. > > Regards, > Dominik My intention of this entire patch was to allow most systems to compile ffmpeg with OpenCL enabled. Couple of problems with this today is that the location of OpenCL headers and libraries is not a standard nor is it easy to figure out this location across various platforms. As a result we need to tell ffmpeg the location of the Khronos OpenCL headers and libraries using --extra-cflags and --extra-ldflags in addition to using --enable-opencl. Clew, used by several open source projects such as LibreOffice and Blender, helps in this regards by not having to depend on the OpenCL static library. Additionally by adding it to the ffmpeg source tree, we can completely avoid having to pass any additional options for enabling OpenCL, thereby achieving my original intent. If you can suggest any better approach to achieving the intended goal, I can work on the required patch for the same. Also if it helps, below is a response from Martijn who is maintaining clew for Blender. -- Sergey and me forked clew as it was un-maintained and we wanted it to do OpenCL 1.2 at least. We host ours at https://github.com/OpenCLWrangler/clew and have the following plans for the future: - Make more of the code auto generated from official Kronos headers - Add OpenCL 2.0 support - Keep it stable and help out where needed to enable our stakeholders ( maintainers of OSL / OpenSubDiv ) and users to have a seamless opencl enabled experience where possible. We also have a similar library for Cuda's driver api and recently for loading SDL 2. Since our use of OpenCL is currently mainly the compositor there has not been a lot of development in the passed year on the whole clew front. I hope this helps you, Martijn -- Regards, Maneesh > -- > MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There > should be a science of discontent. People need hard times and oppression to > develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of wm4 > Sent: Friday, February 06, 2015 4:58 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil > > On Fri, 6 Feb 2015 11:06:28 + > "Gupta, Maneesh" wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > > > boun...@ffmpeg.org] On Behalf Of wm4 > > > Sent: Friday, February 06, 2015 4:31 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to > > > libavutil > > > > > > On Fri, 6 Feb 2015 11:14:21 +0100 > > > Hendrik Leppkes wrote: > > > > > > > On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh > > > wrote: > > > > > Hi All, > > > > > > > > > > There are several issues with the way ffmpeg compilation works > > > > > when > > > OpenCL is enabled using --enable-opencl. Chief among them are: > > > > > 1. One needs to also use --extra-cflags, --extra-ldflags & > > > > > -extra-libs to > > > specify the path to the OpenCL header and library files. Otherwise > > > configure fails. > > > > > 2. ffmpeg currently requires OpenCL 1.2, but the build system > > > > > may have > > > another version installed (such as the newer OpenCL 2.0 which has > > > deprecated some 1.2 APIs). > > > > > > > > > > There are a couple of ways to address this. > > > > > > > > > > * One way is the x264 approach which is to bundle cl.h, > > > > > cl_platform.h and > > > a wrapper c file which relies on dynamically loading OpenCL rather > > > than using static linking. This requires modifications to the entire > > > OpenCL based code since we cannot use the OpenCL APIs directly. > > > > > * Another approach taken by LibreOffice and Blender for example > > > > > is to > > > use clew (i.e. The OpenCL Extension Wrangler Library). This has the > > > advantage of letting us use the OpenCL APIs directly yet at the same > > > time relying on dynamically loading OpenCL. The clew project is > > > hosted at https://github.com/OpenCLWrangler/clew. This is maintained > > > by two people (Sergey and Martijn). > > > > > Usage of clew in Libreoffice can be seen @ > > > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in > > > Blender @ > > > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/ext > > > ern/cl > > > ew. > > > > > > > > > > This patch is for adding clew to the ffmpeg tree. The subsequent > > > > > patches > > > switch the OpenCL code in ffmpeg from using cl.h to using clew. > > > > > > > > > > > > > > > > > Using such a library is fine, if its deemed the best solution > > > > available, but flat-out importing its code into avutil is not. > > > > > > +1 > > > > > > Also look at all these awful "portability" hacks in the added code. > > > It's not a good idea to agree to maintaining this terrible mess. > > > > Alright. Can you suggest an alternate way of building ffmpeg using clew? > Clew has lot of advantages and essentially consists of a single source and > header file. I will modify and resubmit the patch accordingly. > > Convince upstream to package it as real library. Clew can already be built as a static library. It ships with a cmake file. However I am a little confused here. My intention for using clew was to remove the pain of having to specify multiple parameters to enable the OpenCL feature. If clew is used as a library, instead of having use --extra-cflags, --extra-ldflags to specific the path to standard OpenCL bits I would have to still use them to point ffmpeg to the path to clew. Or am I missing something here? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of wm4 > Sent: Friday, February 06, 2015 4:31 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil > > On Fri, 6 Feb 2015 11:14:21 +0100 > Hendrik Leppkes wrote: > > > On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh > wrote: > > > Hi All, > > > > > > There are several issues with the way ffmpeg compilation works when > OpenCL is enabled using --enable-opencl. Chief among them are: > > > 1. One needs to also use --extra-cflags, --extra-ldflags & -extra-libs to > specify the path to the OpenCL header and library files. Otherwise configure > fails. > > > 2. ffmpeg currently requires OpenCL 1.2, but the build system may have > another version installed (such as the newer OpenCL 2.0 which has > deprecated some 1.2 APIs). > > > > > > There are a couple of ways to address this. > > > > > > * One way is the x264 approach which is to bundle cl.h, cl_platform.h and > a wrapper c file which relies on dynamically loading OpenCL rather than using > static linking. This requires modifications to the entire OpenCL based code > since we cannot use the OpenCL APIs directly. > > > * Another approach taken by LibreOffice and Blender for example is to > use clew (i.e. The OpenCL Extension Wrangler Library). This has the > advantage of letting us use the OpenCL APIs directly yet at the same time > relying on dynamically loading OpenCL. The clew project is hosted at > https://github.com/OpenCLWrangler/clew. This is maintained by two people > (Sergey and Martijn). > > > Usage of clew in Libreoffice can be seen @ > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in > Blender @ > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/cl > ew. > > > > > > This patch is for adding clew to the ffmpeg tree. The subsequent patches > switch the OpenCL code in ffmpeg from using cl.h to using clew. > > > > > > > > > Using such a library is fine, if its deemed the best solution > > available, but flat-out importing its code into avutil is not. > > +1 > > Also look at all these awful "portability" hacks in the added code. > It's not a good idea to agree to maintaining this terrible mess. Alright. Can you suggest an alternate way of building ffmpeg using clew? Clew has lot of advantages and essentially consists of a single source and header file. I will modify and resubmit the patch accordingly. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] Update configure since OpenCL compilation does not need cl.h
Attached is the patch that updates the configure script since we no longer depend upon cl.h. One added advantage of using clew is that we can turn on OpenCL compilation by default. This patch additionally enables OpenCL compilation on Linux, Windows and Darwin target OS. Regards, Maneesh Gupta 0003-Update-configure-since-OpenCL-compilation-does-not-n.patch Description: 0003-Update-configure-since-OpenCL-compilation-does-not-n.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] Use clew instead of cl.h for OpenCL
Attached is the follow on patch that switches to using clew instead of cl.h Regards, Maneesh Gupta 0002-Use-clew-instead-of-cl.h-for-OpenCL.patch Description: 0002-Use-clew-instead-of-cl.h-for-OpenCL.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] updated documentation for -opencl_bench option
> -Original Message-
> From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-
> boun...@ffmpeg.org] On Behalf Of Stefano Sabatini
> Sent: Tuesday, January 27, 2015 4:38 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] updated documentation for -
> opencl_bench option
>
> On date Tuesday 2015-01-27 09:56:41 +, Gupta, Maneesh encoded:
> > Attached is a patch for updated documentation for the -opencl_bench
> option.
> >
> > Regards,
> > Maneesh
>
> > From 5c963436f67cc2fe6eae93f0fbda588e902f2da4 Mon Sep 17 00:00:00
> 2001
> > From: Maneesh Gupta
> > Date: Tue, 27 Jan 2015 15:09:41 +0530
> > Subject: [PATCH] documentation for -opencl_bench
> >
> > ---
> > doc/fftools-common-opts.texi | 31 +-
> -
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/fftools-common-opts.texi
> > b/doc/fftools-common-opts.texi index 7d52c1a..876c53c 100644
> > --- a/doc/fftools-common-opts.texi
> > +++ b/doc/fftools-common-opts.texi
> > @@ -294,8 +294,35 @@ Possible flags for this option are:
> > @end table
> >
> > @item -opencl_bench
> > -Benchmark all available OpenCL devices and show the results. This
> > option -is only available when FFmpeg has been compiled with @code{--
> enable-opencl}.
> > +This option is used to benchmark all available OpenCL devices and
> > +print the results. This option is only available when FFmpeg has been
> > +compiled with @code{--enable-opencl}.
> > +
> > +When FFmpeg is configured with @code{--enable-opencl}, the options
> > +for the global OpenCL context are set via @code{-opencl_options}. See
> > +the ``OpenCL Options`` section in the ffmpeg-utils manual for the
> > +complete list of supported options. Amongst others, these options
> > +include the ability to select a specific platform and device to run
> > +the OpenCL code on. By default, FFmpeg will run on the first device
> > +of the first platform. While the options for the global OpenCL
> > +context provide flexibility to the user in selecting the OpenCL
> > +device of their choice, most users would probably want to select the
> fastest OpenCL device for their system.
> > +
>
> > +This option assists the selection of the most efficient configuration
> > +by identifying the appropriate device for the user?s system. The
> > +built-in
>
> unrecognized character here, use '
>
> > +benchmark is run on all the OpenCL devices and the performance is
> > +measured for each device. The devices in the results list are sorted
> > +based on their performance with the fastest device listed first. The
> > +user can subsequently
>
> > +invoke Ffmpeg using the device deemed most appropriate via
>
> @command{ffmpeg}
>
> > +@code{--opencl_options} to obtain the best performance for the OpenCL
>
> @option{-opencl_options}
>
> > +accelerated code.
> > +
> > +Typical usage to use the fastest OpenCL device involve the following
> steps:
> > +@example
> > +ffmpeg -opencl_bench
>
> Close the example, or comment with # the next comment line.
>
> > +Note down the platform ID (@var{pIDx}) & device ID (@var{dIDx}) of the
> first i.e. fastest device in the list.
>
> > +ffmpeg -opencl_options
> platform_idx=@var{pIDx}:device_idx=@var{dIDx} ...
> > +@end example
>
> I'd write something like this:
>
> 8<
> Typical usage to use the fastest OpenCL device involve the following steps.
>
> Run the command:
> @example
> ffmpeg -opencl_bench
> @end example
>
> Note down the platform ID (@var{pidx}) and device index (@var{didx}) of
> the first i.e. fastest device in the list.
>
> Select the platform and device using the command:
> @example
> ffmpeg -opencl_options platform_idx=@var{pidx}:device_idx=@var{didx} ...
> @end example
> 8<
>
> LGTM otherwise, thanks.
> --
> FFmpeg = Foolish and Fancy Magic Powered Educated Gnome
Attached is the updated patch with above comments addressed.
Regards,
Maneesh
0001-updated-documentation-for-opencl_bench.patch
Description: 0001-updated-documentation-for-opencl_bench.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] updated documentation for -opencl_bench option
Attached is a patch for updated documentation for the -opencl_bench option. Regards, Maneesh 0001-documentation-for-opencl_bench.patch Description: 0001-documentation-for-opencl_bench.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] OpenCL device selection documentation
Hi, I was searching the FFMPEG documentation on enabling OpenCL & selecting/specifying an OpenCL device. Here is what I could find: 1) Enabling OpenCL while building OpenCL: https://trac.ffmpeg.org/wiki/HWAccelIntro 2) Specifying an OpenCL device to be used: /share/doc/ffmpeg/ffmpeg-utils.html#OpenCL-Options I did not find much information on the auto-selection of an OpenCL device using the -opencl_bench. What is the best way to update this documentation to include information regarding the auto-selection logic from a user perspective? I would use assume it would be a patch that modifies the files used to generate ffmpeg.html and ffmpeg-utils.html (i.e. doc/ffmpeg.texi and doc/ffmpeg-utils.texi). Please let me know your thoughts on this before I proceed with working on a patch for this documentation. Thanks and Regards, Maneesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
