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

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20130409/fe5f0555/attachment.asc>