[FFmpeg-devel] [PATCH]opencl: compile kernels separately

[Michael Niedermayer]

On Wed, Oct 30, 2013 at 10:03:49AM +0100, Hendrik Leppkes wrote:
> On Wed, Oct 30, 2013 at 7:32 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On 30.10.2013, at 04:07, Wei Gao <highgod0401 at gmail.com> wrote:
> >> 2013/10/30 Lenny Wang <lenny at multicorewareinc.com>
> >>
> >>> Attached new patch after 2nd review.
> >>>
> >>> On Tue, Oct 29, 2013 at 3:24 PM, Lenny Wang <lenny at multicorewareinc.com>
> >>> wrote:
> >>>> Attached new patch has been cleaned up and modified based on previous
> >>>> reviewer's comments.  Any comments or questions please just let me
> >>>> know.
> >>>>
> >>>> On Tue, Oct 29, 2013 at 4:19 AM, Thilo Borgmann <thilo.borgmann at mail.de>
> >>> wrote:
> >>>>> Am 29.10.13 07:59, schrieb Lenny Wang:
> >>>>>> Currently opencl kernels in ffmpeg are compiled altogether at
> >>>>>> initialization stage, most of related data structures are maintained
> >>> within
> >>>>>> the opencl framework of ffmpeg.  This is very cumbersome to use and is
> >>> not
> >>>>>> efficient.  This patch uses distributed opencl programs/kernels for
> >>> each
> >>>>>> filter (or potentially any other component that uses opencl), allowing
> >>>>>> kernels to be compiled separately at each component's initialization
> >>> stage.
> >>>>>>
> >>>>>> Tests have been conducted successfully on mainstream Nvidia/AMD/Intel
> >>>>>> platforms with "-vf deshake=opencl=1,unsharp=opencl=1".
> >>>>>
> >>>>> Your patch contains trailing whitespaces, a lot of unnecessary and
> >>> unrelated
> >>>>> changes. Please clean it up and resubmit it.
> >>>>>
> >>>>> -Thilo
> >>>
> >>
> >> Hi, I reviewed the patch, and still has some bugs on code styles.
> >>
> >> I correct all bugs which I have found and make a patch, is it OK for you?
> >
> > The stuff you are changing all seems to be public API (has av_ prefix).
> > You may only change those in a way that might break any existing code at a major API bump, and usually only after a transition period.
> > If you want to use a new API you can add it with new names, but you can't just remove/change the old one.
> > Or to put it differently: if you install a previous FFmpeg version and then replace libavutil.so and only that one with a version after this patch and _any_ if the opencl filters break, the change is wrong.
> 
> I believe the OpenCL API was considered experimental and as such is
> not necessarily required to be API stable yet, until that experimental
> tag is revoked.
> 
> See the note in libavutil/opencl.h:
> * This interface is considered still experimental and its API and ABI may
> * change without prior notice.

./configure --help | grep -C2 opencl
  --enable-libzvbi         enable teletext support via libzvbi [no]
  --enable-openal          enable OpenAL 1.1 capture support [no]
  --enable-opencl          enable OpenCL code
  --enable-openssl         enable openssl [no]
  --enable-x11grab         enable X11 grabbing [no]

no mention of experimental
so someone building binary packages could not have known

and opencl functions in libavutil are used by libavfilter and cmdutils
so enabling that and distrbuting the libs as seperate packages is
enough

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131030/3d608d8e/attachment.asc>