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

[Wei Gao]

2013/4/2 Wei Gao <highgod0401 at gmail.com>

>
>
>
> 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(&mutex);
> 3.unlock:pthread_mutex_unlock(&mutex);
>
   4. pthread_mutex_destroy(&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
>>
>
>