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

Michael Niedermayer michaelni at gmx.at
Wed Oct 30 16:27:48 CET 2013

On Wed, Oct 30, 2013 at 03:29:40PM +0100, Stefano Sabatini wrote:
> On date Wednesday 2013-10-30 12:01:57 +0100, Michael Niedermayer encoded:
> > On Wed, Oct 30, 2013 at 11:07:20AM +0800, Wei Gao wrote:
> [...]
> > i suggest to split the patch into a libavutil and a libavfilter
> > one. This reduces the chances of breaking public API/ABI as the
> > code must still build (and work) with only the libavutil patch applied.
> > 
> > also i suggest to make sure that your new API will serve future needs
> > and be easy extendible not requiring major version bumps for changes.
> > Its likely alot less work to
> > design it well in the first place than to deal with these API/ABI
> > compatibility issues later.
> > 
> > old functions that are not part of the new API should be marked as
> > deprecated, point the reader to the new and be put under #if so they
> > get automatically disabled with the next major version bump.
> > 
> > also if the new is still meant to be experimental, it might be best
> > to require a --enable-experimental in configure.
> > In that case then, random ABI/API changes would be no problem, sadly
> > its too late for that for the old API, but it could be used for the
> > new ...
> > 
> > also, if its too hard to support old and new at the same time, one
> > "hack" would be to support enough of the old API/ABI so building
> > succeeds and code trying to use it gets a clear & clean error
> > like return AVERROR(ENOSYS) on old functions.
> While I agree on --enable-experimental, this should not disallow to
> break this API now, since it was agreed that it could be marked as
> experimental one year ago.

the problem is the ABI

for example:
libavfilter uses av_opencl_release_kernel()
the patch removes this function from libavutil

if someone has binary packages that have opencl enabled and he upgrades
libavutil then libavfilter will have a reference to a function that
no longer exists.

and av_opencl_register_kernel_code() has a changed prototype in the
patch its also used by libavfilter from avfilter_register_all()
this will break every application using libavfilter no matter if they
use opencl or not even if their linker doesnt freak out about the
unresolved symbols before.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- 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/542c56b6/attachment.asc>

More information about the ffmpeg-devel mailing list