[FFmpeg-devel] [PATCH 1/2] libavutil/libavfilter: opencl wrapper based on comments on 20130401

[Wei Gao]

2013/4/9 Michael Niedermayer <michaelni at gmx.at>

> On Tue, Apr 09, 2013 at 09:41:07AM +0800, Wei Gao wrote:
> > 2013/4/9 Michael Niedermayer <michaelni at gmx.at>
> >
> > > On Thu, Apr 04, 2013 at 08:40:10PM +0800, Wei Gao wrote:
> > > > 2013/4/4 James Almer <jamrial at gmail.com>
> > > >
> > > > > On 04/04/13 12:36 AM, Wei Gao wrote:
> > > > > > 2013/4/4 James Almer <jamrial at gmail.com>
> > > > > >
> > > > > >> On 02/04/13 6:46 AM, Michael Niedermayer wrote:
> > > > > >>>> Since unlike in atomic.c we have init() and uninit() functions
> > > here,
> > > > > >> there's no need
> > > > > >>>> to have a statically allocated mutex. We could call
> > > > > >> pthread_mutex_init() and
> > > > > >>>
> > > > > >>> the init and uninit themselfs must be thread safe, also
> register is
> > > > > >>> called before init and must be thread safe
> > > > > >>
> > > > > >> As things are right now the code wont compile unless you use
> > > pthreads or
> > > > > >> no threading
> > > > > >> at all (See ticket #2422).
> > > > > >>
> > > > > >> So the code either needs to be changed to allocate the mutexes
> > > > > dynamically
> > > > > >> (Which will
> > > > > >> let us use the wrappers), or we make configure abort when
> trying to
> > > > > build
> > > > > >> with OpenCL
> > > > > >> support and w32threads or os2threads enabled.
> > > > > >>
> > > > > >> Ideally, the latter if implemented should be a temporary
> solution
> > > until
> > > > > >> the former is
> > > > > >> implemented instead.
> > > > > >>
> > > > > >> Regards.
> > > > > >>
> > > > > > Hi, I want to ask a question, does it mean that the OpenCL code
> > > can't be
> > > > > > used  in w32threads or os2threads? Is there any solutions to
> solve
> > > that?
> > > > > > Thanks
> > > > > > Best regards
> > > > >
> > > > > Right now, it fails to compile with anything except pthreads or no
> > > > > threading at
> > > > > all: http://ffmpeg.org/trac/ffmpeg/ticket/2422
> > > > >
> > > > > And as for a solution, making the mutex dynamic instead of static
> > > should
> > > > > allow
> > > > > us to enable this with all threading types using the wrappers, but
> I'm
> > > not
> > > > > sure how to properly implement that.
> > > > >
> > > > > thanks, can I add a function to init the mutex and note that it
> should
> > > be
> > > > called in the main thread to init the mutex? I think codecs also has
> this
> > > > problem. I saw that the init function is in pthreads.c, should I add
> a
> > > init
> > > > thread function for opencl in it?
> > >
> > > This may be difficult in some use cases
> > > consider a libA and a libB that both use libavfilter
> > > a user application using both libA and libB could call either libs
> > > init function in either order (if they have init functions at all)
> > >
> > thanks, michaelni, I am not familiar with threads, is there any
> > static Mutexs in win32threads and os2threads just like pthreads?
> > thanks
>
> I do not know which is the best way to do it
> There may be a simpler way but
>
>  you can use avpriv_atomic_ptr_cas()
> 1. allocate new mutex
>
> 2.use avpriv_atomic_ptr_cas() to set a global pointer to the new mutex
>   when it equals to NULL
>   This will either succeed in which case you where the first to set
>   it or fail, in which case it was already set, if so you free the
>   mutex that you allocated and use the one that was set
>
Thanks michaelni, I will learn and try it, thanks, learn a lot from you.

>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>