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

[Wei Gao]

2013/4/2 James Almer <jamrial at gmail.com>

> On 01/04/13 8:37 AM, Michael Niedermayer wrote:
> > On Mon, Apr 01, 2013 at 12:23:51PM +0200, Stefano Sabatini wrote:
> >> On date Monday 2013-04-01 17:52:13 +0800, Wei Gao encoded:
> >>>
> >>
> >>> From 8d7554e834fbb36bdfaaf384905320bce5bc29f0 Mon Sep 17 00:00:00 2001
> >>> From: highgod0401 <highgod0401 at gmail.com>
> >>> Date: Mon, 1 Apr 2013 17:46:11 +0800
> >>> Subject: [PATCH 1/2] opencl wrapper based on comments on 20130401
> >>>
> >>> ---
> >>>  configure          |   4 +
> >>>  libavutil/Makefile |   3 +
> >>>  libavutil/opencl.c | 719
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>  libavutil/opencl.h | 201 +++++++++++++++
> >>>  4 files changed, 927 insertions(+)
> >>>  create mode 100644 libavutil/opencl.c
> >>>  create mode 100644 libavutil/opencl.h
> >>
> >> Missing APIchanges entry and libavutil minor bump, but these can be
> >> added by the committer.
> >
> > I didnt bump libavutil as i think the API/ABI is not stable yet
> >
> > [...]
> >> No more comments from me, we can fix it later in case of need as the
> >> API is marked as experimental, and other minor formatting nits can be
> >> fixed when it's already in.
> >
> > patch applied
>
> 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
> pthread_mutex_destroy() in said functions, which will let us use the
> w32threads and
> os2threads wrappers.
>
> Besides, as things are right now in opencl.c, LOCK_OPENCL and
> UNLOCK_OPENCL are only
> defined when building with pthreads, or with no threading at all. So
> trying to build
> with any of the other two thread types and opencl enabled will fail to
> compile.

Hi, can you tell more details of pthread_mutex_init()
pthread_mutex_destroy()?  I think it can use like this:

pthread_mutex_t mutex;
1.pthread_mutex_init(&mutex, NULL);.
2.lock :pthread_mutex_lock(&p->mutex);
3.unlock:pthread_mutex_unlock(&p->mutex);

use the lock and unlock code to replace the orignal code. Is it OK? I have
little experence on thread field,
Thanks.

Regards.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>