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

James Almer jamrial at gmail.com
Tue Apr 2 01:50:42 CEST 2013


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.

Regards.


More information about the ffmpeg-devel mailing list