[FFmpeg-devel] [PATCH] configure: autodetect opencl
Maneesh.Gupta at amd.com
Mon Mar 2 12:35:10 CET 2015
> -----Original Message-----
> From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-
> bounces at 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 +0000, Carl Eugen Hoyos wrote:
> > Gupta, Maneesh <Maneesh.Gupta <at> 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:
> 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.
More information about the ffmpeg-devel